Re: comm_connect_addr broke in squid3/trunk?

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