Steve Bennett <[EMAIL PROTECTED]> wrote:
> Sure, I'm happy to provide some feedback.
>
> You might say that the real problem is the arm gcc compiler.
No, processors that have been originally designed for DSP purposes, it is not
uncommon to have e.g. 24 bit "bytes".
> For whatever reason, it really likes to align things on 4 byte boundaries,
> and pad structures to 4 byte boundaries, even where most other compilers
> don't.
There is no reason to pas the size of a structure to a 4 byte boundary (except
when the code blows up "bytes" to 32 bits).
> (Such as the char arrays in the structures in question).
Did you test with a recent GCC using
#pragma pack(1)
I would expect that this also results in reduced sizes.
> Why is it this way? I can't say (perhaps another arm compiler did it this
> way).
> I know I don't like it because of the problems
> it causes with various apps on arm. But the C spec does not place any
> requirements on field alignment and structure padding, so we have to accept
> that it is OK.
First: C allows more freedom than POSIX......
POSIX requires char to be of a size that allows to deal with 8 bit char arrays
from external data.
> By rights, the use of C structures to represent physical storage should
> be avoided because of exactly this problem.
>
> I see the simplest solution is to use the one mechanism this compiler
> provides to force structure alignment/packing. The alternative of moving
> to a non-structure approach would surely require huge code changes.
>
> FWIW, yes, various other apps have problems too, especially those which
> represent network protocols as C structures. The __attribute__(packed)
> approach seems to be the preferred approach for these apps.
The official way to deal with problems like this is to use:
#pragma pack(1)
Jörg
--
EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin
[EMAIL PROTECTED] (uni)
[EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
