RE: FW: [iPAQ] skiff tools question

From: George France <france.a.t.crl.dec.com>
Date: Thu Sep 14 2000 - 19:38:52 EDT

Jamey is correct. I did not see the [1]. I thought it was [0].

Please note that the netwinder uses a kernel handler for this issue. I have
not looked at the code. Does anybody know more????

--George

> -----Original Message-----
> From: Jamey Hicks [mailto:jamey@crl.dec.com]
> Sent: Thursday, September 14, 2000 7:16 PM
> To: 'Gordon McNutt'; ipaq@handhelds.org
> Subject: 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
>
> _______________________________________________
> iPAQ mailing list
> iPAQ@handhelds.org
> http://handhelds.org/mailman/listinfo/ipaq
>
Received on Thu Sep 14 16:36:18 2000

This archive was generated by hypermail 2.1.8 : Tue May 04 2004 - 09:43:42 EDT