On Sun, 15 Oct 2000, Andrew Morton wrote:
> There is a bug in gcc-2.7.2.3. It incorrectly lays out
> structure initialisers when the `name:value;' construct is used.
>
>
> Here is the degenerate case:
>
> struct struct_1 { int a; };
>
> struct thing {
> int a;
> struct struct_1 b;
> };
>
> struct thing a_thing = {
> // a: 0, /* Uncomment this for correct code */
> b: {0},
> };
>
>
> Which produces:
>
> .file "e.c"
> .version "01.01"
> gcc2_compiled.:
> .globl a_thing
> .data
> .align 4
> .type a_thing,@object
> .size a_thing,8
> a_thing:
> .zero 4
> .zero 4
> .long 0
> .ident "GCC: (GNU) 2.7.2.3"
>
> Note the extra `.zero 4'.
>
>
> 3: Don't use gcc-2.7.2.3 (use one of the later compilers and
> put up with 50% longer build times).
>
> 4: Fix gcc-2.7.2.3
>
The 'C' language can order structure members anyway it wants. It also
can add any 'fill' or alignment bytes it wants. The compiler is not
broken in this respect.
If the structure must exist in memory exactly as you have
coded it (i.e., a template), then you have to use some 'extentions'
that are not part of the 'C' language, but are often provided
by the compiler(s), __attribute__ ((PACKED)), comes to mind.
When using bit-fields, the same is true. This is why you never
use bit-fields to access hardware. Instead you use machine-specific
unsigned shorts, ints, longs, etc.
Truly 'portable' stuff, like network-sync-crash programs, use
character arrays to generate network packets. It is not allowed
for a 'C' compiler to introduce extraneous characters within such
an array or at its beginning. However, it can append anything it
wants, i.e., fill up to the next machine-specific alignment.
Cheers,
Dick Johnson
Penguin : Linux version 2.2.17 on an i686 machine (801.18 BogoMips).
"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Oct 15 2000 - 21:00:29 EST