Re: C89, size_t, and long

Yevgen Muntyan wrote:
Richard Bos wrote:
Yevgen Muntyan <muntyan.removethis@xxxxxxxx> wrote:

Richard Bos wrote:
Yevgen Muntyan <muntyan.removethis@xxxxxxxx> 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
esosman@xxxxxxxxxxxxxxxxxxx
.

Relevant Pages

  • Re: C89, size_t, and long
    ... libraries which have useful stuff). ... but you can hardly blame the consequences on the Standard headers. ... First, there are identifiers that are reserved for future use, ... and if you use `strdup' or `streptomycin' ...
    (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: pass by reference
    ... >> undefined behavior to write a function that has the same as a standard ... Each name declared as an object with external linkage in a header is ... Each header declares or defines all identifiers listed in its ... compiled source code and pre-build libraries, ...
    (alt.comp.lang.learn.c-cpp)