C89, size_t, and long

[CBFalconer]

Eric Sosman wrote:
.... snip ...

It's surely the easiest to walk a problem around by calling others
incompetent, especially if it's not your problem.


I do have a specific library in mind, indeed. It's not written by
me or my friends or relatives. It's a widely used and indeed useful
library.

So why are you hiding its identity, after a specific request for
such?

 

[Yevgen Muntyan]

... which you have not named, to warn us away from it.

That's right. Somehow I don't believe you. And somehow I don't want
bring names in this context. Those guys are not hostile, unlike you.

I offered the remark as a "proposition," thus inviting
a counter-example. Got one?

Nope, as I said. Still can't make a conclusion there isn't one.
I don't know way too many things to claim something doesn't exist
because I've never seen it.

Yes, "every"

Good you used "quotes" here.

-- unless you've decided to stray outside the
bounds of Standard C. There are good reasons for such strayings,
but you can hardly blame the consequences on the Standard headers.

If the headers in particular implementation are broken, then
they are broken. I don't blame the Standard for that. Not sure
if I blame "Standard headers". And not sure how it is relevant
to whether I use or do not use POSIX read and write.

Again, I'd be interested to learn the name of this perverse
library you keep alluding to.

Proposition: A library that deals in object sizes but uses
unsigned long instead of size_t to describe them is perverse.
Counter-example?

I know one. If a library has a bug, you call it perverse? I know
*lots*.

Balderdash. They should be equally leery of the % operator.

I'd think the developers carefully use % operator if it's broken
on some target platform. Is it broken somewhere, did it cause
problems for someone? You seem to imply it.

Your argument (perhaps I have misunderstood it) was that
someone might prefer to use unsigned long instead of size_t
because he would need to include a Standard header to obtain
a size_t definition, and the implementation's headers might
be broken. That's what I think you said; that's what I reject.

Well, I can't provide any examples of broken standard headers,
I have access only to two systems here, and I am not aware
of some famous example. Does it mean there isn't one? No.
Is there one? I have no idea. Do *I* avoid using standard
headers? *No*. Read the paragraph you replied to?

Yes, I've heard of the WinMain() thing. It's perfectly legal,
but only for free-standing (not hosted) environments. In those
systems, the entire Standard library is optional and you cannot
even rely on the existence of exit(). Those systems do not meet
the requirements the Standard places on hosted systems, and if
they claim to conform to the Standard for hosted systems they
claim incorrectly.

I'm glad you provided this useful information, even though it's
irrelevant. But since we're on it, implementation may provide
a separate translation unit which contains definition of main(),
which in turn calls my WinMain. I can ask implementation to do it
for me, and it'd be perfectly legal. I have no idea how exactly
it's done in MS implementation, do you? Come on, let's talk about
what's legal and what's not, exactly on point.

Um, er, haven't you simply illustrated what I wrote? "There
are identifiers that are reserved for future use, meaning that
the standard headers are free to define them." The four strxxx()
identifiers you show are in that class: The implementation is at
liberty to provide them, and if you use `strdup' or `streptomycin'
as an identifier, the clash is your fault, not the implementation's.
"Personal matters" have nothing to do with it: You either tread on
the reserved name space and risk the consequences, or you keep your
distance and remain safe.

Sorry, what clash? If I don't define _GNU_SOURCE in some way, I
do *not* get declaration of strndup(). glibc provides strndup()
to me but I have to take special measures to use it.
If some library header has '#include <string.h>' then I can't
#define _GNU_SOURCE after it and get strndup() declaration.
If I do #define _GNU_SOURCE before, and the library includes
some more implementation headers, I could get some other stuff
changed, which I may or may not want. And this is exactly the
business for me, a user, not for library to decide which headers,
in what order, and how I use. (_GNU_SOURCE and strndup is
simply a trivial example, people say there are much worse
situations where header order matters)

But even if I wrote totally illegal code which worked fine, it'd be
stupid if some unrelated library broke it. It would be totally fine as
far as the standard is concerned, of course, UB and all that, so what?

For the record, I am not saying I am writing that evil code,
nor am I advocating writing it. (I know, it can't help, you'll
think I ask standard for something, moreover you will think I
ask you for something, and so on)

....

As I said, you may want the undefined behavior.

I may want the well-defined behavior which left undefined by
the standard. If the use of _GNU_SOURCE is documented by
implementation, I may use it. But it's not the point of course.

That's
one of those "personal matters" you refer to, but not a problem
for C.

