Messages in this thread | | | Date | Tue, 15 Jun 1999 12:50:19 -0400 (EDT) | From | "Richard B. Johnson" <> | Subject | Re: egcs-1.1.2 ping bug also causes miscompilation of pcbit isdn drive |
| |
On Tue, 15 Jun 1999, Malcolm Beattie wrote:
> 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/
| |