Re: C89, size_t, and long

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.

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
esosman@xxxxxxxxxxxxxxxxxxx
.

Relevant Pages

  • Re: C89, size_t, and long
    ... libraries which have useful stuff). ... or for some other obscure reasons. ... the standard headers that it is almost as universal as a keyword. ... First, there are identifiers that are reserved for future use, ...
    (comp.lang.c)
  • Re: C89, size_t, and long
    ... 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? ... do not use features from standard headers". ... What I have done is told customers that given versions of libraries were broken and that they had to upgrade. ... 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. ...
    (comp.lang.c)
  • Re: C89, size_t, and long
    ... libraries which have useful stuff). ... stddef.h in library headers due to bugs in C implementations ... stuff into standard headers. ... strdup, strndup, strdupa, strndupa - duplicate a string ...
    (comp.lang.c)
  • Re: [SLE] GCC problem - math.h included, but fmod not available
    ... Sunday, 08 January 2006 15:34 samaye, Per Jessen alekhiit: ... So how do I find out which functions defined in which standard headers are ... included in the default libraries and which not? ...
    (SuSE)
  • Re: regarding size_t
    ... size_t is a typedef for some unsigned integer type meant to be ... anything defined in any standard headers. ... Reserved identifiers ... so none of the cases that say identifiers are ...
    (comp.lang.c)