lkml.org 
[lkml]   [1999]   [Jun]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: egcs-1.1.2 ping bug also causes miscompilation of pcbit isdn drive
    Date
    From
    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/

    \
     
     \ /
      Last update: 2005-03-22 13:52    [W:0.023 / U:0.896 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site