C89, size_t, and long

[Flash Gordon]

Yevgen Muntyan wrote, On 17/03/07 00:04:

Right... You commented on parts you liked,

I comment on those things I decide to comment on and not on those things
I decide not to comment on. You and everyone else does exactly the same.

> and you don't care about
the discussion in whole, where I say one thing and other hears what
he wants to hear. Just like here, you're saying I am claiming there
is a reason not to use standard headers. While I said like five times
that I do *not* know such a reason. Of course, from my unwillingness
to make baseless conclusions you make a conclusion that my opinion
is the contrary. And so on.

You sited what you thought might be a reason and seemed not to accept
that it was an exceedingly bad reason. You still seem not to accept that.

It was a hypothetical good reason for not using standard headers
in general,

I strongly disagree with the word "good" above. It would be an
incredibly bad reason.

> which naturally leads to avoiding #includ'ing stddef.h.
But yes, I do support the following: if an implementation has broken
header foobar.h and I write code for that platform, I will try to work
it around; and if not using foobar.h is a fix, I will avoid using
foobar.h. And *no*, I do not avoid using standard headers in *my*
code because of hypothetical problems.

I am saying that if you came across the problem you should take EXACTLY
the attitude I have taken for some library versions and OSs and tell
people it is broken and that if they want to use your code they cannot
use that version of that library.

Since it works for a small company being paid to develop code for far
larger companies I don't see any reason it would not work in other
situations. It has also worked for one developer within a small company
writing code for far larger companies.

Indeed, that's why we should use standard headers. And? Was it
you agreed or disagreed with my words about making conclusion
without having enough ground?

Writing code to deal with obscure systems is common, writing code to
deal with broken system libraries is at least extremely unusual.

If *I* did, nothing would break. You can prove there are no weird things
in stdio.h like that strndup on every system? You can prove silent
#includ'ing stdio.h will not break user code?

Providing stndup is *not* a weird anomaly. It is a reserved name so the
library can use it for whatever purpose it wants without breaking
correct code.

If it claims conformance to the C standard then you know it does not.
That is the POINT of having a standard.

Yes it does support broken C99 implementations.

No, it is supporting *incomplete* C99 implementations. Since they do not
yet *claim* to be conforming to C99 they are not broken.

> Now you can say
something about C90, that gnulib example is irrelevant since C90
is the important thing, perhaps because C90 is widely implemented
and so on. And we're back to Win64. Oh, totally forgot, it also
supports some broken C90 implementations.

I doubt it supports Win64 yet, lots of things don't. However, if it is
well written it is unlikely to be bitten by the one area of
non-conformance that has been identified, and including the headers from
a C implementation on Win64 is not likely to break anything.

Sorry, I misread what you said. What did you ask? What library and what
header? I know an implementation which breaks correct code, and it was
the original thing. I know a library which conforms to C90 and works
on all computers out there (even with C99 since no sane implementation
has small long) but Win64.

It is not inclusion of the standard headers that causes the problem, so
that is not a reason for avoiding including the headers. In fact, if
they used size_t as has been suggested in this thread they should then
it would not cause a problem.

I accept that it is a non-conformance of the 64 bit version of Visual
Studio (A 64 bit implementation of gcc on Win64 could well not be
broken, especially if they ever finish implementing C99).

So that *still* is not a reason to avoid including standard headers and
types, if anything it is an argument *for* using them.

I'm afraid processor bug is a little different from software bugs.

It was also a bug in the C implementation, one that was fixed under
pressure from everyone else not prepared to work around it.

Broken string functions on some platforms come to mind. Glib has
some stuff to work that around.

I've not seen mention in the documentation of working around broken
string functions, and I've not come across broken string functions. I
have come across ones that don't meet standard they don't claim to meet,
but that is another story.

Can you give a specific example of where it is working around a broken
string library, as opposed to one that does not meet a standard it does
not claim to meet, or one that is correct but does not provide the
functionality they want?

