[PATCH] Unix datagram socket messaging

[Volker Lendecke]

On Thu, Apr 17, 2014 at 09:23:50AM +0200, Stefan (metze) Metzmacher wrote:
> Hi Volker,
> 
> >> When this breaks, hasn't all the of Samba and all the other software
> >> written for BSD sockets also broken?  
> > 
> > That's why I was asking how this is supposed to work.
> > 
> > My understanding of the C standard snippets that I pasted
> > indicates that all of this depends upon undefined C
> > behaviour. In theory, a highly optimized compiler could
> > break a lot of socket code in the future. It is unlikely to
> > happen, so the void * cast is probably fine for the majority
> > of cases right now.
> > 
> > Apart from that, I would really like to know how this is
> > supposed to work without depending on behaviour that
> > compilers might break without us knowing. I'm doing C coding
> > for more than 20 years now, and I still don't understand the
> > corner cases of the language. That's why I am interested in
> > this purely academic question :-)
> 
> My guess is that the (void *) cast tells the compiler to avoid the
> optimization.
> 
> The gcc manpage says (in the -fstrict-aliasing section):
> 
> 	... In particular, an object of one type is assumed never to reside at the
> 	same address as an object of a different type, unless the types are
> almost the same....
> 
> And in this case the structures are forced (by special __SOCKADDR*
> defines in the headers)
> to be "almost the same".
> 
> 	... Even with -fstrict-aliasing, type-punning is allowed, provided the
> memory is accessed
>         through the union type....
> 
> So the union solution would also work.

That's the gcc manpage for some current version. In the
recent past, there have been prominent cases (I believe even
security problems) due to gcc more and more depending on
undefined C behaviour to sqeeze more performance out of code
at high optimization levels.

Don't get me wrong, for me anything that works now is ok.

But I want to know if there is a solution for this problem
that is 100% proof against compiler optimizations within
current language standards. Possibly there is no solution
and we have a gap between C and the socket API.

Volker

-- 
SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen
phone: +49-551-370000-0, fax: +49-551-370000-9
AG Göttingen, HRB 2816, GF: Dr. Johannes Loxen
http://www.sernet.de, mailto:kontakt at sernet.de