From: torvalds@transmeta.com (Linus Torvalds)
Newsgroups: comp.os.linux.development.system,comp.os.linux.development.apps
Subject: Re: libc vs glib
Date: 9 Jun 1998 20:10:34 GMT

In article <m3k96qoi8l.fsf@fred.muc.de>,  <ak@muc.de> wrote:
>kaz@cafe.net (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
maintainer.

>> 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
interface is.

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

		Linus