Re: [ECOS] structure size

[Grant Edwards <grante at visi dot com>]

> Not necessarily true.

Perhaps it's not necissarily true, but it is in the case of GCC
generating code for ARM and SPARC.  I've tripped over it
several times on both architectures (in my code and in others).
If you pack a struct on those architectures using GCC, the
resulting code will result in misaligned accesses if the struct
members are misaligned (bus fault on SPARC and incorrect
results on ARM7).

> When you use attribute(packed) you are telling the compiler
> that some of the fields within the structure will not be
> aligned to their natural boundaries, so the compiler has
> enough information to do the right thing.

But it doesn't.  You would think that with a low-level systems
language like C the compiler would allow you to specify
physical layout of a data structure in memory and then generate
correct code to access it, but that's not the case.

> i.e. generate additional code to access fields a byte at a
> time, shifting as required. This is very different from code
> that misaligns data without telling the compiler about it,
> which will indeed lead to bus faults or incorrect results.

It could be different in theory, but with GCC it isn't
different (again, in my experience with SPARC and ARM7).  In my
experience the compiler generates misaligned accesses if the
struct members are packed on "bad" boundaries.

> It is true that attribute(packed) is not mainstream, so there
> is an increased risk that the compiler will fail to do the
> right thing. There are also some things you really won't want
> to do, e.g. taking the address of one field within a packed
> structure and then treating that as an ordinary pointer. If
> there are problems it is worthwhile checking exactly what code
> the compiler is generating.

-- 
Grant Edwards
grante@visi.com

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