Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!taumet!steve
From: steve@taumet.com (Stephen Clamage)
Newsgroups: comp.std.c
Subject: Re: X3J11 Pleasanton meeting summary
Keywords: X3J11 Pleasanton meeting C standard interpretations
Message-ID: <470@taumet.com>
Date: 4 Oct 90 19:40:49 GMT
References: <13996@smoke.BRL.MIL> <3206@mcrware.UUCP>
Organization: Taumetric Corporation, San Diego
Lines: 29

jejones@mcrware.UUCP (James Jones) writes:

>In article <13996@smoke.BRL.MIL> gwyn@smoke.BRL.MIL (Doug Gwyn) writes:
>>	struct foo x;
>>	struct foo { int i; };
>>	/* the above is strictly conforming; incomplete-type objects can
>>	   be defined, so long as by the end of the translation unit the
>>	   type becomes complete so that storage can then be allocated */

>Gee.  This seems to me to be rather inconsistent with other constraints
>placed on C that appear to have as their justification allowing straight-
>forward one-pass compilation.

I believe the statement above attributed to Doug is not quite correct.
The "struct foo x;" declaration uses an "incomplete type".
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; };
-- 

Steve Clamage, TauMetric Corp, steve@taumet.com