[asterisk-dev] [asterisk-commits] simon.perreault: branch group/v6-new r274766 - /team/group/v6-new/main/

Kevin P. Fleming kpfleming at digium.com
Thu Jul 8 13:03:34 CDT 2010


On 07/08/2010 12:44 PM, Tilghman Lesher wrote:
> On Thursday 08 July 2010 11:43:28 Simon Perreault wrote:
>> On 2010-07-08 12:27, Tilghman Lesher wrote:
>>> I had proposed that before in a code review, and he replied that it was
>>> intentionally ugly, since the port numbers were not aligned with one
>>> another in the union, thus making a port assignment to the wrong address
>>> type a coding error.
>>
>> This interpretation is a bit narrow. The rationale has nothing to do
>> with ports. It has to do with mistakenly using an IPv4 address as an
>> IPv6 address and vice-versa. I realize now that my example given on the
>> review board had to do with ports and could be misleading.
> 
> That's true, but if you buffer the header such that the port numbers between
> the two items in the union match up, you can similarly use the IPv4-mapped
> addresses within IPv6 to create an address which is backward-compatible with
> using the IPv4 address, assuming the upper bits are set correctly.  Of course,
> if the upper bits aren't set to the IPv4 mapping, the least significant
> 32-bits isn't an IPv4 address, but we can deal with that situation at least
> better.

OK, I understand the reasoning for not using the union... but you could
still avoid the memcpy() problems by writing the copy like this:

  *((struct sockaddr_in *) &addr->ss) = *sin;

Yes, it's ugly, but you're keeping the ugly on purpose in this case, and
if you forget an '*' or '&', the compiler will tell you.

-- 
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
skype: kpfleming | jabber: kfleming at digium.com
Check us out at www.digium.com & www.asterisk.org



More information about the asterisk-dev mailing list