Grant Edwards @ Thu, 14 Feb 2008 16:46:15 +0000 (UTC)
>
> On 2008-02-14, Oleg Verych <[email protected]> wrote:
[]
>>| typedef struct tTestPointer
>>| {
>>| uint8_t m;
>>| uint16_t k;
>>| uint32_t l;
>>| } __attribute__ ((packed)) tTestPointer;
>>
>> padding can be inserted after 'm' (gcc) or *before* (by design). Latter,
>> as it seems, is going to work for wire protocols without overhead. No?
>
> Yes. But that's a very specially contrived case. In the wild,
> The chances that you can get all of the fields in a struct to
> align by adding padding at the beginning of the structure are
> going to be pretty slim.
This is help for WenZhan Song, i hope (i've started all this too dodgy :)
> struct t
> {
> uint16_t u1;
> uint8_t b1;
> uint16_t u2;
> }
>
> If you have to deal with data layed out like that, there's
> nothing you can do besides doing byte-by-byte access of the
> misaligned fields. You simply can't have both u1 and u2
> aligned.
This is problem of high-level design, or blame whatever you want (e.g.
8-bit past, Intel+MS hegemony, C and its "implementation-defined"), but
not msp430 toolchain.
C was meant to be a macro-language for PDP-11 or something like that. And
all this is *text*. 30+ years of C, 20+ years of diff + patch --
something is very strange with _modern software technology_.
"2.3.2 Just rewrite the code (best solution!)"[0] is an option, but rethink
your text processing tools(R) is IMHO even better one.
[0]
http://lecs.cs.ucla.edu/wiki/index.php/XScale_alignment#Just_rewrite_the_code_.28best_solution.21.29
_______
