From: firstname.lastname@example.org (Linus Torvalds)
Subject: Re: libc vs glib
Date: 9 Jun 1998 20:10:34 GMT
In article <email@example.com>, <firstname.lastname@example.org> wrote:
>email@example.com (Kaz Kylheku) writes:
>> Then there is something called ``socklen_t'' which breaks existing code that
>> uses functions which require a pointer to address length. Existing code uses
>> pointer to int for this, which is incompatible with a pointer to socklen_t.
No. Because _any_ sane library _must_ have "socklen_t" be the same size
as int. Anything else breaks any BSD socket layer stuff.
If you find a library for which that isn't true, shoot the library
>> I'm puzzled why size_t isn't used, since at least that is cleaner from a
>> language point of view. The size_t type is the result type of the sizeof
>> operator and is intended for representing object sizes, thus it is natural for
>> representing the size of an address structure.
>This is required by POSIX 1003.1g. If you don't like it complain to the
>comitee. It is also required by the Single Unix Specification.
POSIX initially _did_ make it a size_t, and I (and hopefully others, but
obviously not too many) complained to them very loudly indeed. Making
it a size_t is completely broken, exactly because size_t very seldom is
the same size as "int" on 64-bit architectures, for example. And it
_has_ to be the same size as "int" because that's what the BSD socket
Anyway, the POSIX people eventually got a clue, and created "socklen_t".
They shouldn't have touched it in the first place, but once they did
they felt it had to have a named type for some unfathomable reason
(probably somebody didn't like losing face over having done the original
stupid thing, so they silently just renamed their blunder).