This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [pushed] Fix struct sockaddr/sockaddr_in/sockaddr_un strict aliasing violations


On 03/07/2015 06:00 PM, Eli Zaretskii wrote:
>> From: Pedro Alves <palves@redhat.com>
>> Date: Sat,  7 Mar 2015 17:44:26 +0000
>>
>> Building gdbserver in C++ mode shows:
>>
>>   gdb/gdbserver/tracepoint.c: In function âvoid* gdb_agent_helper_thread(void*)â:
>>   gdb/gdbserver/tracepoint.c:7190:47: error: cannot convert âsockaddr_un*â to âsockaddr*â for argument â2â to âint accept(int, sockaddr*, socklen_t*)â
>> 	  fd = accept (listen_fd, &sockaddr, &tmp);
>>
>> A few places in the tree already have an explicit cast to struct
>> sockaddr *, but that's a strict aliasing violation.  Instead of
>> propagating invalid code, fix this by using a union instead.
> 
> Yuck!  Isn't there a better way?  Why do we have the original problem
> to begin with, i.e. where did the incompatible data type come from?

Those are BSD socket types, they've been this way ever since BSD
invented them.  The structs are not type compatible, even though
they have some common fields that are are put at the same offsets,
by design.

See e.g.:

  http://stackoverflow.com/questions/1429645/how-to-cast-sockaddr-storage-and-avoid-breaking-strict-aliasing-rules

Lots of packages fixed this around the gcc 4.4 era, but gdb managed
to never triggers the warnings.  See e.g., (from a quick google search):

  http://comments.gmane.org/gmane.network.inn/8891
  http://pidgin.im/pipermail/commits/2010-April/016956.html

> (Does it even make sense to work around C++ restrictions while
> converting code to C++?)

It's not a C++ restriction.  The old code was invalid C code.

Thanks,
Pedro Alves


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]