Re: ARM compiler misbehaves ?

[Richard Earnshaw <Richard dot Earnshaw at arm dot com>]

On Thu, 2004-04-29 at 16:39, Grant Edwards wrote:
> On Thu, Apr 29, 2004 at 04:35:26PM +0100, Richard Earnshaw wrote:
> 
> >> So casting the pointer to a (char*) or (void*) should guarantee
> >> that the memcpy() works correctly.  Assuming that the "&"
> >> operator on a packed field correctly returns the address of the
> >> first byte in the field.
> > 
> > No.  The compiler is entitled to infer alignment (and other
> > things, such as aliasing, but lets not go there right now)
> > through casts.
> > 
> > If you lie to the compiler it's entitled to do all sorts of
> > random things.  Putting something that isn't suitably aligned
> > into a pointer that implies some alignment is lying to the
> > compiler...  It doesn't matter how much you try to camouflage
> > it, once you've lied you get exactly what you deserve.
> 
> Boy.  The C standards people have sure worked hard to make it
> as difficult as possible to deal with externally constrained
> data layouts (e.g. network protocol frames).
> 

They worked extremely hard to try and overcome C's type weakness so that
compilers could do a reasonable job of optimizing the result in the
common cases.

> The only thing guaranteed to work is to declare everything as
> an array of unsigned chars and bash bytes around manually.

Yep.  If you want to write strict ISO-conforming C, that's pretty much
what you have to do.  And embedded programmers messing with casts
(particularly pointer casts) should read section 6.3.4 (cast operators)
very carefully indeed.

R.

------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com