Problem report: Struct aliasing problem causes Thread_Ready_Chain corruption in 4.6.99.3

Kim Barrett kab at irobot.com
Tue Dec 5 01:47:19 UTC 2006


At 3:14 PM -0800 12/4/06, Till Straumann wrote:
>Plus, it seems that there is a gcc (extension?) so that
>
>extern char *some_allocator();
>
>int tst()
>{
>char *rval = some_allocator();
>     rval[0]      = 0;
>     *(int*)rval = 0xffffffff;
>     return rval[0];
>}
>
>returns indeed 0xff (i.e., gcc assumes *(int*)rval may alias
>*rval) whereas
>
>extern short *some_other_allocator();
>
>int tst()
>{
>short *rval = some_other_allocator();
>     rval[0]  = 0;
>     *(int*)rval = 0xffffffff;
>     return rval[0];
>}
>
>returns 0. So gcc seems to not only allow char to alias type anything but
>also conversely anything to alias char. This is more relaxed than the
>standard which says

Interesting. I didn't know about that behavior for gcc. Some web searches
seem to indicate this might also be true for void*. Some further web
searches turned up the "may_alias" type attribute. I think that attribute
would solve the rtems chain problem, without the nasty (and I think not
actually portable in general) union approach.

Otherwise, for what it's worth, I agree with Till's description of what
the standard says, and the implications thereof. Yikes!



More information about the users mailing list