Problem report: Struct aliasing problem causes Thread_Ready_Chain corruption in 4.6.99.3

[Till Straumann]

The C99 standard invents special, magic semantics for 'memcpy' 'malloc' etc.
so that allocated memory can be 'assigned' an 'effective type'.

To me, this shows how inherently broken the alias rule is.
There are many occasions where you might want to provide
an allocator of some kind (e.g., allocate a buffer from a pool)
w/o knowing what type of object the item finally should represent.

However, it seems to me that you cannot 'c99-legally' write
such an allocator.

I can't figure out a way to, e.g., allocate a (generic) buffer,
read data into it and figuring out later that it is a UDP packet
and then access it as as 'struct udp_packet'.

I don't understand why C99's 'restrict' keyword was not enough...

T.

Kim Barrett wrote:
> At 9:16 PM +0100 12/4/06, Thomas Doerfler wrote:
>   
>> when I look into the current RTEMS networking stack, you are right.
>> [...]
>> Any hints?
>>     
>
> Nope. I was really hoping to be shown that I was wrong. It seems to me
> that if significant POSIX APIs are in violation of the aliasing rules,
> there are much bigger problems with the strict-aliasing option than the
> rtems chaining code.
>
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.com
> http://rtems.rtems.org/mailman/listinfo/rtems-users
>