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

Malcolm Beattie (mbeattie@sable.ox.ac.uk)
Tue, 15 Jun 1999 15:29:48 +0100 (BST)

Richard B. Johnson writes:
> On Mon, 14 Jun 1999, Michal Jaegermann wrote:
>
> > I am posting this before somebody will jump to a conclusion that
> > "because egcs may have problems on Intel this implies that it will
> > have the same trouble on Alpha, or other processor, as well".
> >
>
> [SNIPPED]
>
> The problem with 'endian-ness` and other incompatibilities where
> packets have to be assembled (such as networking), was addressed
> using macros such as htons, htonl, etc.
>
> According to my interpretation of the current 'C' standard, members
> in structures can only be addressed by using the member name. No
> assumption may be made about the actual location of a particular
> member, nor the physical size of the object in memory. Note, in
> the following discussion, the word 'object' means "a specific
> addressable item". It has nothing to do with C++.
>
> struct {
> char one;
> short two;
> long three;
> double four;
> } foo;
>
> foo.one != (*(char *)&foo);
>
>
> To preserve alignment, the compiler could put member 'four' first.
> I have never seen one that does, but it could, based upon the requirement
> that members are accessible only via their member names.

I'm getting a bit fed up of all the wrong information that's flying
around in this thread. If people aren't absolutely sure and can't
quote chapter and verse then they should keep out of it.

Section 6.5.2.1 of the ANSI/ISO 9899-1990 standard says:

Within a structure object, the non-bit-field members and the
units within which bit-fields reside have addresses that
increase in the order in which they are declared.

This specifically means that the fields above must appear in the order
one, two, three, four and can't be re-ordered. It goes on to say:

A pointer to a structure object, suitable converted, points to its
initial member (or if that member is a bit-field, then to the unit
in which it resides), and vice versa. There may therefore be
unnamed padding within a structure object, but not at its
beginning, as necessary to achieve the appropriate alignment.

This means that, contrary to what you claim, the condition

foo.one == (*(char *)&foo);

is indeed guaranteed to hold.

--Malcolm

-- 
Malcolm Beattie <mbeattie@sable.ox.ac.uk>
Unix Systems Programmer
Oxford University Computing Services


-
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/