[PATCH] Unix datagram socket messaging

[Volker Lendecke]

On Wed, Apr 16, 2014 at 12:55:54PM +0200, Stefan (metze) Metzmacher wrote:
> > The correct way to avoid this is to do a memcpy. I will
> > convert to that.
> 
> I don't think so 'struct sockaddr' is too small, as far
> as I can tell this is the only way to avoid this warnings,
> other than defining a union, which would be overkill for this case.

Even a union will not do it correctly:

http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1256.pdf
has on page 73 in footnote 82:

> If the member used to access the contents of a union object is not
> the same as the member last used to store a value in the object,
> the appropriate part of the object representation of the value is
> reinterpreted as an object representation in the new type as described
> in 6.2.6 (a process sometimes called "type punning"). This might be a
> trap representation.

A trap representation is defined on page 37 in 6.2.6.1, paragraph 5 as:

> Certain object representations need not represent a value of the object
> type. If the stored value of an object has such a representation and
> is read by an lvalue expression that does not have character type, the
> behavior is undefined. If such a representation is produced by a side
> effect that modifies all or any part of the object by an lvalue expression
> that does not have character type, the behavior is undefined. Such a
> representation is called a trap representation.
 
So it is undefined behaviour to create a union of struct
sockaddr_un and struct sockaddr, store into one member and
read from another one. We're not the first ones trying to
solve this unspecified behaviour, I'm probably just not able
to correctly read the C standard.

Is anybody out there who knows how to correctly bind a unix
domain datagram socket without using undefined C behaviour?
Or is it just not possible to do in C?

Thanks,

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