🚀 go-pugleaf

Lawrence Kirby <fred@genesis.demon.co.uk> wrote:
>In article <48gu0r$91o@news0.rain.rg.net> plong@perf.com "Paul Long" writes:
>
>>What does "the size...is not needed" mean? "Needed" sounds awfully vague. For
>>example, is the size needed here?
>
>I think it is clear enough that size is needed in contexts that require
>an object type and not needed in contexts that allow an incomplete type
>(since the distinction between object/incomplete types is exactly
>whether the size of the type is known).

Sounds like you've just restated the problem in slightly different
terms. The Standard is quite clear in most areas as to whether an object
type or incomplete type is allowed/required, for example, the types of
operator operands. However, it is silent regarding whether the objects
in the following situations have object or incomplete type:
   1. a parameter and
   2. a full expression that only references the value of an object,
      as in x;.
If the Standard is indeed silent in these cases (I'd actually prefer
that someone prove me wrong), the behavior is undefined.

>>   struct S x;
>>   void foo() { x; }
>>
>>I don't think so, but perhaps this is implementation-dependent.
>
>struct S x is the definition of an object x and requires an object type so
>size is needed.

No, an "object" can be described at various points in a translation unit
by an object type _or_ an incomplete type. See section 6.1.2.5, paragraph
1. You see, "object" is overloaded. This has tripped up myself and others.

>This would have been OK with extern struct S x; or if struct S
>had been completed by an earlier or later declaration of it.
>
>>How about this one:
>>
>>   void bar(struct T x) { x; }
>>
>>Is this a conforming program? Is a diagnostic required?
>
>Functions parameters are defined to be lvalues and hence objects - they must
>have an object type.

Again, an object is not required to have an object type.

Section 6.7.1 says, under Semantics, that after array and function
adjustment, "The resulting parameter type shall be an object type."
However, it is silent regarding the parameter type starting out as
incomplete, as in "foo(struct S x){}". Even if we accepted that
"shall be an object type" referred to parameter types as coded, the
behavior would still be undefined because this is a Semantics
interpretation, not a Constraint.

-- 
Paul Long         plong@perf.com       http://www.teleport.com/~pciwww/
  "A perfect method should not only be an efficient one, as respects
  the accomplishment of the objects for which it is designed, but
  should in all its parts and processes manifest a certain unity and
  harmony." - George Boole, _An Investigation of the Laws of Thought_