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