Good for you, what can I say? Not all people are so lucky, and not all
bugs are processor bugs which are so serious that addition breaks.

No, but a bug making avoidance of including standard headers would be
almost as serious since it would break stupidly large amounts of code.

Telling people they have to upgrade to the new fixed version of some
library is COMMON PRACTICE.

Again, great for you. Really great and I am glad you can workaround
problems by making them not exist in the first place. If you're saying
it's always possible and easy, you're wrong.

I've yet to come across a situation where it was not possible. Where it
was just awkward but not broken I could not argue it, but where it is
broken it is common practice to tell people they have to upgrade.

Such as what exactly? Are you saying implementation with a bug
in a standard header can't survive? I doubt it. Depends on the
bug, doesn't it? Or maybe you're saying there are no implementations
with buggy headers?

I am saying that an implementation with headers that were buggy enough
you could not safely include them would not survive. I have said this
several times. This is also why any such broken implementation would not
be a good reason to avoid using broken headers.

Um, Win64? Will it be boycotted for making small long type? Or does
it depend on the bug severity?

The standard headers are *not* so broken you cannot safely include them.
The breakage is of a different type. Also, it is not Win64 but the 64
bit version of Visual Studio.

_GNU_SOURCE thing? No clashes. Or do you mean standard C code? Who
said there are problems with that? See, library (not the C library)
developers may care about non-standard user code.

I mean exactly what I said. It is perfectly safe to include the standard
headers in conforming mode, and if you obey what the documentation tells
you (i.e. use _GNU_SOURCE correctly) it is safe to include them in
non-conforming mode.

I.e. the ONLY time it is NOT safe to include them is when YOU are at
fault. The same applies to authors of libraries. I.e., is is SAFE for
library writers to include standard headers in their headers because
things will only break when YOU do something wrong.

To put it another way, you are WRONG to say that avoiding header bugs
might be a good reason not to include standard headers ANYWHERE.

Especially open-source it seems.

I use a lot of open source, so I do know how it works. I have also been
on the wrong end of having the open source community NOT support things.
I just passed the lack of support along the line to customers and told
them we could not support it either and if they wanted to use the new
version of get bug fixes they *needed* they would have to upgrade.

Perhaps. Or perhaps not. You seem to be talking about standard
programs which use only standard headers or at least use only
standard features from standard headers.

Read the bits you have quoted earlier where I EXPLICITLY state that the
same rules apply when using the implementation in NON-conforming mode.

> You sure every implementation
has its implementation-specific extensions done in good nice
way so you can be sure #includ'ing a standard header behind
user back is safe if user uses those funny extensions?

If you use them you have to read the documentation for them as well, and
then YES, you CAN safely include them. I have been using system
specifics and extensions where appropriate since I started programming
professionally over 20 years ago (not in C back then) and it is safe.
Including on the implementations that people seem to me to complain most
about for providing extensions, gcc and MS Visual Studio.

See? Same thing. From "a header may break user code" you make conclusion
"a standard header may break standard code", though I didn't say that
and my example with _GNU_SOURCE isn't standard.

Last I looked string.h *is* a standard header. However, I EXPLICITLY
stated that it is still safe to include it in non-standard conforming
mode (i.e. using _GNU_SOURCE) as long as YOU read the documentation and
so do it correctly.

Who said I can't write my main() function? I can. Or I can ask
implementation to get me builtin translation unit with main()
which would call my FooBarMain().

The STANDARD says that the entry point for YOUR program in a hosted
implementation IS main. If the entry point of YOUR program is NOT main
then either it is NOT a hosted implementation (which is a perfectly
valid thing to be) or it is NOT compliant with the standard.

So if you invoke it so that you do not have to provide main you are NOT
invoking it as a compliant hosted implementation because the STANDARD
says that you have to provide main to a hosted implementation.

And if entry point is indeed main()? Here, let me repeat:

See everything I said above. The entry point to YOUR program has to be
main, not the entry point to something that calls your program. This is
because that is what the STANDARD says.

