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: Steve Ellcey <sellcey at imgtec dot com>
- To: Florian Weimer <fweimer at redhat 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 11:47:48 -0700
- 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>
- Reply-to: <sellcey at imgtec dot com>
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.
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.
Steve Ellcey
sellcey@imgtec.com