On Tue, May 29, 2007 at 08:06:59PM -0400, der Mouse wrote:
> > sockaddr_storage is, by definition, large enough to contain any
> > protocol-specific sockaddr.  That's what it's for.
> 
> Then it needs to be enlarged substantially; the only limit on AF_LOCAL
> sockaddr size I can find is the one implied by the various *_len fields
> (including sun_len) being unsigned char.  (I consider this limit a bug,
> especially as it's not documented as far as I can see.  unix(4) implies
> the limit is 104, without giving a manifest constant for the limit,
> without explaining why it's 104 and not, say, 126, and without
> explaining that the actual limit is entirely different.)

Without taking up the other issue (where I mostly agree with you): I don't
think _this_ use of sockaddr_storage in a structure is a problem with
regard to AF_LOCAL, because you can't do an interface ioctls on an AF_LOCAL
socket: it has no interface.

If there are other sockaddrs hiding in structures sent up to or down from
the kernel, I agree, the size needs to get larger to handle AF_LOCAL
addresses, the length on the limit of which should, in fact, be documented,
regardless.

I think a sockaddr_storage is 256 bytes on FreeBSD.  Maybe it should be
here, too, to address this issue.  But *that* would, I think, present a
whole new set of backwards compatibility issues.

Thor