Re: [Libevent-users] Adding ipv6 support.

[William Ahern <william@xxxxxxxxxxxxxxxxxx>]

On Mon, Feb 07, 2011 at 02:40:03PM -0500, Simon Perreault wrote:
> On 2011-02-07 14:09, William Ahern wrote:
> >> Furthermore, you're ignoring alignment issues.
> > 
> > There are no alignment issues here, arguably not even if we're talking pure
> > standard C. Certainly not in any implementation that supports the BSD
> > sockets API and the .sa_family member overlay.
> 
> It should be 64-bit aligned (see RFC 3493).
> 
> Just add the appropriate compiler-specific magic, or simply use
> sockaddr_storage.

The alignment of a union would be as strict as the strictest of its members,
because the standard guarantees that a pointer to a member of a union is
convertible to a pointer to that union, and vice versa. See C99 6.7.2.1.p14.
But because you can convert such pointers with only a declaration in scope
(and not a definition), it follows that all unions and structures must have
the same alignment. Q.E.D.

Basically, the way sockaddr_in6 and sockaddr_storage would be qualified to
align the struct in6_addr member would require an implementation to effect
internal padding (using knowledge of the universal alignment of structures
and unions), but always after the first member because of C99 6.7.2.1.p13,
which creates a similar equivalence discussed above with the first member in
a structure, disallowing padding at the beginning.

> >> The best current practice is to use sockaddr_storage. See e.g.
> >> http://www.kame.net/newsletter/19980604/ for more info.
> > 
> > That page is very BSD centric. For example, SysV derivatives like Solaris
> > and Linux don't have .sa_len.
> 
> The advice it contains applies everywhere. Application code should not
> make use of _len members.
> 

_len, however, is the source of the legitimate alignment concerns, because
the traditional BSD implementation with .sa_len made it the first member,
which means accessing an overlayed .sa_family (as the second member) was
strictly undefined according to the C standard (though required on all
existing BSD implementations because of historical practice). Basically,
accessing sockunion.sa.sa_family and sockunion.sin.sin_family was undefined
in standard C if _family wasn't the first member, and although it was
guaranteed to work (as the second member) on all existing BSD
implementations it was still a legitimate warning to people that in the
future it might not hold, so don't do it. (Although it would be beyond all
reason for this guarantee to not hold in the future; it would break an
insane amount of code.)
***********************************************************************
To unsubscribe, send an e-mail to majordomo@xxxxxxxxxxxxx with
unsubscribe libevent-users    in the body.