🚀 go-pugleaf

In article <470@taumet.com> steve@taumet.com (Stephen Clamage) writes:
>Section 3.5.2.3 says that an incomplete type "may be used only when
>the size of an object of the specified type is not needed."
>
>So if you had
>	struct foo x;
>	size_t bar() { return sizeof(x); }
>	struct foo { int i; };
>this would violate the constraint, as would
>	struct foo x, y;
>	void bar() { x = y; }
>	struct foo { int i; };

Prove the second example.  By reference to the standard only, please.
It is not hard to construct an implementation which can deal with the
assignment without knowing the size at the time (e.g., by generating
a call to memcpy() which references a to-be-filled-in-later variable
for the size of the struct).  I can find nothing in the standard which
makes your second example violate this so-called "constraint".

As I've said earlier, the *only* place where that "constraint" appears
to operate, based strictly on the wording of the standard, is in
"sizeof".  Everywhere else, sufficient cleverness in the implementation
can avoid it, by postponing decisions.  The only reason that "sizeof"
is an exception is that the standard demands that its value be known
at compile time.

>Section 3.5.2.3 says that an incomplete type "may be used only when
>the size of an object of the specified type is not needed."

The trouble is that nothing in the standard, anywhere, ever, says
"the size of the object is needed for this construct".  One can only
infer that "needed" refers to "needed by the implementation", which
leaves the whole issue (apart from "sizeof") implementation-defined and
makes nonsense out of the committee's recent interpretation.
-- 
Imagine life with OS/360 the standard  | Henry Spencer at U of Toronto Zoology
operating system.  Now think about X.  |  henry@zoo.toronto.edu   utzoo!henry