I have no idea how to use it properly as a Foo or C++ compiler either.
Nice nit though. Your statement is probably true, I don't really
have doubts about it.

So? You not knowing how to use it does not affect anything I said. MS
having WinMain as the entry point is legal when it is not behaving as a
hosted implementation, so they are fine there. When invoked as a hosted
implementation you have to provide main, so they are still fine.

That's right, that's why I said "user is stupid". So, a third-party
library mandates that stupid things are user's problem. It's quite
sensible, and in fact it's an approach taken by many libraries (glib
too). Now, can you guarantee there are no totally-legitimate non-stupid
things like this _GNU_SOURCE thing which could break?
Yes.

> Not necessarily
with standard C headers by the way. sys/stat.h is good too to make
developers wary of standard headers.

sys/stat.h is NOT a reason for developers to be wary of standard headers
and nothing you have said justifies your statement that it is. It would
make just as much sense to say the sinking of the Titanic was a good
reason for developers to be wary of standard headers.

Yes, even though Earth is not round. Maybe "no problems with standard
headers" is just as correct as "Earth is round"? Works fine most of
the time, but not always.

Don't you find it at all strange that you seem to be the only person who
thinks it does not work? Have you not considered that people with vastly
more experience might actually have found that compiler writers take
compliance to C89 seriously and take making their C implementations
usable as intended (i.e. including the standard headers) even more
seriously?

I think it's important not to make conclusions from absence of evidence
in technical groups. It's not a court. Exactly.

There is no evidence that you are not a figment of someone's deranged
imagination either.

Generally in both science and technical arenas the person challenging
what is generally believed has to provide some convincing evidence.

It is, if you think of C99 for a minute. stdbool.h and all that. But not
only that of course.

None of the implementations it support claim to be C99 implementations,
therefore working around them not having stdbool.h or not having an
stdbool.h that meets the C99 requirements is NOT working around a broken
implementation, it is working around an implementation being perfectly
correct and not providing what they want.

Or fixes some broken string functions for the case when they are
broken in the implementation. You sure it does not work around any
bugs in implementations?

Where? Working around a non-C99 implementation not providing C99
functionality is NOT working around a broken implementation.

Of course it's not, since gnulib is intended to be a complement to
any-C-library.

So having said it is an example of your point you now accept my
statement that it is not an example of my point.

