Re: C89, size_t, and long

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

(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
.

Relevant Pages

  • Re: C89, size_t, and long
    ... libraries which have useful stuff). ... 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? ... 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. ... but you can hardly blame the consequences on the Standard headers. ...
    (comp.lang.c)
  • Re: C89, size_t, and long
    ... libraries which have useful stuff). ... 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? ... want to have standard headers included in their own headers which ...
    (comp.lang.c)
  • Re: C89, size_t, and long
    ... ISO type and the idea behind it is broken; the only valid reason to have ... theoretical possibility of brokenness when you already know that you ... stddef.h in library headers due to bugs in C implementations ...
    (comp.lang.c)
  • Re: C89, size_t, and long
    ... libraries which have useful stuff). ... but you can hardly blame the consequences on the Standard headers. ... to use strndup, it's personal matter between user and his C ...
    (comp.lang.c)
  • Re: kids and their furniture?
    ... I would always honor and respect any house rules I was ... standards that differed significantly from the range of behaviors ... I think it's pretty close to the legal 'reasonable person' standard. ... too much work to reason one's way through every single ...
    (misc.kids)