itojun@iijlab.net writes:

> >Log Message:
> >struct addrinfo.ai_addrlen used to be a size_t, per RFC 2553.
> >
> >In XNS5.2, and subsequently in POSIX-2001 and draft-ietf-ipngwg-rfc2553bis-02
> >it was changed to a socklen_t.
> >
> >To accomodate for this while preserving binary compatibility with the
> >old interface, prepend or append 32 bits of padding, depending on
> >the (LP64 data model) architecture's endianness.

> 	i'm not sure if "#if __sparc64__" is the best way to deal
> 	with this issue, will this be okay for new ports?

Yes, that's intentional.  The point of explicitly naming architectures
here is to preserve binary compatibility for those that are supported
_and_ have sizeof(size_t) != sizeof(socklen_t).  If a new architecture
is added for which this is also true, there's no binary compatibility
which needs to be preserved.

> 	btw, do you plan to do anything about getaddr/nameinfo function
> 	arguments?  POSIX-2001 changed some of size_t into socklen_t.

Yes.  That's actually the easy part, because these functions pass the
arguments to be changed in registers, and compatibility is preserved.

> 	(i don't really understand why they changed it, though)

There's a piece of (historical) information which Andrew Gollan
proposed to be added to the rationale:

 The type socklen_t is an unfortunate historical accident, and needed to
 be invented to cover the range of implementations seen in the field.
 The intent of socklen_t is to be the type for all lengths that are
 naturally bounded in size, that is, that they are the length of a
 buffer which cannot sensibly become of massive size: network addresses,
 hostnames, string representations of these, ancillary data, control
 messages, and socket options are examples.  Truly boundless sizes are
 represented by size_t as in read(), write(), etc.

 All socklen_t types were originally (in BSD UNIX) of type int.
 An overzealous unknown decided without significant review to "correct"
 all buffer lengths to size_t, which appears on its face to make sense.
 When dual mode 32/64 bit systems came along, this choice unnecessarily
 complicated system interfaces because size_t (with long) was a different
 size under ILP32 and LP64 models.  Reverting to int would have happened
 except that some systems had already shipped 64-bit only interfaces. The
 compromise was a type which could be defined to be any size by the
 implementation: socklen_t.



- Klaus