This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Fix strict-aliasing warning in resolv/res_hconf.c
- From: Pedro Alves <palves at redhat dot com>
- To: Florian Weimer <fweimer at redhat dot com>, sellcey at imgtec dot com
- Cc: Andreas Schwab <schwab at suse dot de>, Roland McGrath <roland at hack dot frob dot com>, Paul Eggert <eggert at cs dot ucla dot edu>, libc-alpha at sourceware dot org
- Date: Wed, 27 May 2015 12:39:39 +0100
- Subject: Re: [PATCH] Fix strict-aliasing warning in resolv/res_hconf.c
- Authentication-results: sourceware.org; auth=none
- References: <5bfa6373-3817-4d31-a5ee-a8676e79b723 at BAMAIL02 dot ba dot imgtec dot org> <555BB55E dot 3050304 at cs dot ucla dot edu> <1432075989 dot 16668 dot 62 dot camel at ubuntu-sellcey> <555BC19B dot 90001 at cs dot ucla dot edu> <1432077972 dot 16668 dot 65 dot camel at ubuntu-sellcey> <20150519235817 dot 9516F2C3A73 at topped-with-meat dot com> <555C3E0B dot 2040404 at redhat dot com> <mvma8wzbqsv dot fsf at hawking dot suse dot de> <555C48F0 dot 2030208 at redhat dot com> <1432139240 dot 16668 dot 77 dot camel at ubuntu-sellcey> <55658C2A dot 70209 at redhat dot com> <5565A192 dot 6060106 at redhat dot com> <5565A5EF dot 1090909 at redhat dot com> <5565A79E dot 6010403 at redhat dot com>
On 05/27/2015 12:16 PM, Florian Weimer wrote:
> On 05/27/2015 01:09 PM, Pedro Alves wrote:
>> On 05/27/2015 11:50 AM, Florian Weimer wrote:
>>> On 05/27/2015 11:19 AM, Pedro Alves wrote:
>>>> On 05/20/2015 05:27 PM, Steve Ellcey wrote:
>>>>
>>>>> diff --git a/resolv/res_hconf.c b/resolv/res_hconf.c
>>>>> index 73942e8..3b05287 100644
>>>>> --- a/resolv/res_hconf.c
>>>>> +++ b/resolv/res_hconf.c
>>>>> @@ -444,13 +444,13 @@ _res_hconf_reorder_addrs (struct hostent *hp)
>>>>>
>>>>> ifaddrs[new_num_ifs].addrtype = AF_INET;
>>>>> ifaddrs[new_num_ifs].u.ipv4.addr =
>>>>> - ((struct sockaddr_in *) &cur_ifr->ifr_addr)->sin_addr.s_addr;
>>>>> + cur_ifr->ifr_addr_in.sin_addr.s_addr;
>>>>
>>>> Without adding a new union member, isn't the simplest to just take a
>>>> copy step?
>>>
>>> I think it's still undefined behavior.
>>
>> How so? AFAIK, it's implementation defined, and GCC allows type-punning provided
>> the memory is accessed through the union type.
>>
>> https://gcc.gnu.org/onlinedocs/gcc-5.1.0/gcc/Optimize-Options.html#Type-punning
>
> You mean, copy it to a union member of type struct sockaddr, and reading
> from that union as struct sockaddr_in?
Yes, just like the patchlet did:
+ ss.sa = cur_ifr->ifr_addr;
+ ifaddrs[new_num_ifs].u.ipv4.addr = ss.sin.sin_addr.s_addr;
That was implementation defined in C90 (6.3.2.3) "A member of a union object is
accessed using a member of a different type", and blessed in C99/TC3, 6.5.2.3,
footnote 80:
"If the member used to access the contents of a union object
is not the same as the member last used to store a value in the object, the
appropriate part of the object representation of the value is reinterpreted
as an object representation in the new type as described in 6.2.6 (a
process sometimes called "type punning")."
And given that sockaddr_in contains explicit padding and the sizes of the
objects match, C99+TC3 6.2.6.1 points 6 and 7 do not apply.
>
> (Based on my reading of the standard, memcpy does not change effective
> type if one has been assigned.)
Thanks,
Pedro Alves