Newsgroups: comp.lang.c Path: utzoo!utgpu!utfyzx!sq!msb From: msb@sq.sq.com (Mark Brader) Subject: Re: sizeof a struc field Message-ID: <1989Sep25.060407.1940@sq.sq.com> Reply-To: msb@sq.com (Mark Brader) Organization: SoftQuad Inc., Toronto References: <7710@microsoft.UUCP> <11086@smoke.BRL.MIL> <131@dtoa3.dt.navy.mil> <11110@smoke.BRL.MIL> <8361@ardent.UUCP> <11120@smoke.BRL.MIL> Date: Mon, 25 Sep 89 06:04:07 GMT > > With regard to a discussion of: > > sizeof(((struct abc *)0)->ghi) > > ... > (((struct abc *)0)->ghi) is not a valid unary expression, > because the left-hand operand of the -> is not an lvalue > that points at an object (see 3.3.2.3 Semantics). The wording there -- I checked it, but don't have it at hand -- does indeed appear to make such a requirement. But if we interpret it in the way that Doug does, then we also have to forbid sizeof (foo->ghi) where foo is an otherwise unused, automatic variable of the appropriate pointer-to-struct type. Such a prohibition seems ridiculous to me. I claim that 3.3.2.3 must therefore describe the semantics of the -> operation only when such an operation is actually attempted. I think that the wording should have made clear that the result of "sizeof expression" is independent of the actual values entering into the expression, and that the (notional) type of the result of -> is the type of the member even when no result is possible. Similarly, sizeof(300*300) should be sizeof(int) whether or not the computation of 300*300 in ints causes an overflow trap, and so should sizeof(a*b) where a and b are otherwise unused auto ints. -- Mark Brader, SoftQuad Inc., Toronto, utzoo!sq!msb, msb@sq.com A standard is established on sure bases, not capriciously but with the surety of something intentional and of a logic controlled by analysis and experiment. ... A standard is necessary for order in human effort. -- Le Corbusier This article is in the public domain.