Oh, just so you know I've decided that since you seem unable to >
understand the points others and I have made (several times above you
say you don't understand, or close enough) there is no point arguing
further with you. Believe what you will and the rest of us will be happy
knowing that we can always safely include standard headers and use
size_t, even with the small break that MS Visual Studio for Win64, since
that does not break well written code.

 

[muntyan]

Yevgen Muntyan wrote, On 17/03/07 01:20:





Yes, I know that. However, no typedef will allow you to provide an 8 bit
type is one does not exist and if char is not 8 bits one does not exist.
If, as you suggest, there reason is due to variability in the signedness
of plain char then one would expect them to state this and possibly
actually use signed char, since otherwise using a common option on gcc
on linux platforms will stop the typedef doing what they want.

Care to show that typedef? I have here

typedef signed char gint8;
typedef unsigned char guint8;

Documentation:

gint8

typedef signed char gint8;

A signed integer guaranteed to be 8 bits on all platforms. Values of
this type can range from -128 to 127.

guint8

typedef unsigned char guint8;

An unsigned integer guaranteed to be 8 bits on all platforms. Values
of this type can range from 0 to 255.

I.e. that comment is still highly amusing to me for the lack of
knowledge it shows.

Sure, totally incompetent people.

Yevgen

 

[muntyan]

Yevgen Muntyan wrote, On 17/03/07 01:20:





It's not my fault if they put a .c file in the includes directory which
is specifically for include files hence the name include. Since they
include header guards (again in a way that invades the implementation
name space) there is a strong suggestion that they expect people to
include it. As does the fact that it is only providing static functions,
typedefs, and struct definitions. Therefore I believe it *is* a header
file, it just does not have the conventional name.

I admit, I had no idea about this file. Indeed, looks like some
special-purpose private header. There are few others like that, it
doesn't change a thing.
#include <glib.h> which pulls everything from the glib library won't
get string.h for you. Moreover, even if you use <glib-object.h>, which
is the GObject main header (it's not part of the glib proper), you
won't get gobjectnotifyqueue.c nor
will you get string.h. Moreover, the documented and the legal way to
use libgobject is <glib-gobject.h>, you may not use individual headers
(the .h files you can see in gobject/ folder) with one documented
exception (not this file).

No, but #include <gobjectnotifyqueue.c> will, and if you actually loot
at it you will see that is its intended use.

No, you will get a compilation error. But it's details of course.
Indeed, a header. Undocumented, private header. Not even part of
libglib (the <glib.h> thing).

....

I require a lot more investigation or discussion with the developers to
state categorically that they are incompetent, but as I say the evidence
points to significant holes in their knowledge.

Well, let me make a conclusion. Bugs in your software present evidence
of your incompetence. I could even say that you are incompetent or
hostile, since you are producing software with bugs. Or not?

[snip]

Yevgen

 

[muntyan]

Yevgen Muntyan wrote, On 17/03/07 00:04:

Flash Gordon wrote: [snip]

The documentation for gnulib also talks about the fact that it *can*
freely include the standard headers that are available in the oldest
implementation that is supports, so it is definitely *not* an example
of dealing with not being able to include the headers because they are
too broken.

Of course it's not, since gnulib is intended to be a complement to
any-C-library.

So having said it is an example of your point you now accept my
statement that it is not an example of my point.

Same thing again. I said gnulib is an example of how people work
around bugs in implementation. I did *not* say it's an example of how
people avoid using standard headers. Whatever.
I brought gnulib in here because you said implementations are never
broken enough to have to workaround bugs in them. Sorry if it wasn't
clear. I believe I did say explicitly (not once) example of what
gnulib is.

Oh, just so you know I've decided that since you seem unable to >
understand the points others and I have made (several times above you
say you don't understand, or close enough) there is no point arguing
further with you.

Absolutely. There is no point in talking to you if you are unwilling
not to hear what I didn't say.

Believe what you will and the rest of us will be happy
knowing that we can always safely include standard headers and use
size_t, even with the small break that MS Visual Studio for Win64, since
that does not break well written code.

Did I say one single time that (not) #includ'ing standard headers may
be a problem with Win64? You're playing word games here, you are
composing different things I said into one as you desire, and make me
say whatever nonsense you want me to say.

So you be happy including standard headers. I am happy including
standard headers too, you know. And?

Yevgen

 

[Flash Gordon]

Care to show that typedef? I have here

OK. http://developer.gnome.org/doc/API/glib/glib-basic-types.html#GCHAR
Straight on THEIR web site. It is entirely possible that their
documentation does not reflect their code, but that would not be a good
sign either.

I've uninstalled the development package since I don't need it, so I
won't be checking the actual code.

typedef signed char gint8;
typedef unsigned char guint8;

Documentation:

gint8

typedef signed char gint8;

A signed integer guaranteed to be 8 bits on all platforms. Values of
this type can range from -128 to 127.

As stated, there is no guarantee in C that there is ANY such type.
Providing the typedef solves exactly NO problems.

Sure, totally incompetent people.

No one has said totally incompetent, I certainly have not. You do keep
pointing at evidence suggesting it though.

 

[Flash Gordon]

I admit, I had no idea about this file. Indeed, looks like some
special-purpose private header. There are few others like that, it
doesn't change a thing.

It does. You said glib avoids it and yet there it is using it in a file
provided WHITHOUT installing the sources.

#include <glib.h> which pulls everything from the glib library won't
get string.h for you. Moreover, even if you use <glib-object.h>, which
is the GObject main header (it's not part of the glib proper), you
won't get gobjectnotifyqueue.c nor
will you get string.h. Moreover, the documented and the legal way to
use libgobject is <glib-gobject.h>, you may not use individual headers
(the .h files you can see in gobject/ folder) with one documented
exception (not this file).

Either they are showing lack of competence by including it in that
directory (I did NOT install the sources, only the packages to develop
using it) or they include string.h in a file users of the library are
intended to use. Take your choice, I don't care which it is since I
don't develop with it.

No, you will get a compilation error. But it's details of course.

Including a .c file does NOT cause a compilation error.

Indeed, a header. Undocumented, private header. Not even part of
libglib (the <glib.h> thing).

If it is private it should not be placed in the directory for public
headers. In fact, as I did not install the sources it should not be
installed at all. So either you are wrong and it is intended to be used
or they are wrong for putting it their. Take your pick.

Well, let me make a conclusion. Bugs in your software present evidence
of your incompetence. I could even say that you are incompetent or
hostile, since you are producing software with bugs. Or not?

Bugs in my software are pointers towards where either my knowledge or
skill are lacking, if there are enough then it indicates I am
incompetent. The same applies to everyone else. You can decide you thing
me incompetent or hostile if you like, I really don't care.

Anyway, I said it was not worth arguing with you, and now I'll act on
it. Have the last word if you want since I won't read it.

 

[muntyan]

(e-mail address removed) wrote, On 18/03/07 00:41:





OK.http://developer.gnome.org/doc/API/glib/glib-basic-types.html#GCHAR
Straight on THEIR web site.

The documentation you cited is from 5 years old package, not from
headers you looked at. It doesn't change the fact that the actual
typedefs in actual code of that ancient package are

typedef signed char gint8;
typedef unsigned char guint8;

It is entirely possible that their
documentation does not reflect their code, but that would not be a good
sign either.

Of course, it would be a sign of usual problem with documentation.
Docs suck, way too often. They improve with time though.

I've uninstalled the development package since I don't need it, so I
won't be checking the actual code.

Of course, it's easier to get irrelevant docs and claim given software
package is written by incompetent people.

As stated, there is no guarantee in C that there is ANY such type.
Providing the typedef solves exactly NO problems.

"There is no guarantee in C". So?
gint8 *is* a signed integer guaranteed to be 8 bits on all platforms
where glib works. Values of this type can range from -128 to 127. Try
to disprove it. Provide an example of implementation where gint8 won't
be 8 bits and its range won't be -128..127. Oops, you can't, right?
Since glib isn't going to work on that platform even if you find it in
some computing museum.

No one has said totally incompetent, I certainly have not. You do keep
pointing at evidence suggesting it though.

Yeah. Sure.

 

[muntyan]

^^^^>>>>> fact. It does avoid string.h,

^^^^^^^^^^^^^^^^^^^^^^^





It does. You said glib avoids it and yet there it is using it in a file
provided WHITHOUT installing the sources.

What it provides in some file doesn't mean anything. It may install
anything. What's important is what it has in documented public
headers. Go find some fun code in /usr/include/sys/bits/ and then try
to make some conclusions like "it's there, installed, I can use it".

Either they are showing lack of competence by including it in that
directory (I did NOT install the sources, only the packages to develop
using it) or they include string.h in a file users of the library are
intended to use. Take your choice, I don't care which it is since I
don't develop with it.



Including a .c file does NOT cause a compilation error.

Your #include directive does, unless you are using undocumented
include paths. Try compiling programs installed on your computer with -
I/usr/include/bits/ and you'll see what happens. Of course you can
include any file, I didn't say you can't. Question is what it means,
when you include random file to prove some points (just like some
other guy, huh? correct to the end)

If it is private it should not be placed in the directory for public
headers.

Of course, Flash Gordon said.

In fact, as I did not install the sources it should not be
installed at all. So either you are wrong and it is intended to be used

I bet it is intended to be used if it's there. Question is how and
what for and by whom.

or they are wrong for putting it their. Take your pick.





Bugs in my software are pointers towards where either my knowledge or
skill are lacking, if there are enough then it indicates I am
incompetent. The same applies to everyone else. You can decide you thing
me incompetent or hostile if you like, I really don't care.

I decide you are hostile, I don't think you are incompetent. Your
hostility is caused by me not taking your "we think so" as a 100%
proof of anything.

Anyway, I said it was not worth arguing with you,

And still arguing, huh?

and now I'll act on
it. Have the last word if you want since I won't read it.

Well, whatever. You are the man who supports insulting people without
having enough information to judge about their competence. Insulting
them just to stay right in the argument; insulting because you can't
admit they might be not bad because it would mean *I* am right in
something here.

See, your problem, and problem of some other peple here is you make
conclusions too fast and too often those conclusions are rather
baseless. Or based solely on your experience. While your experience
may be huge, it's still surely very narrow. And experience of five
people is still way too narrow to judge about *everything*. Or perhaps
I am wrong and collective experience and knowledge of these five
people is indeed big enough, and together you know everything and you
may judge everything. Or am I?

 

[muntyan]

(e-mail address removed) wrote, On 18/03/07 00:41:





OK.http://developer.gnome.org/doc/API/glib/glib-basic-types.html#GCHAR
Straight on THEIR web site. It is entirely possible that their
documentation does not reflect their code, but that would not be a good
sign either.

Sorry, can't resist. It's not just some outdated docs, the link points
to this:

gchar
typedef char gchar;
Corresponds to the standard C char type.

You are not going to read it, too bad, maybe you indeed could provide
the *typedef* I asked you for, or provide a link to the docs you
didn't like so much.
See, I trusted you, and I supposed you knew what you were talking
about, and I assumed it was docs bug. Whatever. It's so much better to
whine a little "oh they are incompetent morons their docs are so
amusing".

 

[Steve Thompson]

Newsgroups: comp.lang.c
Date: Fri, 16 Mar 2007 14:08:15 +0000
From: Flash Gordon <[email protected]>
Subject: Re: C89, size_t, and long

Yevgen Muntyan wrote, On 16/03/07 03:57:

If you are not prepared to provide evidence for you claims then do not
expect people to take them seriously.

<delurk>

Reading this thread has made me curious about the library under discussion.
If the OP refuses to name the library, perhaps there is a good reason for
it. Perhaps the licensing terms forbid it? Whatever the case it would
seem that the argument is indeed progressing without a concrete subject,
that is an example, and as such is ultimately futile.

Maybe the OP should do whatever it is he has to do in order to provide the
specific example in this instance so he may then be taken seriously.
Otheriwse, I would say he has no basis whatsoever for argument or discussion.


Regards,

Steve

 

[muntyan]

On Fri, Mar 16, 2007 at 02:08:15PM +0000, Flash Gordon set bits thusly: [snip]

<delurk>

Reading this thread has made me curious about the library under discussion.
If the OP refuses to name the library, perhaps there is a good reason for
it.

Yes, the reason was that the library developers were called
incompetent by a man who had no idea who he was talking about, or what
code he was talking about. I even suspect that the library developers
are much more competent than that man.
Yes, I didn't want to bring the names in here, naturally.

In any case I did name it (not even today or yesterday), it's glib.

Maybe the OP should do whatever it is he has to do in order to provide the
specific example in this instance so he may then be taken seriously.

Maybe you should read the thread if you really care? I understand you
don't care, and I understand you have no desire to read this stupid
thread. But perhaps avoid comments on it in this case?

Otheriwse, I would say he has no basis whatsoever for argument or discussion.

But opponents surely do have basis for reading what I didn't write and
for calling others incompetent in conclusion from whatever they made
up in their mind. So, one says "those guys are incompetent, who are
those guys?", and it's fine. Me not saying who those guys are means I
have no basis for argument or discussion. Yeah.

 

[Steve Thompson]

Newsgroups: comp.lang.c
Date: 18 Mar 2007 16:04:48 -0700
From: (e-mail address removed)
Subject: Re: C89, size_t, and long

On Fri, Mar 16, 2007 at 02:08:15PM +0000, Flash Gordon set bits thusly: [snip]

<delurk>

Reading this thread has made me curious about the library under discussion.
If the OP refuses to name the library, perhaps there is a good reason for
it.

Yes, the reason was that the library developers were called
incompetent by a man who had no idea who he was talking about, or what
code he was talking about. I even suspect that the library developers
are much more competent than that man.
Yes, I didn't want to bring the names in here, naturally.

Naturally? It's not like the authors of glib are working in secret,
distributing their code under an NDA to a select group of clients. (And
even so, discussing it in roundabout terms would still likely constitute a
violation of the NDA.) In any case, your refusal to name names until
called on it is ... specious.

In any case I did name it (not even today or yesterday), it's glib.


Maybe you should read the thread if you really care? I understand you
don't care, and I understand you have no desire to read this stupid
thread. But perhaps avoid comments on it in this case?

News propogation is not necessarily ideal. My ISP believes that Usenet is
a non-essential service and therefore fails to maintain a decent spool. In
order to get the remaining posts and read your reply in a timely fashion, I
had to specifically use another source. Don't piss on my head about
'reading the thread', dickwad, I had no idea my view of the thread was out
of date.

But opponents surely do have basis for reading what I didn't write and
for calling others incompetent in conclusion from whatever they made
up in their mind. So, one says "those guys are incompetent, who are
those guys?", and it's fine. Me not saying who those guys are means I
have no basis for argument or discussion. Yeah.

There are assholes all over Usenet who will make up their opinions _a
priori_ based on their prejudices or corporate affilliation. When they
apply said prejudices to discussions in complete opposition to the text, it
is usually rather obvious. If you wish to argue with them, and on their
level, feel free to do so. But don't become all bitchy when it is noted
that you lose the battle right at the outset when you engage them on their
terms.

Personally, after finally reading all the messages in the thread, I think
you're full of shit. If pushed, I would venture to say that you write in
order to hear yourself speak, and for the attention (good or bad) that your
misguided arguments draw. As for the intellectual or ethical value of your
position and posture: trivial.


Regards,

Steve

 

[muntyan]

Naturally? It's not like the authors of glib are working in secret,
distributing their code under an NDA to a select group of clients. (And
even so, discussing it in roundabout terms would still likely constitute a
violation of the NDA.) In any case, your refusal to name names until
called on it is ... specious.

I didn't want to name it because if one of glib developers reads this
stuff occasionally, I would be ashamed. Because I bring their code as
an example of wrong bad code which violates all the holy principles. I
didn't mean it, I didn't say it, others did, but it doesn't change a
thing.

Now, leaving aside my irrelevant psychological reasons not to name it,
this thing:

Specific example of freaking what? Of a library which uses long
instead of size_t? Man, turn on your brain and use grep, try grepping
for "alloc", you'll find some examples of such things on your unixish
system. If you're on windows, it sucks, you have to use koders.com.
Now, if you don't want to that, it means you don't care. If you don't
believe there are libraries which do things like that then you either
believe in bugless software, or you believe in UFO, or <insert
whatever you like>

News propogation is not necessarily ideal. My ISP believes that Usenet is
a non-essential service and therefore fails to maintain a decent spool. In
order to get the remaining posts and read your reply in a timely fashion, I
had to specifically use another source. Don't piss on my head about
'reading the thread', dickwad, I had no idea my view of the thread was out
of date.

It was my mistake, and I am sorry for it, but your view of the thread
was up-to-date enough for not pissing on my head about your view of
presented evidence and other shit.

 

[Steve Thompson]

It was my mistake, and I am sorry for it, but your view of the thread
was up-to-date enough for not pissing on my head about your view of
presented evidence and other shit.

Sorry and $1.75 CAD will get you a fuckin' coffee at Starbucks. HTH.


Regards,

Steve