Re: getaddr/nameinfo size_t -> socklen_t

[eeh%netbsd.org@localhost]

| itojun%iijlab.net@localhost 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.

Since socklen_t is defined in sys/ansi.h as `unsigned int' and is thus 
MI (which is IMHO bogus, but that's another issue) then any 64-bit 
architecture should have sizeof(size_t) != sizeof(socklen_t).  So you
should really be checking for _LP64 and _BYTE_ORDER == _BIG_ENDIAN.
And, as far as that goes, does x86_64 pad force that field to be padded
to 64-bits?  If not you may have the same problem there.

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

So...  Should we start overriding socklen_t in MD header files?

Eduardo