Henrik Nordstrom wrote:
tis 2008-04-01 klockan 17:24 +0800 skrev Adrian Chadd:
Wait a sec, which platforms don't have sin_len in which struct?
I think amos meant to say ss_len in struct sockaddr_storage, which not
very frequently seen as not all address families need a length.. (for
example on Linux)
I do not know of any platforms not having sin_len in struct sockaddr_in
or sockaddr_in6.. but I guess it doesn't really hurt to test for them
just in case.
I started out that way (assuming ss_len was absent but sin_len was
present) but a header analysis proved the assumption wrong. sin_len also
proves very absent from Debian Linux 2.6.25 headers.
OS that I know of and have tested the headers for all define a
SOCKADDR_COMMON() macro for these types which neatly ensures they all
have the same initial format within a given kernel. But not necessarily
the same as other kernels.
Linux
- defines s*_family as unsigned short (16-bits) padded with 0 on the
initial byte.
- fields set in Host-Order format.
FreeBSD
- defines s*_len also defined as a unsigned char or uint8_t placed as
the _first_ 8-bits of the struct.
- defines s*_family in two places: once as uchar once as uint8_t
(_second_ 8-bits).
- fields set in Network-Format.
AFAICT they are formally required to do so for sockaddr_in6. But not for
sockaddr_in or sockaddr_storage.
I'm having deja-vu here with my earlier experiments I think I mentioned.
Not quite exactly the same (better logic and info this time around), but
essentially a ushort/uchar difference in the family field bits.
The current patch adds a configure test for all three and uses the
ss_len if present, failing over to sin*_len if its present, then to
nothing if neither defined.
Either way it should fix this issue portably if a little messy.
Amos
--
Please use Squid 2.6STABLE19 or 3.0STABLE3
