🚀 go-pugleaf

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