Who said it's a problem for C. Again, you are saying it like I am
claiming standard owes me something, standard is completely wrong,
and I invoke UB every day twice a day.
No, I am saying that library developers may have an attitude
of "user knows better what he's doing".

You're out in the unexplored and exciting territory --
not necessarily a bad place to be, but not a country where the
laws are universally obeyed. Or even understood. If you want
to deal with Roy Bean, "The Hangin' Judge," "The Law West of
the Pecos," that's your lookout. It has its rewards, but also
its dangers.

Poetry...

 

[Yevgen Muntyan]

That's right. Somehow I don't believe you. And somehow I don't want
bring names in this context. Those guys are not hostile, unlike you.

I think I have to apologize for overreacting. I should not take insults
so close. Perhaps "incompetent" wasn't an insult, it was meant to be
a statement about one's ability to do certain things in right way,
supposedly, but in my dictionary "competent" is a very complex notion,
which is not equivalent to "never makes mistakes". Perhaps supposed
incompetence of certain programmers wasn't a justification for violating
standards by some company. Oh well.

Really sorry,
Yevgen

 

[Richard Heathfield]

Yevgen Muntyan said:

That's right. Somehow I don't believe you.

It seems that Mr Muntyan is not content with calling me a liar. Now he
is calling Eric Sosman a liar, too. How many more of us will he call
liars before he is through?

 

[Yevgen Muntyan]

Yevgen Muntyan said:


It seems that Mr Muntyan is not content with calling me a liar. Now he
is calling Eric Sosman a liar, too. How many more of us will he call
liars before he is through?

Um, I said I don't believe he wants me to name the library because he
wants to "be warned not to use that organization's products". Does it
qualify as "calling him a liar"? Perhaps. I apologize in that case.
It was a heated argument, with some rude stuff.
If you are saying someone is wrong, does it mean he's a liar? Must be,
since you're saying he said something wrong, that is lied. Or not?

Dear Mr Heathfield, I do understand that saying in public you're not
telling the truth is a bad offense. But when you're making totally
ridiculous statements to justify your rudeness, I simply can't resist.
Hm, somehow I don't believe you're most offended by me calling you
a liar. For some reasons I think the worst thing is disagreement
with you even after you present all your killer
100%-correct-and-ignore-everything-else arguments. Did I just call you a
liar again?
Sorry about that, I do understand I will be hurt by this more than you.

Yevgen

 

[Richard Bos]

That's good and everything, but doesn't always work on practice
unfortunately. If I happen to use some library which uses long instead
of ssize_t, and if I happen to get a dll of that library, I have a
problem.

(If you use ssize_t at all, you have a problem, because that's not an
ISO type and the idea behind it is broken; the only valid reason to have
it in the first place is covered by ptrdiff_t.)

However, if you use a library and you find you can't trust it, your
options are basically to choose a different library, to roll your own,
or to accept that your supervisor doesn't know what he's talking about
and drink the flavorade. Discussing with yourself whether there's a
theoretical possibility of brokenness when you already know that you
will not be able to stop the breakage is reason to file a defect report
with your managers, not reason to fret about it.

Perhaps. Or maybe it's because many vendors put lot of non-standard
stuff into standard headers. Say, if you #include <string.h> and
do not #define _GNU_SOURCE with glibc, then you don't get strndup()
declaration.

So? What does that have to do with the price of fish?

You need functions from <string.h>, you #include <string.h>, and you get
size_t for free. Ditto with <stdio.h>, and all the others. If you choose
not to #include a header you should #include because you just _might_
one day have to deal with Ganuck, the difference between unsigned long
and size_t is the least of your problems; getting a grip on your
priorities is much more important.

Richard

 

[Richard Bos]

Forgot to mention another evil thing the library does: it uses void*
for function pointers. I wonder if it's caused by hostility or
incompetence.

_The_ library. You obviously have a particular library in mind. Care to
put your money where your mouth is, and name it?

(My first guess would be something coming from M$ itself; in which case
a. The size_t/unsigned long difference is irrelevant because it comes
from the same vendor anyway, and
b. Both. Obviously.)

Richard

 

[Eric Sosman]

Yevgen Muntyan wrote: [... a lot ...]

Eric Sosman wrote: [... too much ...]

