>> We want the better optimizations that "new C" enables more than we
>> want the semantics of "traditional C".

Is this an ex cathedra pronouncement?

>> Thus, anything that depends on "traditional C" should be fixed.
> [...mtod...]

Or struct sockaddrs.  You can finesse many uses (eg, the stuff coming
back from getaddrinfo()) by declaring that the _real_ object type is
the AF-specific one, and the struct sockaddr * is just an intermediate
type (which as I read the explanation is OK as long as its alignment
requirements are no stricter than any AF-specific version).  But how do
you propose to deal with code that uses struct sockaddr, or struct
sockaddr_storage, and references the sa_family/sa_len (resp.
ss_family/ss_len) members to decide which AF-specific struct to treat
it as?  Must code that does an accept() first check the address family
of the socket so it can know which AF's AF-specific sockaddr to cast to
struct sockaddr * for the second argument to accept()?  A whole lot of
code that uses sockaddr_storage is now broken by fiat, even though it
was written correctly according to the API as it existed up until this
language shift.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B