home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.std.c
- Path: sparky!uunet!unislc!ttobler
- From: ttobler@unislc.uucp (Trent Tobler)
- Subject: Re: Struct hack one last time (one last time)
- X-Newsreader: Tin 1.1 PL5
- References: <1993Jan8.190840.11087@taumet.com>
- Message-ID: <1993Jan8.220422.20084@unislc.uucp>
- Organization: Unisys Corporation SLC
- Date: Fri, 8 Jan 1993 22:04:22 GMT
- Lines: 36
-
- Steve Clamage (steve@taumet.com) wrote:
- : msb@sq.sq.com (Mark Brader) writes:
- :
- : >In particular, it could not modify padding at the end of a struct,
- : >precisely *because* it would break the struct hack.
- :
- : We seem to have some circular reasoning here.
- :
- : I proposed an implemention which I claimed was conforming on which
- : the struct hack would not work; therefore the struct hack is illegal.
-
- ...
-
- : For example, if the struct hack is strictly conforming, what about this:
- :
- : struct S {
- : double a[2];
- : double b;
- : } s;
- : s.a[2] = 1.0;
- :
- : The array reference exceeds the declared bounds of s.a, but not the
- : bounds of object s, because sizeof(s) can't be smaller than
- : sizeof(a)+sizeof(b). If a compiler can't add padding to the end of
- : the struct for other than alignment, then surely it can't add padding
- : between a and b, because it can't be required for alignment. Therefore
- : s.a[2] must be the same as s.b.
-
- First off, the compiler is free to add padding for whatever reasons it
- wants.. but it must not depend on the value of this padding information.
- Second, in your example, a[2] would be equal to 1.0. It says nothing
- about the value of b. Because the contents of b may or may not be changed,
- it's value is not definite.
-
- --
- Trent Tobler
-