[PATCH] Fix strict-aliasing warning in resolv/res_hconf.c

[Florian Weimer]

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