Re: egcs-1.1.2 ping bug also causes miscompilation of pcbit isdn driver

Jedi/Sector One (j@4u.net)
Sun, 13 Jun 1999 22:57:23 +0200

> From: Tygrys <tygrys@tygrys.eu.org>
> Date: Sun, 13 Jun 1999 18:37:49 +0200
> Subject: Re: egcs-1.1.2 ping bug also causes miscompilation of pcbit isdn driver
>
> Lars Heete wrote:
>
> > --------------------- test case ----------------------
> > #include <stdio.h>
> > int main(int argc, char **argv) {
> > struct {char c1, c2, c2, 4;} t;
> > t.c4 = 0x78; t.c3 = 0x56; t.c2 = 0x34; t.c1 = 0x12;
> > printf("0x%x\n", *((unsigned long*) &t));
> > return 0;
> > }
> >
> > gives 0x12 with egcs-1.1.2 on i386, instead of 0x78563412.
> But only when compiled with optimization...

This behavior is *NOT* a bug in Egcs. A C compiler is free to reorder
the members of a structure (except the first one, and the last one if it
is a variable-size array in C9X) and/or to add several padding bytes.
Casting a structure object to a long value is a silly thing. It might
work, but the C standard explicitly prohibits this and tells that the
behavior is undefined.
C language is not assembly language and you'd better avoid this kind
of trick. Egcs would give you the expected values for t.c1, t.c2, t.c3
and t.c4, that is what it is supposed to do. Internal organisation of
the data in compiled code has not to be fixed in that case.
Read the standard before blaming a compiler.

-- 
 	      Standard C Programming language is now ISO C9X !
		       Frank DENIS aka Jedi/Sector One
				 <j@c9x.org>






-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/