Yevgen Muntyan wrote, On 16/03/07 16:12:
For what claim exactly? That there is such a library?
Yes.
> 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.
If you say something exists but you are not prepared to tell people your
references you cannot expect to be taken seriously.
> 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?
I did not comment on that part of the argument because I did not want to
trace it back.
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.
The version of the library originally introducing long instead of size_t
is the "evil library" so you still have it.
Also library frequently break backwards compatibility in various ways on
major upgrades.
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.
The thing that got me was you appearing to be claiming that an
implementation with broken headers was a good reason to avoid including
them and therefore not having size_t available.
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.
The point of using the facilities provided by the standard headers is so
that you do not have to worry about obscure systems since the
implementer has done the worrying for you.
I doubt it. Read the sentence. "Every module that performs I/O includes
Same thing. I rarely use size_t in fact. I did though have modules
which perform I/O and do not use stdio.h.
So you are using things outside of standard C. Now what would be broken
if you included one of the standard headers?
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?
Yes, I've seen it. It does not seem to mention support for broken
implementations, although it does provide stuff for pre-C89 implementations.
So you can all jump around and yell "those guys are incompetent morons
how cool we are"?
No, to make the point.
If your code is going to work on that implementation, yes.
Actually, when it was found that the Pentium (I think it was) had a bug
like this there was a major shout about it and MS release a new version
of their compiler (their C implementation was effectively broken by it)
that worked around the processor bug thus leading to a non-broken
implementation. So yes, all the writers of software (or enough) shouted
and screamed about the C implementation now being broken and waited for
it to be fixed instead of working around the problem themselves.
I was not one to raise bug reports on the Pentium, but people *did* and
it got fixed but providers of implementations providing implementations
that worked despite the processor bug and Intel fixing the processor.
What I have done is told customers that given versions of libraries were
broken and that they had to upgrade. I've also told them that they have
to upgrade to newer version of complete OSs. My customers are orders of
magnitude larger than the company I work for.
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".
I can do it. I know because I HAVE done it. Let's see if I can remember
it...
We told customers they had to upgrade to SCO 5.0.5 because the Java
implementations available for earlier versions were not good enough...
We later told them that they had to upgrade from SCO to Linux because
SCO various libraries we wanted to use were not available on SCO...
We also told another that they would have to upgrade from AIX 4.3 to
either Linux or an up to date version of AIX due to library problems...
We have also told customers when they have reported problems and we have
seen that their systems were out of date to "patch up to the latest
version and test again, if there is still a problem we will look at it
then." So they had to update before we would even look to see if the
problem was in out software or the library!
"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.
Any such implementation would be basically unusable so it would not survive.
You are kidding, right? How about MS?
When building with Visual Studio in include their standard headers
without any problems. So what about MS? They are not an example of such
a broken system.
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.
I claim that there has been no implementation since 1995 claiming
conformance to any version of the C standard that has been broken for as
long as a month such that including the standard headers in conforming
mode would break correct code. I further claim that even in
non-conforming mode if you avoid anything that clashes with documented
extensions it would still not break.
I am *not* talking specifically about size_t, I am talking about
including *any* standard header.
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.
I do claim it is true because I have some limited understanding of
commercial and open-source realities. The reality is that no one can be
bothered to deal with severely broken systems unless they are being paid
a lot of money specifically to do it. So any implementation broken badly
enough that including standard headers is not safe will simply not be used.
You mean "mian" was relevant to anything?
Yes. If an implementation is so broken that including standard headers
is not safe then it is so broken that anything could be wrong including
the spelling of main.
Yes it can, why can't it? Execution starts in main(), everything
is fine.
If you cannot write your own main function and have that as the entry
point for your program then by *definition* it is not a conforming
hosted 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)
The proof is the definition of a hosted implementation given by the C
standard. It states that the entry point to the program that *you* write
is main, so if the entry point to your code is anything other than main
it does not meet that definition.
Again, I don't know how to use MS VC++.
That I can believe. A lot of people don't know how to use it properly as
a C compiler. My statement is still true.
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.
Actually, I believe that if you do:
#define _GNU_SOURCE
#include <foo-thelib.h>
#include <string.h>
void bar (void)
{
strndup ("33", 1);
}
It will all work perfectly unless foo-thelib.h invades the
implementation name space, in which case foo-thelib.h is broken. The
implementation provided headers are perfectly OK.
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).
Freedom of speech. I've got the right to tell you that. Equally you have
the right to tell me that I am wrong. However, that is not what is
important here. What is important is what is true and what isn't, if you
don't think that then I think a technical group is the wrong place for you.
That's how it seemed.
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.
Another good reason for providing what you believe are example. Then
people can explain why it was wrong or be convinced that there actually
is a good reason under some situation.
> 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?
It exists to aid porting GNU, part of which *is* an implementation.
There are specific reasons why it still supports pre-C89 implementations
(actually, it is only the library they support as pre-C89). An
implementation no having been upgraded to C89 is not broken as such,
just old (or, rather, ancient), but supporting it requires wrapping
various standard library functions and dealing with not having standard
headers, or them not having been upgraded to match the C89 standard.
So it is *not* an example of working around broken implementations, only
an example of comparability with ancient systems, and they are slowly
moving the goal posts forward.
It also wraps some functions to provide consistent behaviour where the
standard does not require it, for example wrapping malloc so that their
wrapped version when passed a size of 0 will try to allocate a byte and
so return a non-NULL value if possible.
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.