Perhaps it's time to review the bidding. This thread
began with your technical question about the implications of
a quiet change in the C99 Standard. I and others explained
how the existence of a size_t wider than unsigned long could
change a program's behavior. You wondered whether this meant
that Win64 was broken, and the consensus seemed to be that it
is. I went on to say that the breakage was unlikely to be
serious, and explained why I thought so. Among my reasons:
nobody would deliberately store size_t values in anything other
than a size_t -- like an unsigned long -- unless there were an
excellent reason to believe the values being stored would be
sufficiently small.

And that's when things got weird, or at least when they
started to elude my understanding. You mentioned a nameless
but useful library that stores sizes in unsigned long, and the
library's existence somehow made me a villain. You are worried
that the library's ill-advised choice of data type might make it
vulnerable to breakage when running on broken Win64, and this
worry somehow makes you angry at me.

I do not understand how the interaction of choices I did not
make and was not responsible for justifies blaming me for the
potential breakage. It's beyond my comprehension, and I give up.

 

[Flash Gordon]

Yevgen Muntyan wrote, On 16/03/07 06:22:

Um, I said I don't believe he wants me to name the library because he
wants to "be warned not to use that organization's products". Does it
qualify as "calling him a liar"? Perhaps. I apologize in that case.
It was a heated argument, with some rude stuff.
If you are saying someone is wrong, does it mean he's a liar? Must be,
since you're saying he said something wrong, that is lied. Or not?

Since you have not named the library, the only other part in statement
you could be disagreeing with is the reason why we would want to know
which library it is. Are you saying that Eric might be mistaken about
why he wants to know the name of the library? If not (and that would be
a ridiculous thing for you to claim) then the logical conclusion is you
think he is lying about why he wants to know the name of the library.

Dear Mr Heathfield, I do understand that saying in public you're not
telling the truth is a bad offense. But when you're making totally
ridiculous statements to justify your rudeness, I simply can't resist.

The last few posts in this thread by Richard and Eric do not seem to be
making ridiculous statements to me, only your posts seem to be doing that.

Hm, somehow I don't believe you're most offended by me calling you
a liar. For some reasons I think the worst thing is disagreement
with you even after you present all your killer
100%-correct-and-ignore-everything-else arguments. Did I just call you a
liar again?
Sorry about that, I do understand I will be hurt by this more than you.

Whether Richard and Eric feel offended or hurt does not change whether
it is an offensive thing to say. As far as I can see the biggest impact
of your attitude here will be to make people think less of you.

 

[Flash Gordon]

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

That's right. Somehow I don't believe you. And somehow I don't want
bring names in this context. Those guys are not hostile, unlike you.

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

Nope, as I said. Still can't make a conclusion there isn't one.
I don't know way too many things to claim something doesn't exist
because I've never seen it.

So because others here can't think of a good reason to use long instead
of size_t and you can't prove there is never such a reason, we must all
assume there could be a good reason to not use the mechanisms provided
by the standard to deal with a problem?

I think you have it backwards. If you are claiming there is a reason to
avoid the mechanisms the standard provides to allow portability then it
is up to *you* to prove your point, not up to others to disprove it.

Good you used "quotes" here.

Probably for emphasis. I've never had to include a header just to get
size_t when I wanted it because I've somehow always without thinking
included a header (or more than one) that provides it.

If the headers in particular implementation are broken, then
they are broken. I don't blame the Standard for that. Not sure
if I blame "Standard headers". And not sure how it is relevant
to whether I use or do not use POSIX read and write.

Yet you are using broken headers and headers providing extensions (all
your examples being ones the standard allows them to do that will not
break any otherwise correct code) as a reason for not including them.
Broken headers is not a good reason to not use them since if you cannot
rely on the C implementation you cannot rely on it and need to use a
different one instead.

I know one. If a library has a bug, you call it perverse? I know
*lots*.

Provide ONE specific example where a library has a broken header (give
the name and version of the library) which is bad enough to cause
problems with otherwise correct code.

I'd think the developers carefully use % operator if it's broken
on some target platform. Is it broken somewhere, did it cause
problems for someone? You seem to imply it.

1+1 is broken on at least one implementation (well, it was something
fundamental like that), should we avoid adding that as a result? No, you
file a bug report on the library (or processor in this case) and tell
your user base not to use it because it is broken. I know, because I
work in a commercial organisation and we *do* tell them that they cannot
use certain things with our software because they are broken.

Well, I can't provide any examples of broken standard headers,
I have access only to two systems here, and I am not aware
of some famous example. Does it mean there isn't one? No.
Is there one? I have no idea. Do *I* avoid using standard
headers? *No*. Read the paragraph you replied to?

