Re: [ECOS] structure size

[Chris Gray <chris dot gray at kiffer dot be>]

On Monday 05 January 2004 17:12, Grant Edwards wrote:
> >     William> Although your answer is a 'better' solution in that
> >     William> it gives a developer more power over individual
> >     William> structures, I thought it would be interesting to turn it
> >     William> on once for an entire module.
> >
> > That is usually a bad idea. When you #include system headers
> > you would be defining data structures laid out differently
> > from how the rest of the system understands those structures.
> > Those headers may also define inline functions which
> > manipulate those structures, and things quickly get very
> > messy.
> >
> > Also, when the compiler inserts padding it usually does so for
> > a good reason: manipulating packed structures can involve a
> > significant performance penalty.
>
> Not only that, on many systems (ARM, SPARC, H8, ...)
> manipulating packed structures can cause bus faults (if you're
> lucky) or silently produce incorrect results.

You'd better believe it. ARM in particular seems to just quietly rotate data 
when you make non-aligned accesses, which is one very effective way to go 
insane.

Beware also constructs like
  typedef union foo {
    UINT32 u32;
    struct {
       UINT8 a;
       UINT8 b;
       UNIT8 c;
       UINT8 d;
    } u8x4;
  } foo;

To which byte of u32 does u8x4.a correspond? Are you sure?

As for bitfields - don't let me start. ;->

> Be very, very careful when packing structs.  You can get bit.
> Or more likely, somebody else will get bit in the future when
> they try to figure out why your code stopped working...

-- 
Chris Gray                                  /k/ Embedded Java Solutions
Embedded & Mobile Java, OSGi              http://www.kiffer.be/k/
chris.gray@kiffer.be                                      +32 477 599 703

-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss