> 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.
>
Wonderful. Now try that with local data on a push-up stack rather than
the usual push-down stack.
There is a requirement that pointer math work, i.e., char[1] be addressed
at a higher offset value than char[0]. This has been interpreted to mean
a higher memory location and it's not nocessarily so.
Given a communications packet such as TCP/IP......
struct {
HEADER hdr;
char user_data[0];
} IP;
The assumption that this will always work is wrong (aside from the
fact that a zero-length array is not allowed either.
Cheers,
Dick Johnson
***** FILE SYSTEM WAS MODIFIED *****
Penguin : Linux version 2.2.6 on an i686 machine (400.59 BogoMips).
Warning : It's hard to remain at the trailing edge of technology.
-
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/