The contention of everyone else is that there is no implementation worth
bothering with that has headers sufficiently broken to be worth worrying
about. There is a very good reason for this, and such implementation
would be well publicised and boycotted until it was fixed, so a short
time after it is released it will be of historic interest only because
the free bugfix will be available.

Again, it is up to *you* to prove your contention that there are reasons
to avoid standard headers due to problems, because the purpose of the
standard is to provide you with the guarantees that you do not need to
worry about such things.

I'm glad you provided this useful information, even though it's
irrelevant.

It is entirely relevant since it shows that your suggesting WinMain as a
counter-example was *not* a valid counter-example.

> But since we're on it, implementation may provide
a separate translation unit which contains definition of main(),
which in turn calls my WinMain.

It can't if it is a hosted implementation. It is actually well known
that when compiling applications for the Window GUI using MS VC++ you
are using a freestanding implementation.

> I can ask implementation to do it
for me, and it'd be perfectly legal. I have no idea how exactly
it's done in MS implementation, do you? Come on, let's talk about
what's legal and what's not, exactly on point.

WinMain is legal because it is a FREESTANDING implementation, all
appearances to the contrary. When you invoke MS VC++ as a hosted
implementation *you* have to provide main, so it is not a counter example.

Sorry, what clash?

That is the point. If you (and this mythical library that has to avoid
use of standard headers) do not invade the implementation namespace then
there is no clash, so the headers declaring strdup is not a problem. If
you or the mythical third party library do then it is *your* code, or
that mythical library, that is broken *not* the standard header.

> If I don't define _GNU_SOURCE in some way, I
do *not* get declaration of strndup(). glibc provides strndup()
to me but I have to take special measures to use it.
If some library header has '#include <string.h>' then I can't
#define _GNU_SOURCE after it and get strndup() declaration.
If I do #define _GNU_SOURCE before, and the library includes
some more implementation headers, I could get some other stuff
changed, which I may or may not want.

Give exactly ONE example of something it will break where you or your
mythical library is not already broken due to invading the
implementations namespace.

> And this is exactly the
business for me, a user, not for library to decide which headers,
in what order, and how I use. (_GNU_SOURCE and strndup is
simply a trivial example, people say there are much worse
situations where header order matters)

People say the earth is flat, that does not make it true. People also
say the earth is not flat, and them saying that does not make it true
either.

But even if I wrote totally illegal code which worked fine, it'd be
stupid if some unrelated library broke it. It would be totally fine as
far as the standard is concerned, of course, UB and all that, so what?

For the record, I am not saying I am writing that evil code,
nor am I advocating writing it. (I know, it can't help, you'll
think I ask standard for something, moreover you will think I
ask you for something, and so on)

You are advocating that there are good reasons to write stupidly broken
code when writing a library, everyone else is saying you are wrong. If
you want to convince anyone that you are correct, or even that you have
a valid if mistaken point of view, then *you* have to provide some
concrete example, not hand waving and saying you know this library that
does it and you are sure that it is because of broken headers and they
have a good reason.

...


I may want the well-defined behavior which left undefined by
the standard. If the use of _GNU_SOURCE is documented by
implementation, I may use it. But it's not the point of course.


Who said it's a problem for C. Again, you are saying it like I am
claiming standard owes me something, standard is completely wrong,
and I invoke UB every day twice a day.
No, I am saying that library developers may have an attitude
of "user knows better what he's doing".

You are saying that the writer of a third party library has to do
something everyone else considers stupid to prevent it being broken when
you do something legal on a specific implementation. I say this is
complete rubbish and the writer of the third party library should use
the standard mechanisms provided. Either proved *real* *verifiable*
evidence of your claim that there are good reasons or accept that the
writers of that library have done the wrong thing.

 

[Richard Heathfield]

Flash Gordon said:

Yevgen Muntyan wrote, On 16/03/07 06:22:


Whether Richard and Eric feel offended or hurt does not change whether
it is an offensive thing to say.

Right. And for the record, disagreeing with me has never been cause for
offending me. Lots of people here have disagreed with me - you, no
doubt, Flash, for one - and then there's the Thompson Twins (Keith and
Dave Thompson), and Chris Torek, and Martin, and Chris Dollin, and
Steve, and and Brian, and Ben, and Dann, and plenty more besides - and
sometimes I've been incorrect, and they were right to disagree, and
sometimes I've been correct, and they were /still/ right to disagree,
since the ensuing discussions help to sort out the issue in everyone's
minds. And sometimes we've ended up agreeing to differ. But the mere
fact of disagreement is *not* sufficient to cause offence, and nor
should it be.

 

