C89, size_t, and long
Yevgen Muntyan
I was reading C99 Rationale, and it has the following two QUIET CHANGE
paragraphs:
6.5.3.4: "With the introduction of the long long and extended integer
types, the sizeof operator may yield a value that exceeds the range
of an unsigned long."
6.5.6: "With the introduction of the long long and extended integer
types, the subtraction of pointers may return a value that exceeds the
range of a long."
Was it required by C89 that result of sizeof() fits into unsigned long,
and that pointer subtraction result fits into long? If yes, then MS
Win64 implementation is not C89-conforming (while sizeof case may be
arguable, I guess, we certainly can ask to malloc more than ULONG_MAX
bytes, and get pointer arithmetics which needs more than (unsigned)
long). If no, why these two paragraphs, if programs which relied on long
being big enough were already broken?
Yevgen
Eric Sosman
> Hey,
>
> I was reading C99 Rationale, and it has the following two QUIET CHANGE
> paragraphs:
>
> 6.5.3.4: "With the introduction of the long long and extended integer
> types, the sizeof operator may yield a value that exceeds the range
> of an unsigned long."
>
> 6.5.6: "With the introduction of the long long and extended integer
> types, the subtraction of pointers may return a value that exceeds the
> range of a long."
>
> Was it required by C89 that result of sizeof() fits into unsigned long,
> and that pointer subtraction result fits into long?
"Yes" and "Almost," respectively. C89 offered a fixed
set of integer types, of which {,un}signed long was the widest.
The implementation was free to provide additional types that
behaved like integers, but they were not "integer types" as
C89 defined them. C89 also required that size_t and ptrdiff_t
be aliases for "integer types," so they could not be wider than
long. If an implementation offered wider types, they were not
"integer types" and hence were not candidates for size_t and
ptrdiff_t.
On machines whose longs are the same width as their pointers
(more generally, no wider than their pointers), this means that
ptrdiff_t cannot be wide enough to express the result of all
pointer subtractions. An easy example:
char *p = malloc(LONG_MAX + 2u); /* assume success */
char *q = p + LONG_MAX + 2u;
ptrdiff_t delta = q - p;
We will now have p < q but (probably) delta < 0.
> If yes, then MS
> Win64 implementation is not C89-conforming (while sizeof case may be
> arguable, I guess, we certainly can ask to malloc more than ULONG_MAX
> bytes, and get pointer arithmetics which needs more than (unsigned)
> long). If no, why these two paragraphs, if programs which relied on long
> being big enough were already broken?
I don't know MS' Win64 implementation well enough to comment
on whether it's broken or not. As for programs that assumed
size_t and ptrdiff_t were no wider than long, no: They were not
broken under C89's rules, because C89 implied the truth of the
assumption. C99 changed the rules, allowing the implementation-
defined "exotic" types to be counted among the "integer types,"
and this change could break some programs that relied on the old
rule. Hence the "Quiet Change" warnings.
Yevgen Muntyan
It has 32-bit long, same as int, and naturally 64-bit size_t.
> As for programs that assumed
> size_t and ptrdiff_t were no wider than long, no: They were not
> broken under C89's rules, because C89 implied the truth of the
> assumption.
Then these programs may be broken on Win64, right? Say, this code:
void do_something (void *buf, unsigned long len)
{
memset (buf, 1, len);
}
int main (void)
{
size_t i;
size_t size = BIG_NUMBER;
char *p = malloc (size);
if (p)
{
do_something (p, size);
assert (p[size-1]);
}
return 0;
}
BIG_NUMBER can be defined as some square root of SIZE_MAX+1 multiplied
by two or something, so we don't need to invent functions which get
us a big buffer. I guess MS estimated somehow how much of their code
uses long as 32-bit int, and decided it's more than code which uses
unsigned long as size_t. Anyway, is MS Win64 implementation not
C89-conforming (it's an important thing, isn't it)? Or I do miss
something?
Thanks,
Yevgen
Eric Sosman
> Eric Sosman wrote:
>
>>Yevgen Muntyan wrote On 03/14/07 14:26,:
>>>Was it required by C89 that result of sizeof() fits into unsigned long,
>>>If yes, then MS
>>>Win64 implementation is not C89-conforming (while sizeof case may be
>>>arguable, I guess, we certainly can ask to malloc more than ULONG_MAX
>>>bytes, and get pointer arithmetics which needs more than (unsigned)
>>
>> I don't know MS' Win64 implementation well enough to comment
>>on whether it's broken or not.
>
> It has 32-bit long, same as int, and naturally 64-bit size_t.
If size_t is wider than long, the implementation cannot
conform to C89. It could, however, conform to C99, with
size_t being as wide as long long or as some other wide type.
One of the (many) things I don't know about MS Win64 is what
standards it claims to conform to.
>>As for programs that assumed
>>size_t and ptrdiff_t were no wider than long, no: They were not
>>broken under C89's rules, because C89 implied the truth of the
>>assumption.
>
> Then these programs may be broken on Win64, right? Say, this code:
>
> void do_something (void *buf, unsigned long len)
> {
> memset (buf, 1, len);
> }
>
> int main (void)
> {
> size_t i;
> size_t size = BIG_NUMBER;
> char *p = malloc (size);
> if (p)
> {
> do_something (p, size);
> assert (p[size-1]);
> }
> return 0;
> }
If malloc() succeeds, this program works under C89 but
might not work on a C99 implementation.
> [...] Anyway, is MS Win64 implementation not
> C89-conforming (it's an important thing, isn't it)? Or I do miss
> something?
From your description, it cannot be a conforming C89
implementation. Is that important? Well, to whom?
Yevgen Muntyan
> Yevgen Muntyan wrote On 03/14/07 15:14,:
>> Eric Sosman wrote:
>>
>>> Yevgen Muntyan wrote On 03/14/07 14:26,:
>>>> [...]
>>>> Was it required by C89 that result of sizeof() fits into unsigned long,
>>>> and that pointer subtraction result fits into long? [...]
>>>> If yes, then MS
>>>> Win64 implementation is not C89-conforming (while sizeof case may be
>>>> arguable, I guess, we certainly can ask to malloc more than ULONG_MAX
>>>> bytes, and get pointer arithmetics which needs more than (unsigned)
>>>> long). [...]
>>> I don't know MS' Win64 implementation well enough to comment
>>> on whether it's broken or not.
>> It has 32-bit long, same as int, and naturally 64-bit size_t.
>
> If size_t is wider than long, the implementation cannot
> conform to C89. It could, however, conform to C99, with
> size_t being as wide as long long or as some other wide type.
> One of the (many) things I don't know about MS Win64 is what
> standards it claims to conform to.
It claims conformance to C90. It does not conform to C99.
...
>> [...] Anyway, is MS Win64 implementation not
>> C89-conforming (it's an important thing, isn't it)? Or I do miss
>> something?
>
> From your description, it cannot be a conforming C89
> implementation. Is that important? Well, to whom?
Well, to people who want to write code which would work on win64.
Yevgen
Eric Sosman
> Eric Sosman wrote:
>>
>> If size_t is wider than long, the implementation cannot
>
> It claims conformance to C90. It does not conform to C99.
In that case, the claim is incorrect, and testably so:
size_t u = -1;
unsigned long v = u;
assert (u == v);
>>>[...] Anyway, is MS Win64 implementation not
>>>C89-conforming (it's an important thing, isn't it)? Or I do miss
>>>something?
>>
>> From your description, it cannot be a conforming C89
>>implementation. Is that important? Well, to whom?
>
>
> Well, to people who want to write code which would work on win64.
Observe that this nonconformance only affects code that
does any of
- Type-punning via unions or pointers to access a size_t
object as an unsigned long or vice versa (or similar punning
between ptrdiff_t and signed long). Such code is broken already
under all versions of the Standard, so it doesn't bother me if
MS causes additional breakage.
- Computing sizes > ULONG_MAX bytes (>= 4GB, in this case)
and converting them to unsigned long. First, you'd need to
have a reason to compute such large sizes; all right, on a
64-bit system I'll grant that such reasons may arise. But
then you'd need to write unsigned long instead of size_t to
get into trouble; why would you do that?
- To answer the question, you might do that to print the
size_t value using "%lu" or something of the kind. In this
case, you could get the wrong answer printed, which might or
might not affect the behavior of the rest of the program. As
far as I can imagine, this is the only case you need to worry
about, the only case in "legitimate" code where the fact that
size_t is wider than unsigned long could cause trouble. Be
on your guard!
Keith Thompson
> Eric Sosman wrote:
[...]
>> I don't know MS' Win64 implementation well enough to comment
>> on whether it's broken or not.
>
> It has 32-bit long, same as int, and naturally 64-bit size_t.
How is size_t defined? Does the implementation provide an "unsigned
long long" type and make size_t an alias for that? Or does it use
some non-standard syntax for its 64-bit types?
--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Yevgen Muntyan
> Yevgen Muntyan wrote On 03/14/07 15:57,:
>> Eric Sosman wrote:
>>> If size_t is wider than long, the implementation cannot
>>> conform to C89. [...]
>> It claims conformance to C90. It does not conform to C99.
>
> In that case, the claim is incorrect, and testably so:
>
> size_t u = -1;
> unsigned long v = u;
> assert (u == v);
>
>>>> [...] Anyway, is MS Win64 implementation not
>>>> C89-conforming (it's an important thing, isn't it)? Or I do miss
>>>> something?
>>> From your description, it cannot be a conforming C89
>>> implementation. Is that important? Well, to whom?
>>
>> Well, to people who want to write code which would work on win64.
>
> Observe that this nonconformance only affects code that
> does any of
>
>
> - Computing sizes > ULONG_MAX bytes (>= 4GB, in this case)
> and converting them to unsigned long. First, you'd need to
> have a reason to compute such large sizes; all right, on a
> 64-bit system I'll grant that such reasons may arise. But
> then you'd need to write unsigned long instead of size_t to
> get into trouble; why would you do that?
Answer to "why" may be wrong, but it won't change much if it's
already done. There is lot of code which assumes long
is big enough, and one must be aware of it (it's a real issue,
with real software).
There is more important thing to it. This single non-conformance
is simple: use appropriate types and you're good. But if MS broke
this thing (which breaks code, i.e. it's not some academic issue),
then what else is broken? It's a psychological issue (paranoia?).
> - To answer the question, you might do that to print the
> size_t value using "%lu" or something of the kind. In this
> case, you could get the wrong answer printed, which might or
> might not affect the behavior of the rest of the program. As
> far as I can imagine, this is the only case you need to worry
> about, the only case in "legitimate" code where the fact that
> size_t is wider than unsigned long could cause trouble.
You're saying it's legitimate. But how is casting size_t
to unsigned long more legitimate than
int process_some_data (char *data, unsigned long len);
Yevgen
Jack Klein
<muntyan.r...@tamu.edu> wrote in comp.lang.c:
What do you mean by "already broken"? Neither 64-bit Windows, nor the
AMD 64-bit extension to the x86 instruction set, existed before the
C99 standard.
--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~ajo/docs/FAQ-acllc.html
Yevgen Muntyan
> Yevgen Muntyan <muntyan.r...@tamu.edu> writes:
>> Eric Sosman wrote:
> [...]
>>> I don't know MS' Win64 implementation well enough to comment
>>> on whether it's broken or not.
>> It has 32-bit long, same as int, and naturally 64-bit size_t.
>
> How is size_t defined? Does the implementation provide an "unsigned
> long long" type and make size_t an alias for that? Or does it use
> some non-standard syntax for its 64-bit types?
It doesn't have long long, it has builtin __int64, and
typedef __int64 intptr_t;
typedef unsigned __int64 uintptr_t;
typedef __int64 ptrdiff_t;
typedef unsigned __int64 size_t;
Yevgen
Yevgen Muntyan
> On Wed, 14 Mar 2007 18:26:50 GMT, Yevgen Muntyan
> <muntyan.r...@tamu.edu> wrote in comp.lang.c:
>
>> Hey,
>>
>> I was reading C99 Rationale, and it has the following two QUIET CHANGE
>> paragraphs:
>>
>> 6.5.3.4: "With the introduction of the long long and extended integer
>> types, the sizeof operator may yield a value that exceeds the range
>> of an unsigned long."
>>
>> 6.5.6: "With the introduction of the long long and extended integer
>> types, the subtraction of pointers may return a value that exceeds the
>> range of a long."
>>
>> Was it required by C89 that result of sizeof() fits into unsigned long,
>> and that pointer subtraction result fits into long? If yes, then MS
>> Win64 implementation is not C89-conforming (while sizeof case may be
>> arguable, I guess, we certainly can ask to malloc more than ULONG_MAX
>> bytes, and get pointer arithmetics which needs more than (unsigned)
>> long). If no, why these two paragraphs, if programs which relied on long
>> being big enough were already broken?
>>
>> Yevgen
>
> What do you mean by "already broken"? Neither 64-bit Windows, nor the
> AMD 64-bit extension to the x86 instruction set, existed before the
> C99 standard.
*If* Win64 is C90-conforming, then long smaller than size_t is fine,
then a program which uses unsigned long instead of size_t is broken
as far as C90 is concerned (of course it depends on the usage of
those types), so C99 doesn't need to say this is a quiet change.
Yevgen
Richard Bos
> Eric Sosman wrote:
> > - To answer the question, you might do that to print the
> > size_t value using "%lu" or something of the kind. In this
> > case, you could get the wrong answer printed, which might or
> > might not affect the behavior of the rest of the program. As
> > far as I can imagine, this is the only case you need to worry
> > about, the only case in "legitimate" code where the fact that
> > size_t is wider than unsigned long could cause trouble.
>
> You're saying it's legitimate.
Well, he says it's "legitimate". In this case, the scare quotes are
important. It's not more or less legal than other cases; but in this
case, it's inevitable, while in other cases, it can be avoided.
> But how is casting size_t to unsigned long more legitimate than
>
> int process_some_data (char *data, unsigned long len);
In this case, you could easily make len a size_t instead. Making it an
unsigned long instead is legal C90, but relying on this legality is
perhaps not a good idea, and making it a size_t means you get a
declaration which is more self-documenting for the cost, not of more,
but even of _less_ typing, which patently _is_ a good idea.
In the case of printf(), there's nothing you can easily do in C90 to
avoid having to cast a size_t to an unsigned long. C99 has "%zu", but
that's no help in C90, which does not.
Therefore, assuming a size_t is no larger than an unsigned long is
_legal_ in all cases in C90; but you only have _good reason_ for doing
so in the printf() case.
Richard
Yevgen Muntyan
> Yevgen Muntyan <muntyan.r...@tamu.edu> wrote:
>
>> Eric Sosman wrote:
>>> - To answer the question, you might do that to print the
>>> size_t value using "%lu" or something of the kind. In this
>>> case, you could get the wrong answer printed, which might or
>>> might not affect the behavior of the rest of the program. As
>>> far as I can imagine, this is the only case you need to worry
>>> about, the only case in "legitimate" code where the fact that
>>> size_t is wider than unsigned long could cause trouble.
>> You're saying it's legitimate.
>
> Well, he says it's "legitimate". In this case, the scare quotes are
> important. It's not more or less legal than other cases; but in this
> case, it's inevitable, while in other cases, it can be avoided.
>
>> But how is casting size_t to unsigned long more legitimate than
>>
>> int process_some_data (char *data, unsigned long len);
>
> In this case, you could easily make len a size_t instead.
*If* I can change the code. It's why I was confused: I can't imagine
why I would print a size_t value using unsigned long on Win64 platform,
but I can easily imagine how I use code which uses long instead
of ssize_t and unsigned long instead of size_t. Thanks for
clarification.
> Making it an
> unsigned long instead is legal C90, but relying on this legality is
> perhaps not a good idea, and making it a size_t means you get a
> declaration which is more self-documenting for the cost, not of more,
> but even of _less_ typing, which patently _is_ a good idea.
By the way, it seems that some people avoid #includ'ing headers like
stddef.h in library headers due to bugs in C implementations
or for some other obscure reasons. I'd think it adds to this
issue: you can use long for free, it's builtin, but to get
size_t you need an extra header.
Yevgen
Richard Bos
> Richard Bos wrote:
> > Yevgen Muntyan <muntyan.r...@tamu.edu> wrote:
> >
> >> But how is casting size_t to unsigned long more legitimate than
> >>
> >> int process_some_data (char *data, unsigned long len);
> >
> > In this case, you could easily make len a size_t instead.
>
> *If* I can change the code.
If _you_ can't change the code, I would advise not to worry about
whether the ideas expressed in it are legitimate or not; leave that to
the people who did design and do maintain it.
> By the way, it seems that some people avoid #includ'ing headers like
> stddef.h in library headers due to bugs in C implementations
> or for some other obscure reasons. I'd think it adds to this
> issue: you can use long for free, it's builtin, but to get
> size_t you need an extra header.
Given that size_t is also #defined in <stdio.h>, <stdlib.h> and
<string.h>, probably the three most #included headers, without which I
can hardly imagine a useful ISO C program of any reasonable size, as
well as in <time.h> and <wchar.h>, IMO people who do this should do a
reality check.
Richard
Yevgen Muntyan
> Yevgen Muntyan <muntyan.r...@tamu.edu> wrote:
>
>> Richard Bos wrote:
>>> Yevgen Muntyan <muntyan.r...@tamu.edu> wrote:
>>>
>>>> But how is casting size_t to unsigned long more legitimate than
>>>>
>>>> int process_some_data (char *data, unsigned long len);
>>> In this case, you could easily make len a size_t instead.
>> *If* I can change the code.
>
> If _you_ can't change the code, I would advise not to worry about
> whether the ideas expressed in it are legitimate or not; leave that to
> the people who did design and do maintain it.
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. This Win64 thing is funny, because no other 'popular' system
has small long type. Good or bad, but lot of useful software is written
under many assumptions like 8-bit bytes, ASCII, long >= size_t. Simply
ignoring it won't always work since you might actually need that
software (you know, libraries which have useful stuff).
>> By the way, it seems that some people avoid #includ'ing headers like
>> stddef.h in library headers due to bugs in C implementations
>> or for some other obscure reasons. I'd think it adds to this
>> issue: you can use long for free, it's builtin, but to get
>> size_t you need an extra header.
>
> Given that size_t is also #defined in <stdio.h>, <stdlib.h> and
> <string.h>, probably the three most #included headers, without which I
> can hardly imagine a useful ISO C program of any reasonable size, as
> well as in <time.h> and <wchar.h>, IMO people who do this should do a
> reality check.
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.
Yevgen
Eric Sosman
> Richard Bos wrote:
>> Yevgen Muntyan <muntyan.r...@tamu.edu> wrote:
>>
>>> Richard Bos wrote:
>>>> Yevgen Muntyan <muntyan.r...@tamu.edu> wrote:
>>>>
>>>>> But how is casting size_t to unsigned long more legitimate than
>>>>>
>>>>> int process_some_data (char *data, unsigned long len);
>>>> In this case, you could easily make len a size_t instead.
>>> *If* I can change the code.
>>
>> If _you_ can't change the code, I would advise not to worry about
>> whether the ideas expressed in it are legitimate or not; leave that to
>> the people who did design and do maintain it.
>
> 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.
Yes, indeed. Your problem is that you are using a library
written by somebody who didn't understand C, or who chose to be
deliberately perverse in the way he used it. When the library
writer is hostile or incompetent, you certainly have a problem.
> This Win64 thing is funny, because no other 'popular' system
> has small long type. Good or bad, but lot of useful software is written
> under many assumptions like 8-bit bytes, ASCII, long >= size_t. Simply
> ignoring it won't always work since you might actually need that
> software (you know, libraries which have useful stuff).
Libraries that have useful stuff *and* for which no practical
alternatives exist *and* were written by incompetents or hostiles.
Do you have a specific library in mind, or are you "just
supposing?" If the latter, drop it until the situation actually
arises. If the former, please tell us about it so we'll be warned
not to use that organization's products.
>>> By the way, it seems that some people avoid #includ'ing headers like
>>> stddef.h in library headers due to bugs in C implementations
>>> or for some other obscure reasons. I'd think it adds to this
>>> issue: you can use long for free, it's builtin, but to get
>>> size_t you need an extra header.
>>
>> Given that size_t is also #defined in <stdio.h>, <stdlib.h> and
>> <string.h>, probably the three most #included headers, without which I
>> can hardly imagine a useful ISO C program of any reasonable size, as
>> well as in <time.h> and <wchar.h>, IMO people who do this should do a
>> reality check.
>
> 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.
You're playing something, yes, but I don't recognize the tune.
Proposition: There is *no* reason to use unsigned long instead
of size_t. None. Nada. Zero. Zip. Nulla. Every module that
performs I/O includes <stdio.h> and has size_t defined; every
module that works with strings includes <string.h> and has size_t
defined; every module that calls malloc() includes <stdlib.h> and
has size_t defined. The definitions of size_t are so rampant in
the standard headers that it is almost as universal as a keyword.
The excuse "I don't want to include standard headers because they
might be broken" is hopelessly fallacious: If you don't trust the
headers, why would you trust the library? Do you provide a mian()
function just in case the implementation has a spelling error?
As for standard headers providing non-Standard definitions:
First, there are identifiers that are reserved for future use,
meaning that the standard headers are free to define them if
they so choose. You are not allowed to use `isosceles' as an
identifier with external linkage, and if you do use it you are at
fault and not the headers. 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. SAFUYOYO.
--
Eric Sosman
eso...@acm-dot-org.invalid
Yevgen Muntyan
> Yevgen Muntyan wrote:
>> Richard Bos wrote:
>>> Yevgen Muntyan <muntyan.r...@tamu.edu> wrote:
>>>
>>>> Richard Bos wrote:
>>>>> Yevgen Muntyan <muntyan.r...@tamu.edu> wrote:
>>>>>
>>>>>> But how is casting size_t to unsigned long more legitimate than
>>>>>>
>>>>>> int process_some_data (char *data, unsigned long len);
>>>>> In this case, you could easily make len a size_t instead.
>>>> *If* I can change the code.
>>>
>>> If _you_ can't change the code, I would advise not to worry about
>>> whether the ideas expressed in it are legitimate or not; leave that to
>>> the people who did design and do maintain it.
>>
>> 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.
>
> Yes, indeed. Your problem is that you are using a library
> written by somebody who didn't understand C, or who chose to be
> deliberately perverse in the way he used it. When the library
> writer is hostile or incompetent, you certainly have a problem.
Well, I'd choose lighter words than "somebody who didn't
understand C" and "incompetent", but it won't change a thing of course.
Thing is: there is a problem which doesn't exist on sane systems
which use sensible types but which exists on Win64. Why it exists
is another problem.
>> This Win64 thing is funny, because no other 'popular' system
>> has small long type. Good or bad, but lot of useful software is written
>> under many assumptions like 8-bit bytes, ASCII, long >= size_t. Simply
>> ignoring it won't always work since you might actually need that
>> software (you know, libraries which have useful stuff).
>
> Libraries that have useful stuff *and* for which no practical
> alternatives exist *and* were written by incompetents or hostiles.
It's surely the easiest to walk a problem around by calling others
incompetent, especially if it's not your problem.
> Do you have a specific library in mind, or are you "just
> supposing?" If the latter, drop it until the situation actually
> arises. If the former, please tell us about it so we'll be warned
> not to use that organization's products.
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.
>>>> By the way, it seems that some people avoid #includ'ing headers like
>>>> stddef.h in library headers due to bugs in C implementations
>>>> or for some other obscure reasons. I'd think it adds to this
>>>> issue: you can use long for free, it's builtin, but to get
>>>> size_t you need an extra header.
>>>
>>> Given that size_t is also #defined in <stdio.h>, <stdlib.h> and
>>> <string.h>, probably the three most #included headers, without which I
>>> can hardly imagine a useful ISO C program of any reasonable size, as
>>> well as in <time.h> and <wchar.h>, IMO people who do this should do a
>>> reality check.
>>
>> 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.
>
> You're playing something, yes, but I don't recognize the tune.
>
> Proposition: There is *no* reason to use unsigned long instead
> of size_t. None. Nada. Zero. Zip. Nulla.
I know none, this is true. You seem to know none. You sure there
*isn't* one?
> Every module that
> performs I/O includes <stdio.h> and has size_t defined;
Unless this module use third-party I/O routines, or uses things like
open/write. I.e. no, not every.
> every
> module that works with strings includes <string.h> and has size_t
> defined;
If it's C strings, then that's probably true.
> every module that calls malloc() includes <stdlib.h> and
> has size_t defined.
Yes, if a module calls malloc() then it needs to use stdlib.h. But
not every module calls malloc() to allocate memory. Some call
third-party routines which use unsigned long instead of size_t ;)
Anyway, these three examples are examples of why *user* would
use the standard headers. The library itself may not need them.
Now, it may be important for the user how he uses the standard
headers: what he #define's or in what order he uses the headers,
or whatever. Library has no business in that.
Now, if it's true that one single standard header ever caused
problems, then library developers have really good reason to avoid
standard headers altogether.
> The excuse "I don't want to include standard headers because they
> might be broken" is hopelessly fallacious: If you don't trust the
> headers, why would you trust the library?
I, user, may know that on my FooBar-10.7 I need to sit then
jump three times to use some standard header; I can perform
those exercises when writing my program. If a library makes me a
"favor" and uses the header prior to my jumps, then it does a
wrong thing.
Somehow you started talking like I am saying "I don't want to
use standard headers in my program". Nope.
> Do you provide a mian()
> function just in case the implementation has a spelling error?
Ever heard of WinMain() thing? No, I don't provide mian() function.
I also don't eat spoons, and I don't fly.
> As for standard headers providing non-Standard definitions:
> First, there are identifiers that are reserved for future use,
> meaning that the standard headers are free to define them if
> they so choose. You are not allowed to use `isosceles' as an
> identifier with external linkage, and if you do use it you are at
> fault and not the headers.
Good or bad, but:
NAME
strdup, strndup, strdupa, strndupa - duplicate a string
SYNOPSIS
#define _GNU_SOURCE
#include <string.h>
char *strndup(const char *s, size_t n);
It's not (other) library developers business how user is going
to use strndup, it's personal matter between user and his C
library.
> Second, if you define reserved identifiers
> like _GNU_SOURCE you invoke undefined behavior. You may *want* the
> undefined behavior,
See above, SYNOPSIS section.
> but you can't ask the Standard to bless your
> perverted desires. SAFUYOYO.
Am I asking the standard about something?
Yevgen
Yevgen Muntyan
> Yevgen Muntyan wrote:
>> Richard Bos wrote:
>>> Yevgen Muntyan <muntyan.r...@tamu.edu> wrote:
>>>
>>>> Richard Bos wrote:
>>>>> Yevgen Muntyan <muntyan.r...@tamu.edu> wrote:
>>>>>
>>>>>> But how is casting size_t to unsigned long more legitimate than
>>>>>>
>>>>>> int process_some_data (char *data, unsigned long len);
>>>>> In this case, you could easily make len a size_t instead.
>>>> *If* I can change the code.
>>>
>>> If _you_ can't change the code, I would advise not to worry about
>>> whether the ideas expressed in it are legitimate or not; leave that to
>>> the people who did design and do maintain it.
>>
>> 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.
>
> Yes, indeed. Your problem is that you are using a library
> written by somebody who didn't understand C, or who chose to be
> deliberately perverse in the way he used it. When the library
> writer is hostile or incompetent, you certainly have a problem.
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.
Eric Sosman
> Eric Sosman wrote:
>> Yevgen Muntyan wrote:
>>> This Win64 thing is funny, because no other 'popular' system
>>> has small long type. Good or bad, but lot of useful software is written
>>> under many assumptions like 8-bit bytes, ASCII, long >= size_t. Simply
>>> ignoring it won't always work since you might actually need that
>>> software (you know, libraries which have useful stuff).
>>
>> supposing?" If the latter, drop it until the situation actually
>> arises. If the former, please tell us about it so we'll be warned
>> not to use that organization's products.
>
> 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.
... which you have not named, to warn us away from it.
>> Proposition: There is *no* reason to use unsigned long instead
>> of size_t. None. Nada. Zero. Zip. Nulla.
>
> I know none, this is true. You seem to know none. You sure there
> *isn't* one?
I offered the remark as a "proposition," thus inviting
a counter-example. Got one?
>> Every module that
>> performs I/O includes <stdio.h> and has size_t defined;
>
> Unless this module use third-party I/O routines, or uses things like
> open/write. I.e. no, not every.
Yes, "every" -- 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.
> Anyway, these three examples are examples of why *user* would
> use the standard headers. The library itself may not need them.
> Now, it may be important for the user how he uses the standard
> headers: what he #define's or in what order he uses the headers,
> or whatever. Library has no business in that.
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?
> Now, if it's true that one single standard header ever caused
> problems, then library developers have really good reason to avoid
> standard headers altogether.
Balderdash. They should be equally leery of the % operator.
> Somehow you started talking like I am saying "I don't want to
> use standard headers in my program". Nope.
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.
>> Do you provide a mian()
>> function just in case the implementation has a spelling error?
>
> Ever heard of WinMain() thing? No, I don't provide mian() function.
> I also don't eat spoons, and I don't fly.
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.
>> As for standard headers providing non-Standard definitions:
>> First, there are identifiers that are reserved for future use,
>> meaning that the standard headers are free to define them if
>> they so choose. You are not allowed to use `isosceles' as an
>> identifier with external linkage, and if you do use it you are at
>> fault and not the headers.
>
> Good or bad, but:
>
> NAME
> strdup, strndup, strdupa, strndupa - duplicate a string
> SYNOPSIS
> #define _GNU_SOURCE
> #include <string.h>
>
> char *strndup(const char *s, size_t n);
>
> It's not (other) library developers business how user is going
> to use strndup, it's personal matter between user and his C
> library.
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.
The situation is a little tenser if you decide to call upon
strdup() -- or stromboli() -- in your program. The implementation
is permitted to define these identifiers, but is not obliged to do
so and is not obliged to give them any specific meaning. Perhaps
strdup() duplicates a string, but as far as the Standard is concerned
it might just as well cause chocolate pudding to ooze from your
keyboard. *That* might be a "personal matter" between the user and
the C implementation, in the same way that simply assuming a 27-bit
int is a "personal matter."
>> Second, if you define reserved identifiers
>> like _GNU_SOURCE you invoke undefined behavior. You may *want* the
>> undefined behavior,
>
> See above, SYNOPSIS section.
As I said, you may want the undefined behavior. That's
one of those "personal matters" you refer to, but not a problem
for C. 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.
--
Eric Sosman
eso...@acm-dot-org.invalid
Yevgen Muntyan
> Yevgen Muntyan wrote:
>> Eric Sosman wrote:
>>> Yevgen Muntyan wrote:
>>>> This Win64 thing is funny, because no other 'popular' system
>>>> has small long type. Good or bad, but lot of useful software is written
>>>> under many assumptions like 8-bit bytes, ASCII, long >= size_t. Simply
>>>> ignoring it won't always work since you might actually need that
>>>> software (you know, libraries which have useful stuff).
>>>
>>> Do you have a specific library in mind, or are you "just
>>> supposing?" If the latter, drop it until the situation actually
>>> arises. If the former, please tell us about it so we'll be warned
>>> not to use that organization's products.
>>
>> 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.
>
> ... 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.
>>> Proposition: There is *no* reason to use unsigned long instead
>>> of size_t. None. Nada. Zero. Zip. Nulla.
>>
>> I know none, this is true. You seem to know none. You sure there
>> *isn't* one?
>
> 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.
>>> Every module that
>>> performs I/O includes <stdio.h> and has size_t defined;
>>
>> Unless this module use third-party I/O routines, or uses things like
>> open/write. I.e. no, not every.
>
> 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.
>> Anyway, these three examples are examples of why *user* would
>> use the standard headers. The library itself may not need them.
>> Now, it may be important for the user how he uses the standard
>> headers: what he #define's or in what order he uses the headers,
>> or whatever. Library has no business in that.
>
> 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*.
>> Now, if it's true that one single standard header ever caused
>> problems, then library developers have really good reason to avoid
>> standard headers altogether.
>
> 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.
>> Somehow you started talking like I am saying "I don't want to
>> use standard headers in my program". Nope.
>
> 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?
>>> Do you provide a mian()
>>> function just in case the implementation has a spelling error?
>>
>> Ever heard of WinMain() thing? No, I don't provide mian() function.
>> I also don't eat spoons, and I don't fly.
>
> 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.
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)
...
>>> Second, if you define reserved identifiers
>>> like _GNU_SOURCE you invoke undefined behavior. You may *want* the
>>> undefined behavior,
>>
>> See above, SYNOPSIS section.
>
> 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
> Eric Sosman wrote:
>> Yevgen Muntyan wrote:
>>> Eric Sosman wrote:
>>>> Yevgen Muntyan wrote:
>>>>> This Win64 thing is funny, because no other 'popular' system
>>>>> has small long type. Good or bad, but lot of useful software is
>>>>> written
>>>>> under many assumptions like 8-bit bytes, ASCII, long >= size_t. Simply
>>>>> ignoring it won't always work since you might actually need that
>>>>> software (you know, libraries which have useful stuff).
>>>>
>>>> Do you have a specific library in mind, or are you "just
>>>> supposing?" If the latter, drop it until the situation actually
>>>> arises. If the former, please tell us about it so we'll be warned
>>>> not to use that organization's products.
>>>
>>> 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.
>>
>> ... 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 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
> Eric Sosman wrote:
>> Yevgen Muntyan wrote:
>>>
>>> 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.
>>
>> ... which you have not named, to warn us away from it.
>
> 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?
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.
Yevgen Muntyan
> Yevgen Muntyan said:
>
>> Eric Sosman wrote:
>>> Yevgen Muntyan wrote:
>>>> 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.
>>> ... which you have not named, to warn us away from it.
>> 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?
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
> Richard Bos wrote:
> > Yevgen Muntyan <muntyan.r...@tamu.edu> wrote:
> >
> >> Richard Bos wrote:
> >>> Yevgen Muntyan <muntyan.r...@tamu.edu> wrote:
> >>>
> >>>> But how is casting size_t to unsigned long more legitimate than
> >>>>
> >>>> int process_some_data (char *data, unsigned long len);
> >>> In this case, you could easily make len a size_t instead.
> >> *If* I can change the code.
> >
> > If _you_ can't change the code, I would advise not to worry about
> > whether the ideas expressed in it are legitimate or not; leave that to
> > the people who did design and do maintain it.
>
> 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.
> >> By the way, it seems that some people avoid #includ'ing headers like
> >> stddef.h in library headers due to bugs in C implementations
> >> or for some other obscure reasons. I'd think it adds to this
> >> issue: you can use long for free, it's builtin, but to get
> >> size_t you need an extra header.
> >
> > Given that size_t is also #defined in <stdio.h>, <stdlib.h> and
> > <string.h>, probably the three most #included headers, without which I
> > can hardly imagine a useful ISO C program of any reasonable size, as
> > well as in <time.h> and <wchar.h>, IMO people who do this should do a
> > reality check.
>
> 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
_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
> 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.
--
Eric Sosman
eso...@acm-dot-org.invalid
Flash Gordon
> Richard Heathfield wrote:
>> Yevgen Muntyan said:
>>
>>> Eric Sosman wrote:
>>>> Yevgen Muntyan wrote:
>>>>> 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.
>>>> ... which you have not named, to warn us away from it.
>>> 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?
>
> 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
Richard Heathfield
> Yevgen Muntyan wrote, On 16/03/07 06:22:
<snip>
>> 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.
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.
Flash Gordon
> Eric Sosman wrote:
>> Yevgen Muntyan wrote:
>>> Eric Sosman wrote:
>>>> Yevgen Muntyan wrote:
>>>>> This Win64 thing is funny, because no other 'popular' system
>>>>> has small long type. Good or bad, but lot of useful software is
>>>>> written
>>>>> under many assumptions like 8-bit bytes, ASCII, long >= size_t. Simply
>>>>> ignoring it won't always work since you might actually need that
>>>>> software (you know, libraries which have useful stuff).
>>>>
>>>> Do you have a specific library in mind, or are you "just
>>>> supposing?" If the latter, drop it until the situation actually
>>>> arises. If the former, please tell us about it so we'll be warned
>>>> not to use that organization's products.
>>>
>>> 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.
>>
>> ... 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.
If you are not prepared to provide evidence for you claims then do not
expect people to take them seriously.
>>>> Proposition: There is *no* reason to use unsigned long instead
>>>> of size_t. None. Nada. Zero. Zip. Nulla.
>>>
>>> I know none, this is true. You seem to know none. You sure there
>>> *isn't* one?
>>
>> 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.
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.
>>>> Every module that
>>>> performs I/O includes <stdio.h> and has size_t defined;
>>>
>>> Unless this module use third-party I/O routines, or uses things like
>>> open/write. I.e. no, not every.
>>
>> Yes, "every"
>
> 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.
>> -- 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.
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.
>>> Anyway, these three examples are examples of why *user* would
>>> use the standard headers. The library itself may not need them.
>>> Now, it may be important for the user how he uses the standard
>>> headers: what he #define's or in what order he uses the headers,
>>> or whatever. Library has no business in that.
>>
>> 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*.
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.
>>> Now, if it's true that one single standard header ever caused
>>> problems, then library developers have really good reason to avoid
>>> standard headers altogether.
>>
>> 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.
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.
>>> Somehow you started talking like I am saying "I don't want to
>>> use standard headers in my program". Nope.
>>
>> 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?
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.
>>>> Do you provide a mian()
>>>> function just in case the implementation has a spelling error?
>>>
>>> Ever heard of WinMain() thing? No, I don't provide mian() function.
>>> I also don't eat spoons, and I don't fly.
>>
>> 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.
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.
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.
>
> ...
>
>>>> Second, if you define reserved identifiers
>>>> like _GNU_SOURCE you invoke undefined behavior. You may *want* the
>>>> undefined behavior,
>>>
>>> See above, SYNOPSIS section.
>>
>> 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 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.
--
Flash Gordon
Yevgen Muntyan
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...".
>> 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.
>> 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.
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
Well, it wasn't quite like that. Let me quote:
>> Given that size_t is also #defined in <stdio.h>, <stdlib.h> and
>> <string.h>, probably the three most #included headers, without which
>> I can hardly imagine a useful ISO C program of any reasonable size,
>> as well as in <time.h> and <wchar.h>, IMO people who do this should
>> do a reality check.
> 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
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?
>>>>> Proposition: There is *no* reason to use unsigned long instead
>>>>> of size_t. None. Nada. Zero. Zip. Nulla.
>>>>
>>>> I know none, this is true. You seem to know none. You sure there
>>>> *isn't* one?
>>>
>>> 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.
>
> 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.
>>>>> Every module that
>>>>> performs I/O includes <stdio.h> and has size_t defined;
>>>>
>>>> Unless this module use third-party I/O routines, or uses things like
>>>> open/write. I.e. no, not every.
>>>
>>> Yes, "every"
>>
>> Good you used "quotes" here.
>
> Probably for emphasis.
I doubt it. Read the sentence. "Every module that performs I/O includes
<stdio.h>". It is not true. "Every" was put in quotes to make it "true".
> 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.
>>> -- 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.
>
> 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?
>>>> Anyway, these three examples are examples of why *user* would
>>>> use the standard headers. The library itself may not need them.
>>>> Now, it may be important for the user how he uses the standard
>>>> headers: what he #define's or in what order he uses the headers,
>>>> or whatever. Library has no business in that.
>>>
>>> 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*.
>
> 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"?
>>>> Now, if it's true that one single standard header ever caused
>>>> problems, then library developers have really good reason to avoid
>>>> standard headers altogether.
>>>
>>> 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.
>
> 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".
>>>> Somehow you started talking like I am saying "I don't want to
>>>> use standard headers in my program". Nope.
>>>
>>> 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?
>
> 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.
>
>>>>> Do you provide a mian()
>>>>> function just in case the implementation has a spelling error?
>>>>
>>>> Ever heard of WinMain() thing? No, I don't provide mian() function.
>>>> I also don't eat spoons, and I don't fly.
>>>
>>> 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.
>
> 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?
> > 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.
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)
> > 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.
Again, I don't know how to use MS VC++.
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.
> > 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.
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).
>> 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,
Am I?
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
> Yevgen Muntyan <muntyan.r...@tamu.edu> wrote:
>
>> Richard Bos wrote:
>>> Yevgen Muntyan <muntyan.r...@tamu.edu> wrote:
>>>
>>>> Richard Bos wrote:
>>>>> Yevgen Muntyan <muntyan.r...@tamu.edu> wrote:
>>>>>
>>>>>> But how is casting size_t to unsigned long more legitimate than
>>>>>>
>>>>>> int process_some_data (char *data, unsigned long len);
>>>>> In this case, you could easily make len a size_t instead.
>>>> *If* I can change the code.
>>> If _you_ can't change the code, I would advise not to worry about
>>> whether the ideas expressed in it are legitimate or not; leave that to
>>> the people who did design and do maintain it.
>> 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.
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.
>
>>>> By the way, it seems that some people avoid #includ'ing headers like
>>>> stddef.h in library headers due to bugs in C implementations
>>>> or for some other obscure reasons. I'd think it adds to this
>>>> issue: you can use long for free, it's builtin, but to get
>>>> size_t you need an extra header.
>>> Given that size_t is also #defined in <stdio.h>, <stdlib.h> and
>>> <string.h>, probably the three most #included headers, without which I
>>> can hardly imagine a useful ISO C program of any reasonable size, as
>>> well as in <time.h> and <wchar.h>, IMO people who do this should do a
>>> reality check.
>> 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?
#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
CBFalconer
> Eric Sosman wrote:
>
>>
>> Libraries that have useful stuff *and* for which no practical
>> alternatives exist *and* were written by incompetents or hostiles.
>
> It's surely the easiest to walk a problem around by calling others
> incompetent, especially if it's not your problem.
>
>> Do you have a specific library in mind, or are you "just
>> supposing?" If the latter, drop it until the situation actually
>> arises. If the former, please tell us about it so we'll be warned
>> not to use that organization's products.
>
> 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?
--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>
--
Posted via a free Usenet account from http://www.teranews.com
Flash Gordon
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.
>>> 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.
>>> 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.
>
> 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.
>> 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.
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.
--
Flash Gordon
Stephen Sprunk
news:osYJh.5718$Bi2.67@trnddc01...
> Eric Sosman wrote:
>> If size_t is wider than long, the implementation cannot
>> conform to C89. It could, however, conform to C99, with
>> size_t being as wide as long long or as some other wide type.
>> One of the (many) things I don't know about MS Win64 is what
>> standards it claims to conform to.
>
> It claims conformance to C90. It does not conform to C99.
Win64 itself doesn't claim conformance with anything; since it's not a
complete implementation, it couldn't anyways. It's merely an API.
Individual compilers may or may not be compliant; I don't see how
an IL32LLP64 system could be C90-compliant , but it could be
C99-compliant. However, MSVC doesn't even attempt to be C99-
compliant. Since the _vast_ majority of code compiled with it is
blatantly unportable to any other implementation anyways, they can
get away with it. Another implementation for Win64 could be
C99-compliant if the authors wished.
(And for the record, MS wanted to do I32LP64, but they discovered that broke
nearly every program they tried to port, whereas IL32LLP64 allowed nearly
all of them to compile and work unchanged.)
S
--
Stephen Sprunk "Those people who think they know everything
CCIE #3723 are a great annoyance to those of us who do."
K5SSS --Isaac Asimov
Dave Vandervies
Flash Gordon <sp...@flash-gordon.me.uk> wrote:
> 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 dj3v...@csclub.uwaterloo.ca
>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
> "Yevgen Muntyan" <muntyan.r...@tamu.edu> wrote in message
> news:osYJh.5718$Bi2.67@trnddc01...
>> Eric Sosman wrote:
>>> If size_t is wider than long, the implementation cannot
>>> conform to C89. It could, however, conform to C99, with
>>> size_t being as wide as long long or as some other wide type.
>>> One of the (many) things I don't know about MS Win64 is what
>>> standards it claims to conform to.
>>
>> It claims conformance to C90. It does not conform to C99.
>
> 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:
>> Flash Gordon wrote:
>>> Yevgen Muntyan wrote, On 16/03/07 06:22:
>>>> 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.
>
>>>> 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.
>>
>> 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.
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.
--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>
--
Keith Thompson
> Yevgen Muntyan wrote:
>>
> ... 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.
He's not necessarily an idiot. He is very likely just using the
documented mechanism to enable glibc-specific extensions to the
standard C library. The macro "_GNU_SOURCE" is specified in the glibc
documentation; since glibc is part of the implementation, using a name
in the implementor's namespace is exactly the right thing for glibc to
do.
Yes, the behavior is undefined by the standard. Exploiting undefined
behavior (by defining it) is a perfectly good way to implement
extensions.
Of course the user needs to know how to use it properly, and in
particular whether it should appear before or after any other #include
directives.
--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Flash Gordon
> Flash Gordon wrote:
>> Yevgen Muntyan wrote, On 16/03/07 15:26:
>>> Flash Gordon wrote:
>>>> 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.
Saying something like,
| Perhaps. I do understand that you have to earn right to be an asshole,
| like Mr Heathfield has.
Certainly sounds like attacking to me.
Reviewing the thread, it looks like there are only a couple of instances
of such things, so it might in part be you catching me on the wrong day
or me finding you irritating for whatever reason.
>>>>> 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.
>>>
>>> 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.
>
> Bullshit.
Suggesting that they are avoiding the standard headers because they
think some implementation has headers broken enough that they have to be
avoided does suggest they are incompetent. However, elsewhere you have
admitted that it is glibc and looking at the headers in some of them
they *do* include stdef.h and stdio.h, so that obviously is *not* the
reason.
--
Flash Gordon
Yevgen Muntyan
This indeed does. I didn't understand you mean "attacking Mr.
Heathfield". Well, he came accusing me of calling him a liar, and
did not present any evidence of that. Ask him when I called him a
liar. Maybe you'll understand why I feel this way about him. Or
perhaps not. Or perhaps you'll be presented an evidence of him being
an asshole.
> Reviewing the thread, it looks like there are only a couple of instances
> of such things, so it might in part be you catching me on the wrong day
> or me finding you irritating for whatever reason.
>
>>>>>> 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.
>>>>
>>>> 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.
>>
>> Bullshit.
>
> Suggesting that they are avoiding the standard headers because they
> think some implementation has headers broken enough that they have to be
> avoided does suggest they are incompetent.
I did *not* say glib avoids using standard headers. It does not, in
fact. It does avoid string.h, but it doesn't avoid stddef.h. If you
think otherwise, please quote where I said glib uses unsigned long
instead of size_t because of headers thing.
Glib uses unsigned long there because of other reasons, which I
suspect are really "historic reasons". You and Eric easily jump
into "glib developers are incompetent". This is what I call bullshit,
or, politely, groundless, not honest and hostile.
Yevgen
Yevgen Muntyan
> Yevgen Muntyan wrote:
> ... 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,
Or he reads documentation of his implementation and wants to
use nice convenient strndup() function without having to
reimplement it? Use in *legal* *documented* ways. Try
man 3 strndup if you have access to a linux machine.
Sure, great brave C.Falconer will just implement string functions
he likes to implement so much and just call idiots everybody
who doesn't do so. Or what? See, I just noticed you called
me an idiot (no, I didn't use strndup, I used this stupid
#define when needed to get lstat() declared in strict ansi mode,
which is buggy in gcc+glibc). Should I get insulted and run away
crying? Chuck said! Sure!
Yevgen
Flash Gordon
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.
>>>>>> Proposition: There is *no* reason to use unsigned long instead
>>>>>> of size_t. None. Nada. Zero. Zip. Nulla.
>>>>>
>>>>> I know none, this is true. You seem to know none. You sure there
>>>>> *isn't* one?
>>>>
>>>> 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.
>>
>> 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.
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 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.
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.
>>>>>> Every module that
>>>>>> performs I/O includes <stdio.h> and has size_t defined;
>>>>>
>>>>> Unless this module use third-party I/O routines, or uses things like
>>>>> open/write. I.e. no, not every.
>>>>
>>>> Yes, "every"
>>>
>>> Good you used "quotes" here.
>>
>> Probably for emphasis.
>
> I doubt it. Read the sentence. "Every module that performs I/O includes
> <stdio.h>". It is not true. "Every" was put in quotes to make it "true".
>
>> 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.
So you are using things outside of standard C. Now what would be broken
if you included one of the standard headers?
>>>> -- 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.
>>
>> 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?
Yes, I've seen it. It does not seem to mention support for broken
implementations, although it does provide stuff for pre-C89 implementations.
>>>>> Anyway, these three examples are examples of why *user* would
>>>>> use the standard headers. The library itself may not need them.
>>>>> Now, it may be important for the user how he uses the standard
>>>>> headers: what he #define's or in what order he uses the headers,
>>>>> or whatever. Library has no business in that.
>>>>
>>>> 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*.
>>
>> 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"?
No, to make the point.
>>>>> Now, if it's true that one single standard header ever caused
>>>>> problems, then library developers have really good reason to avoid
>>>>> standard headers altogether.
>>>>
>>>> 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.
>>
>> 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.
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.
>> 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 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.
>> 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".
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!
>>>>> Somehow you started talking like I am saying "I don't want to
>>>>> use standard headers in my program". Nope.
>>>>
>>>> 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?
>>
>> 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.
Any such implementation would be basically unusable so it would not survive.
>> 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?
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.
>> 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.
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.
>> because the purpose of the standard is to provide you with the
>> guarantees that you do not need to worry about such things.
>>
>>>>>> Do you provide a mian()
>>>>>> function just in case the implementation has a spelling error?
>>>>>
>>>>> Ever heard of WinMain() thing? No, I don't provide mian() function.
>>>>> I also don't eat spoons, and I don't fly.
>>>>
>>>> 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.
>>
>> 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?
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.
>> > 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.
>
> 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.
>> 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)
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.
>> > 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.
>
> 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.
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.
>> > 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)
>>y
>> 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).
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.
>>> 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,
>
> Am I?
That's how it seemed.
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.
--
Flash Gordon
Keith Thompson
[...]
> Suggesting that they are avoiding the standard headers because they
> think some implementation has headers broken enough that they have to
> be avoided does suggest they are incompetent. However, elsewhere you
> have admitted that it is glibc and looking at the headers in some of
> them they *do* include stdef.h and stdio.h, so that obviously is *not*
> the reason.
<OT>
I think he said he's talking about glib, not glibc. glib and glibc
are two different things. glibc is the GNU implementation of the
standard C library. glib is "the low-level core library that forms
the basis of GTK+ and GNOME".
</OT>
Yevgen Muntyan
> Yevgen Muntyan wrote, On 16/03/07 16:12:
>> Flash Gordon wrote:
>>> Yevgen Muntyan wrote, On 16/03/07 03:57:
> > 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.
Right... You commented on parts you liked, 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.
....
>> 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.
It was a hypothetical good reason for not using standard headers
in general, 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 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.
>
> 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.
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?
>>>>>>> Every module that
>>>>>>> performs I/O includes <stdio.h> and has size_t defined;
>>>>>>
>>>>>> Unless this module use third-party I/O routines, or uses things like
>>>>>> open/write. I.e. no, not every.
>>>>>
>>>>> Yes, "every"
>>>>
>>>> Good you used "quotes" here.
>>>
>>> Probably for emphasis.
>>
>> I doubt it. Read the sentence. "Every module that performs I/O includes
>> <stdio.h>". It is not true. "Every" was put in quotes to make it "true".
>>
>>> 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.
>
> So you are using things outside of standard C. Now what would be broken
> if you included one of the standard headers?
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?
>>>>> -- 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.
>>>
>>> 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?
>
> Yes, I've seen it. It does not seem to mention support for broken
> implementations, although it does provide stuff for pre-C89
> implementations.
Yes it does support broken C99 implementations. 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.
...
>>> 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"?
>
> No, to make the point.
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.
>>>>>> Now, if it's true that one single standard header ever caused
>>>>>> problems, then library developers have really good reason to avoid
>>>>>> standard headers altogether.
>>>>>
>>>>> 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.
>>>
>>> 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.
>
> 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'm afraid processor bug is a little different from software bugs.
Broken string functions on some platforms come to mind. Glib has
some stuff to work that around.
>>> 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 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.
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.
>>> 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".
>
> 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!
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.
>>>> 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
>>
>> "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.
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?
>>> 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?
>
> 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.
Um, Win64? Will it be boycotted for making small long type? Or does
it depend on the bug severity?
>> 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.
_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.
...
>>> 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.
>
> I do claim it is true because I have some limited understanding of
> commercial and open-source realities.
Especially open-source it seems.
> 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.
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. 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?
...
>> 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.
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.
>>> > 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.
>>
>> 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.
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().
>>> 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)
>
> 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.
And if entry point is indeed main()? Here, let me repeat:
>> 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)
>>> > 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.
>>
>> 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.
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.
...
>> 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.
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? Not necessarily
with standard C headers by the way. sys/stat.h is good too to make
developers wary of standard headers.
...
>>> 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).
>
> Freedom of speech. I've got the right to tell you that.
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.
> 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.
I think it's important not to make conclusions from absence of evidence
in technical groups. It's not a court. Exactly.
>>>> 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,
>>
>> Am I?
>
> That's how it seemed.
Quote it. Please quote where I advocated using long instead of
size_t? I did try to make up some possible reasons for that,
and you simply said "no problems may exist with standard headers",
and I didn't agree with *this* claim. I advocated using long instead
of size_t?
Interesting. Care to explain how I can provide an example of something
which I don't know whether it exists or not? I did say, like ten
times I *don't* know if there is a good reason. You can't get it,
can you? You seem to think either I say "yes" or "no", and "don't know"
qualifies as "yes". While your "don't know" implies "no". Oh well.
> > 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,
It is, if you think of C99 for a minute. stdbool.h and all that. But not
only that of course.
> 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.
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?
> 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.
Flash Gordon
> Flash Gordon <sp...@flash-gordon.me.uk> writes:
> [...]
>> Suggesting that they are avoiding the standard headers because they
>> think some implementation has headers broken enough that they have to
>> be avoided does suggest they are incompetent. However, elsewhere you
>> have admitted that it is glibc and looking at the headers in some of
>> them they *do* include stdef.h and stdio.h, so that obviously is *not*
>> the reason.
>
> <OT>
> I think he said he's talking about glib, not glibc. glib and glibc
> are two different things. glibc is the GNU implementation of the
> standard C library. glib is "the low-level core library that forms
> the basis of GTK+ and GNOME".
> </OT>
I know that, I intended to type glib, my saying glibc was a trypo. glib
*does* include stdef.h, stdio.h and string.h (maybe others) from within
its headers.
--
Flash Gordon.
Flash Gordon
It does not. At least, not in the version installed on this machine.
markg@brenda:/usr/include/glib-2.0/gobject$ grep string.h *
gobjectnotifyqueue.c:#include <string.h> /* memset */
> but it doesn't avoid stddef.h. If you
> think otherwise, please quote where I said glib uses unsigned long
> instead of size_t because of headers thing.
> Glib uses unsigned long there because of other reasons, which I
> suspect are really "historic reasons". You and Eric easily jump
> into "glib developers are incompetent". This is what I call bullshit,
> or, politely, groundless, not honest and hostile.
You kept going on about knowing a library that did not use use size_t.
You also kept going on about how one reason for avoiding it could be to
avoid broken standard headers. If the two are unrelated then fine I
misread you.
However, there is still no reason to avoid the use of standard headers.
Some of the things in glib suggest trying to deal with pre-ANSI C, for
example defining NULL if it is not defined. Either that or it shows a
stupid (in my opinion) lack of trust in the standard libraries. The same
applies to the provision of an equivalent of the standard offsetof macro.
There is also invasion of the implementations name space with struct
_GSource etc.
So yes, there is certainly some grounds to say that the author(s) do not
know C properly.
Oh, and one comment I found particularly amusing. 'These are useful
because a "gint8" can be adjusted to be 1 byte (8 bits) on all
platforms.' Ignoring the terminology problem, if char is not 8 bits you
are stuffed in terms of finding an 8 bit type!
--
Flash Gordon
Yevgen Muntyan
> Yevgen Muntyan wrote, On 16/03/07 22:46:
>> Flash Gordon wrote:
>>> Yevgen Muntyan wrote, On 16/03/07 18:49:
>>>> Flash Gordon wrote:
>>>>> Yevgen Muntyan wrote, On 16/03/07 15:26:
>>>>>> Flash Gordon wrote:
>>>>>>> Yevgen Muntyan wrote, On 16/03/07 06:22:
[snip]
>>>>>>>> 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.
>>>>>>
>>>>>> 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.
>>>>
>>>> Bullshit.
>>>
>>> Suggesting that they are avoiding the standard headers because they
>>> think some implementation has headers broken enough that they have to
>>> be avoided does suggest they are incompetent.
>>
>> I did *not* say glib avoids using standard headers. It does not, in
>> fact. It does avoid string.h,
>
> It does not. At least, not in the version installed on this machine.
> markg@brenda:/usr/include/glib-2.0/gobject$ grep string.h *
> gobjectnotifyqueue.c:#include <string.h> /* memset */
Um, so you did not understand I was talking about standard headers
in *headers*? If you really thought I was talking about library
sources, I apologize, and I must admit all I said seemed like
hundred times more stupid than I thought it did. Of course I meant
headers. Why do you think I was talking about that _GNU_SOURCE thing?
Because some glib source file is using it? Just to be clear,
#include <glib.h>
won't make declaration of strlen() visible. But size_t will be
defined.
> > but it doesn't avoid stddef.h. If you
>> think otherwise, please quote where I said glib uses unsigned long
>> instead of size_t because of headers thing.
>> Glib uses unsigned long there because of other reasons, which I
>> suspect are really "historic reasons". You and Eric easily jump
>> into "glib developers are incompetent". This is what I call bullshit,
>> or, politely, groundless, not honest and hostile.
>
> You kept going on about knowing a library that did not use use size_t.
> You also kept going on about how one reason for avoiding it could be to
> avoid broken standard headers. If the two are unrelated then fine I
> misread you.
>
> However, there is still no reason to avoid the use of standard headers.
>
> Some of the things in glib suggest trying to deal with pre-ANSI C, for
> example defining NULL if it is not defined. Either that or it shows a
> stupid (in my opinion) lack of trust in the standard libraries. The same
> applies to the provision of an equivalent of the standard offsetof macro.
> There is also invasion of the implementations name space with struct
> _GSource etc.
>
> So yes, there is certainly some grounds to say that the author(s) do not
> know C properly.
Yeah, sure. Especially the last thing, about underscore-prefixed
identifiers. "Some grounds", huh? Indeed, some grounds. Now can
you say it in plain text, "glib developers are incompetent"?
Mumbling "some ground" surely helps not to lose face and still
make yourself right. Please make the claim you seem to be defending.
> Oh, and one comment I found particularly amusing. 'These are useful
> because a "gint8" can be adjusted to be 1 byte (8 bits) on all
> platforms.' Ignoring the terminology problem, if char is not 8 bits you
> are stuffed in terms of finding an 8 bit type!
You surely know that char is not signed char, I have no doubts about
that. You think these folks use "gint" because they think int may not
be available? However bad wording is (can't talk about it, it's not
my language), it means that gint8 plays the role of int8_t, but
in human-understandable language and without mentioning platforms
where char is not 8 bit (and the library won't work).
Yevgen
Yevgen Muntyan
Could you provide an example of string.h and stdio.h?
Yevgen
Keith Thompson
[...]
> Of course it's not, since gnulib is intended to be a complement to
> any-C-library.
Gnulib? I thought you were talking about glib. Or are you talking
about both?
Just to make sure everyone is clear on this (and not necessarily to
imply that anyone isn't), "gnulib", "glib", and "glibc" are three
different things.
Gnulib is the GNU portability library,
<http://www.gnu.org/software/gnulib/>.
glib is "the low-level core library that forms the basis of GTK+ and
GNOME", <http://www.gtk.org/>.
glibc is the GNU implementation of the standard C library,
<http://www.gnu.org/software/libc/>.
Yevgen Muntyan
> Yevgen Muntyan <muntyan.r...@tamu.edu> writes:
> [...]
>> Of course it's not, since gnulib is intended to be a complement to
>> any-C-library.
>
> Gnulib? I thought you were talking about glib. Or are you talking
> about both?
Both. glib is the evil library, gnulib is an example of how people work
around C implementation bugs.
> Just to make sure everyone is clear on this (and not necessarily to
> imply that anyone isn't), "gnulib", "glib", and "glibc" are three
> different things.
>
> Gnulib is the GNU portability library,
> <http://www.gnu.org/software/gnulib/>.
>
> glib is "the low-level core library that forms the basis of GTK+ and
> GNOME", <http://www.gtk.org/>.
>
> glibc is the GNU implementation of the standard C library,
> <http://www.gnu.org/software/libc/>.
Yes.
CBFalconer
> Flash Gordon <sp...@flash-gordon.me.uk> wrote:
>
>> 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.
The fact that size_t is defined in various headers is incidental.
The point is that the routines in <arbitrary.h> require size_t to
be defined, so that is done. Otherwise there would be awkward
dependencies between header files.
CBFalconer
> Flash Gordon wrote:
>> Yevgen Muntyan wrote, On 16/03/07 22:46:
>>> Flash Gordon wrote:
>>>> Yevgen Muntyan wrote, On 16/03/07 18:49:
>>>>> Flash Gordon wrote:
>>>>>> Yevgen Muntyan wrote, On 16/03/07 15:26:
>>>>>>> Flash Gordon wrote:
>>>>>>>> Yevgen Muntyan wrote, On 16/03/07 06:22:
> [snip]
This thread has received a well-deserved PLONK here.
Yevgen Muntyan
> Yevgen Muntyan wrote:
>> Flash Gordon wrote:
>>> Yevgen Muntyan wrote, On 16/03/07 22:46:
>>>> Flash Gordon wrote:
>>>>> Yevgen Muntyan wrote, On 16/03/07 18:49:
>>>>>> Flash Gordon wrote:
>>>>>>> Yevgen Muntyan wrote, On 16/03/07 15:26:
>>>>>>>> Flash Gordon wrote:
>>>>>>>>> Yevgen Muntyan wrote, On 16/03/07 06:22:
>> [snip]
>
> This thread has received a well-deserved PLONK here.
I'm glad there will be less valuable comments by Chuck
about who's idiot and who isn't.
Richard Heathfield
<snip>
> I didn't understand you mean "attacking Mr.
> Heathfield". Well, he came accusing me of calling him a liar, and
> did not present any evidence of that. Ask him when I called him a
> liar.
"[...] you're either lying or you do as you usually do - posts where
every letter is correct but post as whole doesn't carry any useful
information." - Yevgen Muntyan.
Both charges are false, of course, but insofar as Mr Muntyan considers
either of them to be true, I currently see no value in providing
further responses to any of his questions about C.
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.
Yevgen Muntyan
> Yevgen Muntyan said:
>
> <snip>
>
>> I didn't understand you mean "attacking Mr.
>> Heathfield". Well, he came accusing me of calling him a liar, and
>> did not present any evidence of that. Ask him when I called him a
>> liar.
>
> "[...] you're either lying or you do as you usually do - posts where
> every letter is correct but post as whole doesn't carry any useful
> information." - Yevgen Muntyan.
Surely without context. Of course, you don't want to bring that in.
It's better just to complain about me calling you a liar. Oh
this terrible word "lie"! Mr. Heathfield is totally fine with insulting
others two times a day (twenty in good days), but now someone
has some doubts about Holy Reasons for insulting people or
posting to post a post with "Try to find a mistake here you can't".
> Both charges are false, of course, but insofar as Mr Muntyan considers
> either of them to be true,
You said I called you a liar. So, I believe you took both or the first
one as true. Well, to make it clear, in that context, if I recall
correctly, you lied to my best understanding. The second "charge"
was an exaggeration, you don't usually post those things. They are
just about half of your posts.
> I currently see no value in providing
> further responses to any of his questions about C.
You already said you are not going to reply at all.
It's sad to lose such a nice source of information as this newsgroup,
but perhaps it's better if I don't read pearls by nice fluffy Richard.
Harald van Dijk
> Dave Vandervies wrote:
> > Flash Gordon <sp...@flash-gordon.me.uk> wrote:
> >
> >> 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.
>
> The fact that size_t is defined in various headers is incidental.
> The point is that the routines in <arbitrary.h> require size_t to
> be defined, so that is done. Otherwise there would be awkward
> dependencies between header files.
Not really. The standard library functions can declare malloc's
parameter, strlen's result, etc. as whatever type size_t is a typedef
for, or if that type differs for multiple configurations of the same
implementation, it can use a __size_t type.
Flash Gordon
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.
> If you really thought I was talking about library
> sources, I apologize, and I must admit all I said seemed like
> hundred times more stupid than I thought it did. Of course I meant
> headers. Why do you think I was talking about that _GNU_SOURCE thing?
> Because some glib source file is using it? Just to be clear,
>
> #include <glib.h>
>
> won't make declaration of strlen() visible. But size_t will be
> defined.
No, but #include <gobjectnotifyqueue.c> will, and if you actually loot
at it you will see that is its intended use.
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.
>> Oh, and one comment I found particularly amusing. 'These are useful
>> because a "gint8" can be adjusted to be 1 byte (8 bits) on all
>> platforms.' Ignoring the terminology problem, if char is not 8 bits
>> you are stuffed in terms of finding an 8 bit type!
>
> You surely know that char is not signed char,
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.
I.e. that comment is still highly amusing to me for the lack of
knowledge it shows.
> I have no doubts about
> that. You think these folks use "gint" because they think int may not
> be available?
No, they state a reason for that and it is a valid reason. Hence my not
saying it was a bad reason. Just because I criticise one thing does not
mean I am criticising everything.
> However bad wording is (can't talk about it, it's not
> my language), it means that gint8 plays the role of int8_t, but
If so then it is a broken definition for Linux systems using gcc which
is one of the primary targets.
> in human-understandable language and without mentioning platforms
> where char is not 8 bit (and the library won't work).
There is nothing wrong with the library not working on systems where
char is not 8 bit, but the reason given for gchar is just plain stupid
and the definition does not serve what *you* guess its purpose is.
--
Flash Gordon
Flash Gordon
> Flash Gordon wrote:
>> Yevgen Muntyan wrote, On 16/03/07 16:12:
>>> Flash Gordon wrote:
>>>> Yevgen Muntyan wrote, On 16/03/07 03:57:
> ...
>> > 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.
>
> 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.
>>> 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.
>
> 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.
>>>> 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.
>>
>> 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.
>
> 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.
>>>>>>>> Every module that
>>>>>>>> performs I/O includes <stdio.h> and has size_t defined;
>>>>>>>
>>>>>>> Unless this module use third-party I/O routines, or uses things like
>>>>>>> open/write. I.e. no, not every.
>>>>>>
>>>>>> Yes, "every"
>>>>>
>>>>> Good you used "quotes" here.
>>>>
>>>> Probably for emphasis.
>>>
>>> I doubt it. Read the sentence. "Every module that performs I/O includes
>>> <stdio.h>". It is not true. "Every" was put in quotes to make it "true".
>>>
>>>> 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.
>>
>> So you are using things outside of standard C. Now what would be
>> broken if you included one of the standard headers?
>
> 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.
>>>>>> -- 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.
>>>>
>>>> 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?
>>
>> Yes, I've seen it. It does not seem to mention support for broken
>> implementations, although it does provide stuff for pre-C89
>> implementations.
>
> 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.
>>>> 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"?
>>
>> No, to make the point.
>
> 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.
>>>>>>> Now, if it's true that one single standard header ever caused
>>>>>>> problems, then library developers have really good reason to avoid
>>>>>>> standard headers altogether.
>>>>>>
>>>>>> 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.
>>>>
>>>> 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.
>>
>> 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'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?
>>>> 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 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.
>
> 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.
>>>> 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".
>>
>> 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!
>
> 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.
>>>>> 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
>>>
>>> "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.
>
> 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.
>>>> 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?
>>
>> 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.
>
> 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.
>>> 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.
>
> _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.
>>>> 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.
>>
>> I do claim it is true because I have some limited understanding of
>> commercial and open-source realities.
>
> 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.
>> 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.
>
> 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.
>>> 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.
>
> 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.
>>>> > 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.
>>>
>>> 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.
>
> 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.
>>>> 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)
>>
>> 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.
>
> And if entry point is indeed main()? Here, let me repeat:
>
> >> 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)
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 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.
>>>
>>> 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.
>
> 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.
>>> 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.
>
> 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.
>>>> 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).
>>
>> Freedom of speech. I've got the right to tell you that.
>
> 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?
>> 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.
>
> 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.
<snip>
>> 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,
>
> 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.
>> 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.
>
> 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.
>> 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.
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.
--
Flash Gordon
mun...@gmail.com
> Yevgen Muntyan wrote, On 17/03/07 01:20:
>
>
>
> > Flash Gordon wrote:
> >> Oh, and one comment I found particularly amusing. 'These are useful
> >> because a "gint8" can be adjusted to be 1 byte (8 bits) on all
> >> platforms.' Ignoring the terminology problem, if char is not 8 bits
> >> you are stuffed in terms of finding an 8 bit type!
>
> > You surely know that char is not signed char,
>
> 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
mun...@gmail.com
> Yevgen Muntyan wrote, On 17/03/07 01:20:
>
>
>
> > Flash Gordon wrote:
> >> Yevgen Muntyan wrote, On 16/03/07 22:46:
> >>> I did *not* say glib avoids using standard headers. It does not, in
> >>> fact. It does avoid string.h,
>
> >> It does not. At least, not in the version installed on this machine.
> >> markg@brenda:/usr/include/glib-2.0/gobject$ grep string.h *
> >> gobjectnotifyqueue.c:#include <string.h> /* memset */
>
> > Um, so you did not understand I was talking about standard headers
> > in *headers*?
>
> 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).
> > If you really thought I was talking about library
>
> > sources, I apologize, and I must admit all I said seemed like
> > hundred times more stupid than I thought it did. Of course I meant
> > headers. Why do you think I was talking about that _GNU_SOURCE thing?
> > Because some glib source file is using it? Just to be clear,
>
> > #include <glib.h>
>
> > won't make declaration of strlen() visible. But size_t will be
> > defined.
>
> 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).
...
> >> Some of the things in glib suggest trying to deal with pre-ANSI C, for
> >> example defining NULL if it is not defined. Either that or it shows a
> >> stupid (in my opinion) lack of trust in the standard libraries. The
> >> same applies to the provision of an equivalent of the standard
> >> offsetof macro.
> >> There is also invasion of the implementations name space with struct
> >> _GSource etc.
>
> >> So yes, there is certainly some grounds to say that the author(s) do
> >> not know C properly.
>
> > Yeah, sure. Especially the last thing, about underscore-prefixed
> > identifiers. "Some grounds", huh? Indeed, some grounds. Now can
> > you say it in plain text, "glib developers are incompetent"?
> > Mumbling "some ground" surely helps not to lose face and still
> > make yourself right. Please make the claim you seem to be defending.
>
> 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
mun...@gmail.com
> Yevgen Muntyan wrote, On 17/03/07 00:04:
>
> > Flash Gordon wrote:
> >> 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
> On Mar 17, 3:29 pm, Flash Gordon <s...@flash-gordon.me.uk> wrote:
>> Yevgen Muntyan wrote, On 17/03/07 01:20:
>>
>>
>>
>>> Flash Gordon wrote:
>>>> Yevgen Muntyan wrote, On 16/03/07 22:46:
> ...
>>>>> I did *not* say glib avoids using standard headers. It does not, in
>>>>> fact. It does avoid string.h,
>>>> It does not. At least, not in the version installed on this machine.
>>>> markg@brenda:/usr/include/glib-2.0/gobject$ grep string.h *
>>>> gobjectnotifyqueue.c:#include <string.h> /* memset */
>>> Um, so you did not understand I was talking about standard headers
>>> in *headers*?
>> 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.
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.
>> > If you really thought I was talking about library
>>
>>> sources, I apologize, and I must admit all I said seemed like
>>> hundred times more stupid than I thought it did. Of course I meant
>>> headers. Why do you think I was talking about that _GNU_SOURCE thing?
>>> Because some glib source file is using it? Just to be clear,
>>> #include <glib.h>
>>> won't make declaration of strlen() visible. But size_t will be
>>> defined.
>> 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.
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.
>>>> Some of the things in glib suggest trying to deal with pre-ANSI C, for
>>>> example defining NULL if it is not defined. Either that or it shows a
>>>> stupid (in my opinion) lack of trust in the standard libraries. The
>>>> same applies to the provision of an equivalent of the standard
>>>> offsetof macro.
>>>> There is also invasion of the implementations name space with struct
>>>> _GSource etc.
>>>> So yes, there is certainly some grounds to say that the author(s) do
>>>> not know C properly.
>>> Yeah, sure. Especially the last thing, about underscore-prefixed
>>> identifiers. "Some grounds", huh? Indeed, some grounds. Now can
>>> you say it in plain text, "glib developers are incompetent"?
>>> Mumbling "some ground" surely helps not to lose face and still
>>> make yourself right. Please make the claim you seem to be defending.
>> 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?
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.
--
Flash Gordon
Flash Gordon
> On Mar 17, 3:29 pm, Flash Gordon <s...@flash-gordon.me.uk> wrote:
>> Yevgen Muntyan wrote, On 17/03/07 01:20:
>>
>>
>>
>>> Flash Gordon wrote:
> ...
>>>> Oh, and one comment I found particularly amusing. 'These are useful
>>>> because a "gint8" can be adjusted to be 1 byte (8 bits) on all
>>>> platforms.' Ignoring the terminology problem, if char is not 8 bits
>>>> you are stuffed in terms of finding an 8 bit type!
>>> You surely know that char is not signed char,
>> 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
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.
<snip>
>> I.e. that comment is still highly amusing to me for the lack of
>> knowledge it shows.
>
> 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
mun...@gmail.com
> munt...@gmail.com wrote, On 18/03/07 00:41:
>
>
>
> > On Mar 17, 3:29 pm, Flash Gordon <s...@flash-gordon.me.uk> wrote:
> >> Yevgen Muntyan wrote, On 17/03/07 01:20:
>
> >>> Flash Gordon wrote:
> > ...
> >>>> Oh, and one comment I found particularly amusing. 'These are useful
> >>>> because a "gint8" can be adjusted to be 1 byte (8 bits) on all
> >>>> platforms.' Ignoring the terminology problem, if char is not 8 bits
> >>>> you are stuffed in terms of finding an 8 bit type!
> >>> You surely know that char is not signed char,
> >> 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
>
> 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.
> > 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.
"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.
> <snip>
>
> >> I.e. that comment is still highly amusing to me for the lack of
> >> knowledge it shows.
>
> > Sure, totally incompetent people.
>
> No one has said totally incompetent, I certainly have not. You do keep
> pointing at evidence suggesting it though.
Yeah. Sure.
mun...@gmail.com
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".
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)
>
> > 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.
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.
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?
mun...@gmail.com
> munt...@gmail.com wrote, On 18/03/07 00:41:
>
>
>
> > On Mar 17, 3:29 pm, Flash Gordon <s...@flash-gordon.me.uk> wrote:
> >> Yevgen Muntyan wrote, On 17/03/07 01:20:
>
> >>> Flash Gordon wrote:
> > ...
> >>>> Oh, and one comment I found particularly amusing. 'These are useful
> >>>> because a "gint8" can be adjusted to be 1 byte (8 bits) on all
> >>>> platforms.' Ignoring the terminology problem, if char is not 8 bits
> >>>> you are stuffed in terms of finding an 8 bit type!
> >>> You surely know that char is not signed char,
> >> 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
>
> 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 <sp...@flash-gordon.me.uk>
> Subject: Re: C89, size_t, and long
>
> Yevgen Muntyan wrote, On 16/03/07 03:57:
> >Eric Sosman wrote:
> >>Yevgen Muntyan wrote:
> >>>Eric Sosman wrote:
> >>>>Yevgen Muntyan wrote:
> >>>>>This Win64 thing is funny, because no other 'popular' system
> >>>>>has small long type. Good or bad, but lot of useful software is
> >>>>>written
> >>>>>under many assumptions like 8-bit bytes, ASCII, long >= size_t. Simply
> >>>>>ignoring it won't always work since you might actually need that
> >>>>>software (you know, libraries which have useful stuff).
> >>>>
> >>>> Do you have a specific library in mind, or are you "just
> >>>>supposing?" If the latter, drop it until the situation actually
> >>>>arises. If the former, please tell us about it so we'll be warned
> >>>>not to use that organization's products.
> >>>
> >>>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.
> >>
> >> ... 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.
>
> 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
mun...@gmail.com
> On Fri, Mar 16, 2007 at 02:08:15PM +0000, Flash Gordon set bits thusly:
>
> <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: mun...@gmail.com
> 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 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?
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.
> > 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.
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
mun...@gmail.com
> On Sun, Mar 18, 2007 at 04:04:48PM -0700, munt...@gmail.com set bits thusly:
>
>
>
> > Newsgroups: comp.lang.c
> > Date: 18 Mar 2007 16:04:48 -0700
> > Subject: Re: C89, size_t, and long
>
> > On Mar 18, 3:40 pm, "Steve Thompson" <steve49...@yahoo.ca.ca> wrote:
> > > 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.
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:
>>> 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.
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>
> > 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?
>
> 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