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.