[Yevgen Muntyan]

Yevgen Muntyan wrote, On 16/03/07 06:22:

Since you have not named the library, the only other part in statement
you could be disagreeing with is the reason why we would want to know
which library it is. Are you saying that Eric might be mistaken about
why he wants to know the name of the library? If not (and that would be
a ridiculous thing for you to claim) then the logical conclusion is you
think he is lying about why he wants to know the name of the library.

I should be careful then, if someone jumps to calling people he doesn't
know incompetent, I must stay superpolite in order not to get in danger
of calling him a liar when he says fancy-shmancy "so we are warned...".

The last few posts in this thread by Richard and Eric do not seem to be
making ridiculous statements to me, only your posts seem to be doing that.

Um, Mr Richard didn't quote me calling him a liar, did he? It wasn't
about last few posts in this thread. Or do you mean Mr Heathfield is
liar? Then, I didn't mean Eric words. I said "Mr Heathfield". What I
said to Mr Richard has nothing to do with what I said to Eric Sosman.

Whether Richard and Eric feel offended or hurt does not change whether
it is an offensive thing to say.

So it's fine for Eric to insult other people by calling them
incompetent, but it was so bad from me to say an offensive thing?
And again, what I said to Richard is different. Note, I didn't
invite him nor I mentioned him here. He came whining I called
him a liar elsewhere. "Oh what are we gonna do!"

As far as I can see the biggest impact
of your attitude here will be to make people think less of you.

Perhaps. I do understand that you have to earn right to be an asshole,
like Mr Heathfield has.

Yevgen

 

[Yevgen Muntyan]

Yevgen Muntyan wrote: [... a lot ...]

Eric Sosman wrote: [... too much ...]

Perhaps it's time to review the bidding. This thread
began with your technical question about the implications of
a quiet change in the C99 Standard. I and others explained
how the existence of a size_t wider than unsigned long could
change a program's behavior. You wondered whether this meant
that Win64 was broken, and the consensus seemed to be that it
is. I went on to say that the breakage was unlikely to be
serious, and explained why I thought so. Among my reasons:
nobody would deliberately store size_t values in anything other
than a size_t -- like an unsigned long -- unless there were an
excellent reason to believe the values being stored would be
sufficiently small.

And that's when things got weird, or at least when they
started to elude my understanding. You mentioned a nameless
but useful library that stores sizes in unsigned long, and the
library's existence somehow made me a villain. You are worried
that the library's ill-advised choice of data type might make it
vulnerable to breakage when running on broken Win64, and this
worry somehow makes you angry at me.

I do not understand how the interaction of choices I did not
make and was not responsible for justifies blaming me for the
potential breakage. It's beyond my comprehension, and I give up.

Well, it wasn't quite like that. Let me quote:

> Perhaps. Or maybe it's because many vendors put lot of non-standard
> stuff into standard headers. Say, if you #include <string.h> and
> do not #define _GNU_SOURCE with glibc, then you don't get strndup()
> declaration. But then library (not the C library) may not mandate
> what you get and what you don't from the C library. So it would
> need to document its headers include <string.h>, <foo.h>, and whatnot.
> And then it must maintain that forever. Don't know, playing devil
> advocate here.

And then you said in particular

> Second, if you define reserved identifiers
> like _GNU_SOURCE you invoke undefined behavior. You may *want* the
> undefined behavior, but you can't ask the Standard to bless your
> perverted desires.

So you talked like I am justifying using _GNU_SOURCE or
I am justifying UB, and moreover I want standard to bless it.
But I said that the library developers may opt to *allow user*
invoke UB (this one in this particular case *is* defined and
documented), or use implementation-specific features and whatnot.
That was one part.

