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: Florian Weimer <fweimer at redhat dot com>
- To: 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: Tue, 26 May 2015 20:51:24 +0200
- 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> <555F1430 dot 5050301 at redhat dot com> <1432666068 dot 28747 dot 19 dot camel at ubuntu-sellcey>
On 05/26/2015 08:47 PM, Steve Ellcey wrote:
> On Fri, 2015-05-22 at 13:34 +0200, Florian Weimer wrote:
>> On 05/20/2015 06:27 PM, Steve Ellcey wrote:
>>
>>> I don't know if this change is going to be considered acceptable or not
>>> but here is a complete patch with the new union member, a macro
>>> definition to access it (in order to match the other union members) and
>>> the needed change to resolv/res_hconf.c.
>>
>> It would be more conservative to drop the #define (due to the lack of
>> scope for preprocessor macros). Maybe also add a comment to header
>> saying that application code should use the ifru_addr_in member, not the
>> other struct sockaddr members due to C aliasing issues. Application
>> will run into the same issue, the existing definition was likely
>> impossible to use correctly. This is the reason why I suggest not to
>> add a __ prefix to the ifru_addr_in member.
>>
>> But from a API risk perspective, adding the member is fine—I think,
>> others might disagree. There is no ABI risk because of the existing
>> padding in struct sockaddr.
>
> Skipping the macro may be more conservative but if we think users are
> going to need or want to use the ifru_addr member to avoid the strict
> aliasing warnings then not having the macro there seems awkward by
> making that field different than all the rest.
Okay, seems reasonable. But please add a comment about the aliasing issue.
> I would like to get a fix for this checked in, this is the last of the
> glibc problems I am having when building with the top-of-tree GCC.
I think it's okay, but better wait a one or two days to see if anyone
else has objections.
--
Florian Weimer / Red Hat Product Security