This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: structure size
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