Another part is calling the library developers incompetent. I can
just as well say you are incompetent and prove it (except one
part which doesn't need proving): you are incompetent because
your software has bugs. Or not? I wouldn't say you're incompetent
because of that.

Oh well, whatever. It's beyond your comprehension that people
may not mean anything but what they're saying. You're reading
between the lines, but not what I put in there. I guess it's
the reason for you not understanding the lines either.

Yevgen

 

[Yevgen Muntyan]

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.

For what claim exactly? That there is such a library? Are you calling me
a liar? And no, I don't want to bring names in this context, regardless
of how people take my claims. Especially if they don't take them
seriously regardless. You know, if I am accused of asking standard to
bless using UB (read the thread if you like), then I can be said to fly
to Mars and whatnot. And then what?

So because others here can't think of a good reason to use long instead
of size_t and you can't prove there is never such a reason, we must all
assume there could be a good reason to not use the mechanisms provided
by the standard to deal with a problem?

I think you have it not even backwards. I said that some people *may*
have good reasons. If you say that fact of you, Eric, me, and two
other people not knowing such a good reason implies non-existence of
such a reason, then I will disagree.
But in fact, I was trying to make up reasons "why people would not
want to have standard headers included in their own headers which
do not use features from standard headers". It's in fact even not
very relevant to the "evil library", because it has dedicated type
to serve same purpose as size_t, and long instead of size_t was
in fact a mistake, and then there is backwards compatibility, api
stability and all that.
But you folks decided I am defending this particular thing, and
to justify that I accuse standard of causing all my problems. It
surely is easier to argue with.

I think you have it backwards. If you are claiming there is a reason to
avoid the mechanisms the standard provides to allow portability then it
is up to *you* to prove your point, not up to others to disprove it.

I am claiming this: my (and yours, and Eric's, and all the regulars
here) lack of knowledge about one particular obscure system does
*not* imply I (you, Eric, etc.) *know* something about it. If
I write code, I don't worry about those obscure systems. But I
admit a possibility of someone who does worry about obscure system
I never heard about. I do *not* claim existence of that system.
Not sure what I need to prove here.

Probably for emphasis.

I doubt it. Read the sentence. "Every module that performs I/O includes

I've never had to include a header just to get
size_t when I wanted it because I've somehow always without thinking
included a header (or more than one) that provides it.

Same thing. I rarely use size_t in fact. I did though have modules
which perform I/O and do not use stdio.h.

Yet you are using broken headers and headers providing extensions (all
your examples being ones the standard allows them to do that will not
break any otherwise correct code) as a reason for not including them.
Broken headers is not a good reason to not use them since if you cannot
rely on the C implementation you cannot rely on it and need to use a
different one instead.

This is a very wrong thing. There may be localized bugs which have
to be worked around. It's a source distribution world, you can't
say "Fnu compiler is broken, we shall not use it", you have to
work it around if it's not too hard. Seen gnulib?

Provide ONE specific example where a library has a broken header (give
the name and version of the library) which is bad enough to cause
problems with otherwise correct code.

So you can all jump around and yell "those guys are incompetent morons
how cool we are"?

1+1 is broken on at least one implementation (well, it was something
fundamental like that), should we avoid adding that as a result?

If your code is going to work on that implementation, yes.

No, you
file a bug report on the library (or processor in this case) and tell
your user base not to use it because it is broken.

Totally funny.

I know, because I
work in a commercial organisation and we *do* tell them that they cannot
use certain things with our software because they are broken.

Well, it's different world. You can't say "don't use glibc" or
"don't use FreeBSD C library" or "don't use operating system
you're using".

The contention of everyone else

"everyone else" is three people including you? Perhaps you are right,
I don't know. But I don't know enough to make such a conclusion.

is that there is no implementation worth
bothering with that has headers sufficiently broken to be worth worrying
about. There is a very good reason for this, and such implementation
would be well publicised and boycotted until it was fixed,

You are kidding, right? How about MS?
Oh, of course, you stopped generalizing and now you are talking about
size_t. Yes, I can't believe there is an implementation which doesn't
have size_t correctly defined in stddef.h. I somehow talked about
the general thing of people not wanting to use standard headers.
You can read it upthread.

so a short
time after it is released it will be of historic interest only because
the free bugfix will be available.

Again, it is up to *you* to prove your contention that there are reasons
to avoid standard headers due to problems,

I can't prove it, and I am not going to, since I simply don't know
if it's true. But I don't claim it's false just because I don't know
any example.

because the purpose of the
standard is to provide you with the guarantees that you do not need to
worry about such things.


It is entirely relevant since it shows that your suggesting WinMain as a
counter-example was *not* a valid counter-example.

You mean "mian" was relevant to anything?

It can't if it is a hosted implementation.

Yes it can, why can't it? Execution starts in main(), everything
is fine.

It is actually well known
that when compiling applications for the Window GUI using MS VC++ you
are using a freestanding implementation.

With MS VC++ maybe. I can use other compilers which *might* use
hidden main(). Can you *prove* (you love proofs don't you) my
favorite compiler doesn't do what I say? (I have no idea what
it does really)

WinMain is legal because it is a FREESTANDING implementation, all
appearances to the contrary. When you invoke MS VC++ as a hosted
implementation *you* have to provide main, so it is not a counter example.

Again, I don't know how to use MS VC++.

That is the point. If you (and this mythical library that has to avoid
use of standard headers) do not invade the implementation namespace then
there is no clash, so the headers declaring strdup is not a problem. If
you or the mythical third party library do then it is *your* code, or
that mythical library, that is broken *not* the standard header.

You didn't get it either.

#include <foo-thelib.h>
#define _GNU_SOURCE
#include <string.h>

void bar (void)
{
strndup ("33", 1);
}

If foo.h includes string.h, then strndup() won't be declared.
Whose problem is this? User's. Why does it happen? Because
user is stupid, he should #define _GNU_SOURCE at the very
beginning. Is the library right? No.

People say the earth is flat, that does not make it true. People also
say the earth is not flat, and them saying that does not make it true
either.

It's not about the truth. It's about you not having right to tell others
people earth is round (it's not, you know).

You are advocating that there are good reasons to write stupidly broken
code when writing a library,

Am I?

everyone else is saying you are wrong. If
you want to convince anyone that you are correct, or even that you have
a valid if mistaken point of view, then *you* have to provide some
concrete example, not hand waving and saying you know this library that
does it and you are sure that it is because of broken headers and they
have a good reason.


You are saying that the writer of a third party library has to do
something everyone else considers stupid to prevent it being broken when
you do something legal on a specific implementation. I say this is
complete rubbish and the writer of the third party library should use
the standard mechanisms provided. Either proved *real* *verifiable*
evidence of your claim that there are good reasons or accept that the
writers of that library have done the wrong thing.

Still, I can't do either. I can't accept something has done a wrong
thing simply because I don't know the reason he did it. If you can
it's your right. Of course, your opinion is backed up by opinions
of other three people in this newsgroup, of yeah, collective wisdom.

Just tell, why does gnulib exist, why does it have so many wrappers
for so many *standard* things? Because people working on it are
stupid?

Yevgen

 

[Yevgen Muntyan]

(If you use ssize_t at all, you have a problem, because that's not an
ISO type and the idea behind it is broken; the only valid reason to have
it in the first place is covered by ptrdiff_t.)

However, if you use a library and you find you can't trust it, your
options are basically to choose a different library, to roll your own,
or to accept that your supervisor doesn't know what he's talking about
and drink the flavorade.

Oh well, it's glib, and you're talking nonsense. *If* I don't trust
it lalala. I do trust it.

Discussing with yourself whether there's a
theoretical possibility of brokenness when you already know that you
will not be able to stop the breakage is reason to file a defect report
with your managers, not reason to fret about it.


So? What does that have to do with the price of fish?

#include <glib.h>
#define _GNU_SOURCE
#include <string.h>
#undef _GNU_SOURCE
#include <stdlib.h>

void foo (void)
{
strndup ("d", 1);
}

This code is broken if glib.h #include's string.h. If you were a glib
developer (which I guess is good you aren't), you could decide it's not
a good thing. If it does need string.h (which it doesn't), it would
need to document it, and *always* include it, forever. I have no idea
what funny target platforms considerations may affect desicions like
this. glib is not a fancy standard-C-only library, and it can't rely
solely on guarantees made by the C standard.

You need functions from <string.h>, you #include <string.h>, and you get
size_t for free. Ditto with <stdio.h>, and all the others. If you choose
not to #include a header you should #include because you just _might_
one day have to deal with Ganuck, the difference between unsigned long
and size_t is the least of your problems; getting a grip on your
priorities is much more important.

The difference between long and size_t has nothing to with this headers
business in fact. Try reading my post where I brought it in.

Yevgen

 

[Flash Gordon]

Yevgen Muntyan wrote, On 16/03/07 15:26:

I should be careful then, if someone jumps to calling people he doesn't
know incompetent, I must stay superpolite in order not to get in danger
of calling him a liar when he says fancy-shmancy "so we are warned...".

You should always try to stay polite. So should Richard (all of them),
Eric, myself and everyone else. Not everyone stays polite all the time
and some may not even try, but someone else being impolite does not give
you (or anyone else) license to be impolite. You should be especially
careful of saying things that could be interpreted as implying someone
is lying.

Um, Mr Richard didn't quote me calling him a liar, did he? It wasn't
about last few posts in this thread. Or do you mean Mr Heathfield is
liar? Then, I didn't mean Eric words. I said "Mr Heathfield". What I
said to Mr Richard has nothing to do with what I said to Eric Sosman.

I've never noticed either Richard Heathfield or Eric lying. I've seen
them make mistakes, and I've certainly disagreed with Richard in the
past (I don't keep score, but he has probably been right more often than
me). However the way you have been attacking in this thread I can
certainly see how what you've said can be interpreted as implying they
are lying, in particular what you say above about Eric's comment.

So it's fine for Eric to insult other people by calling them
incompetent, but it was so bad from me to say an offensive thing?

The evidence you present suggests that they are incompetent. I suspect
however that what was intended, even if not said, is that if they are
doing what you say for the reasons they give then they are incompetent,
otherwise you are misrepresenting them. Note the conditional. Currently
I would not want to wager which it is, and your failure to let us know
the library in question only makes things worse.

And again, what I said to Richard is different. Note, I didn't
invite him nor I mentioned him here. He came whining I called
him a liar elsewhere. "Oh what are we gonna do!"

Any post here is an invitation for *everyone* to comment. I suggest that
in this case Richard was referring to things you have said either else
where in this thread or in another thread.

Perhaps. I do understand that you have to earn right to be an asshole,
like Mr Heathfield has.

You have to earn respect, and violently disagreeing with very
knowledgeable people without being prepared to provide any significant
backing for your argument is a good way to loose any respect people have
for you and prevent them from respecting you in the future.

Respect earns you a certain latitude. It may not be fair, but it is the
way human interactions work. So yes, you do have to earn the right to be
an asshole if you want to get away with it, which is not to say that I
consider Richard to be an asshole.

 

[Dave Vandervies]

I've never had to include a header just to get
size_t when I wanted it because I've somehow always without thinking
included a header (or more than one) that provides it.

I can make a stronger statement than that:
I've started writing code, decided I wanted to use a size_t, and therefore
added (or made a mental note to add) a "#include <stddef.h>"...
But every time, I've ended up (often as the next thing I do) adding a
call to a standard library function declared in a header that defines
size_t anyways. So I've never had a reason to #include <stddef.h>
by the time I let a compiler see the code.


dave

--
Dave Vandervies (e-mail address removed)

No? Then I should find something else or (how horrible!) have some work done.

WORK??? I think that would be overreacting.
--Peter Pichler and Richard Heathfield in comp.lang.c

 

[Yevgen Muntyan]

Win64 itself doesn't claim conformance with anything; since it's not a
complete implementation, it couldn't anyways. It's merely an API.

Win64 isn't, "visual C runtime library" or whatever it's called with
their compiler is. The conformance claim is at msdn.com for instance,
you can find it linked from clc wiki.

 

[Yevgen Muntyan]

Yevgen Muntyan wrote, On 16/03/07 15:26:

Yevgen Muntyan wrote, On 16/03/07 06:22: [snip]
Dear Mr Heathfield, I do understand that saying in public you're not
telling the truth is a bad offense. But when you're making totally
ridiculous statements to justify your rudeness, I simply can't resist.

The last few posts in this thread by Richard and Eric do not seem to
be making ridiculous statements to me, only your posts seem to be
doing that.

Um, Mr Richard didn't quote me calling him a liar, did he? It wasn't
about last few posts in this thread. Or do you mean Mr Heathfield is
liar? Then, I didn't mean Eric words. I said "Mr Heathfield". What I
said to Mr Richard has nothing to do with what I said to Eric Sosman.

I've never noticed either Richard Heathfield or Eric lying. I've seen
them make mistakes, and I've certainly disagreed with Richard in the
past (I don't keep score, but he has probably been right more often than
me). However the way you have been attacking in this thread I can
certainly see how what you've said can be interpreted as implying they
are lying, in particular what you say above about Eric's comment.

Um, I am attacking, huh? Okay.

The evidence you present suggests that they are incompetent.

Bullshit.

 

[CBFalconer]

.... snip ...

You didn't get it either.

#include <foo-thelib.h>
#define _GNU_SOURCE
#include <string.h>

void bar (void)
{
strndup ("33", 1);
}

If foo.h includes string.h, then strndup() won't be declared.
Whose problem is this? User's. Why does it happen? Because
user is stupid, he should #define _GNU_SOURCE at the very
beginning. Is the library right? No.

If your mythical user includes the "#define _GNU_SOURCE" line he is
a known C idiot, who is invading the implementors namespace and
ensuring that overall behaviour is undefined.