Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!decwrl!ogicse!daniels
From: daniels@ogicse.ogi.edu (Scott David Daniels)
Newsgroups: comp.std.c
Subject: Re: X3J11 Pleasanton meeting summary
Keywords: incomplete type, size, sizeof
Message-ID: <12672@ogicse.ogi.edu>
Date: 5 Oct 90 20:39:05 GMT
References: <13996@smoke.BRL.MIL> <3206@mcrware.UUCP> <470@taumet.com> <1990Oct5.173314.28454@zoo.toronto.edu>
Organization: Oregon Graduate Institute (formerly OGC), Beaverton, OR
Lines: 23

In article <1990Oct5.173314.28454@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes:
>In article <470@taumet.com> steve@taumet.com (Stephen Clamage) writes:
>>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; };
>...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"...

However, the preceding example is really no different.  If we presume the
fortuitous ``to-be-filled-in-later size variable,'' the return statement 
of the preceding example may load the return value register (or whatever 
convention the compiler prefers for results) from the same variable.  I
am not trying to pick on Henry Spencer.  I am just trying to make the
point that the committee's position is on a very slippery slope.  Since 
sizeof cannot be used to control preprocessing, I don't see where any 
special implementation difficulty is associated exclusively with sizeof.

Instead of choosing between two poor   | Scott Daniels at Oregon Graduate Inst.
    graphics standards, we get X       | daniels@cse.ogi.edu    ogicse!daniels