RE: FW: [iPAQ] skiff tools question

> I hope it's something that simple. But the following example makes me
> worry that it is not, as this example does not use structs:
>
> u8 buf[4];
> u16 *a;
> a = &buf[1];
> *a = 4;

This example shows a difference in behavior with unaligned pointers. This
is another area of non-portability in C. You're doing a 2-byte store on an
odd address. Depending on compilation and kernel options on the ARM, you
will get different results. x86 is specified to work with any pointer
alignment, but it is one of the few CPU architectures that behave this way.

>
> Printing the contents of buf shows one thing on the ARM:
>
> 0xbffffc40 = 0x4
> 0xbffffc41 = 0x0
> 0xbffffc42 = 0x0
> 0xbffffc43 = 0x0
>
> and another on the i386:
> 0xbffff914 = 0x0
> 0xbffff915 = 0x4
> 0xbffff916 = 0x0
> 0xbffff917 = 0x0
>
> It appears that on the ARM, the address of a variable is the last byte
> of the variable, but on the i386 it is the first. It seems that this
> makes overlaying structs non-portable.

Overlaying structures is, in general, non-portable. Sometimes it works, and
if you work hard you can sometimes make it work on all the platforms you're
interested in.

-Jamey
 
Received on Thu Sep 14 16:13:23 2000