Re: C89, size_t, and long

Eric Sosman wrote:
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.

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
.

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: .h for standard headers
    ... The fundamental arrogance in the C++ Standard was thinking that ... It declares all names within namespace std. ... the world on notice that headers like will one day go ... a couple of libraries do meet these requirements. ...
    (comp.lang.cpp)
  • 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: novice: small annoyance
    ... >> own version all.h by including all the standard headers do not get that ... I don't like the idea of the compiler getting things "as ... It would become hard to get specific headers that ... I want and also get defaults from other libraries. ...
    (alt.comp.lang.learn.c-cpp)