RE: RE: [lwip-devel] [bug #26273] etharp.c : fix alignment issue in etharp_raw

[Bill Auerbach]

The compiler assumes all pointers to structs are properly aligned.  All
local, static, and global struct allocations are going to be properly
aligned.  They would not be aligned when casting to pointers to those
structs.  Hence, pointer casting isn't portable or guaranteed to always
work.

It would be curious to see how it is handled if a union were used and the
casting removed.  I expect then with padding turned off that the compiler
might do the right thing.

Bill

>-----Original Message-----
>From: address@hidden
>[mailto:address@hidden On
>Behalf Of Simon Goldschmidt
>Sent: Wednesday, April 22, 2009 3:29 AM
>To: lwip-devel
>Subject: Re: RE: [lwip-devel] [bug #26273] etharp.c : fix alignment
>issue in etharp_raw
>
>> Casting pointers is not guaranteed to conform to alignment
>restrictions of
>> the target processor.  Non-casted pointers to char, short, int, and
>long
>> as well as implicit casts to these are safe.  If you can use standard
>C
>> constructs without casts, it should both be portable and work on all
>platforms.
>>  A bad aspect of C is that it has some portability shortcomings -
>pointer
>> casting and bit-fields come to mind.  I always try to avoid all
>pointer
>> casts other than to void * and char *.
>
>The issue here is that a 4-byte-aligned struct is casted to a 2-byte-
>aligned struct and copied (using operator=) to another 2-byte-aligned
>struct. However, the compiler seems to somehow think it has to copy to a
>4-byte-aligned struct and corrupts memory.
>
>I don't think that has to do with portability of casts, but rather think
>it's a bug in the compiler's implementation of operator= for structs...
>
>Anyway, the only real portable solution seems to be using memcpy,
>although I'm not a friend of that :-(
>
>Simon
>--
>Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen:
>http://www.gmx.net/de/go/multimessenger01
>
>
>_______________________________________________
>lwip-devel mailing list
>address@hidden
>http://lists.nongnu.org/mailman/listinfo/lwip-devel