Problem report: Struct aliasing problem causes Thread_Ready_Chain corruption in 4.6.99.3

[Thomas Doerfler]

Kim,

when I look into the current RTEMS networking stack, you are right.
There we find:

struct sockaddr {
	unsigned char	sa_len;			/* total length */
	sa_family_t	sa_family;		/* address family */
	char	sa_data[14];		/* actually longer; address value */
};

struct sockaddr_in {
	uint8_t	sin_len;
	sa_family_t	sin_family;
	in_port_t	sin_port;
	struct	in_addr sin_addr;
	char	sin_zero[8];
};

sockaddr_in is sometimes overlayed by sockaddr, which is definitively
non-aliased.

IMHO we might come over this, by defining
struct sockaddr_in {
	struct sockaddr sa;
	in_port_t	sin_port;
	struct	in_addr sin_addr;
	char	sin_zero[8];
};

But then, the semantics to access elements in the "general" header would
change, which would break a huge amount of code dealing with sockets.
And would make them non-standard, I would guess.

You may come around this when you are writing application code, because
then you will work with ONE type of socket at a given piece of code, but
I am not sure how we can get over this without (partially) disabling the
aliasing optimizations...

Any hints?

wkr,
Thomas.


Kim Barrett schrieb:
> At 8:30 AM -0800 12/4/06, Till Straumann wrote:
>> While the optimization is optional, programs that violate the
>> aliasing rule are unfortunately not C99 compliant - the
>> standard does *not* declare this rule optional, unfortunately.
> 
> De-lurking briefly, in this very interesting discussion, to ask:
> 
> Am I confused, or is POSIX riddled with strict-aliasing violations?
> 
> I'm thinking, for example, of the struct sockaddr variants, where
> one allocates space for a sockaddr_in or sockaddr_un or whatever,
> but often passes it around as a (cast to) sockaddr*. While sockaddr
> has a "common initial sequence" (C99 6.5.2.3 para5) with sockaddr_in
> &etc, there is nothing I can find that would indicate that they are
> "compatible types" (C99 6.2.7 &etc), and 6.7.7 example 2 seems to
> explicitly indicate that they are not.
> 
> And since the aliasing rules are written in terms of "compatible
> types", this makes me suspicious.
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.com
> http://rtems.rtems.org/mailman/listinfo/rtems-users


-- 
--------------------------------------------
embedded brains GmbH
Thomas Doerfler           Obere Lagerstr. 30
D-82178 Puchheim          Germany
Tel. : +49-89-18 90 80 79-2
Fax  : +49-89-18 90 80 79-9
email: Thomas.Doerfler at embedded-brains.de
PGP public key available on request