Pointers to Incomplete Types in Prototypes

[Norman Diamond]

In article <1991May10.021509.9862 at athena.mit.edu> scs at adam.mit.edu writes:
>In article <1991May8.072112.20866 at tkou02.enet.dec.com> diamond at jit533.enet@tkou02.enet.dec.com (Norman Diamond) writes:
>>In article <1991May8.043353.28983 at athena.mit.edu> scs at adam.mit.edu writes:

>"Scope information," to my view, is the implicit property
>of which (nested) symbol table a given symbol is declared/defined
>in, which is of course the whole issue here.

Yes.

>>>In the absence of any previous mention of a struct bar,
>>>	type foo(struct bar *arg);
>>>is as much of a struct "definition" as is
>>>	type foo(struct bar { ... } *arg);
>>No.  The standard says that the presence of "{ ... }" declares a type.
>
>Well, I hope this doesn't sound like overly-persnickety verbal
>nitpicking, but the standard also says things like "A string
>literal is a primary expression."  I don't conclude that the
>presence of "{...}" is necessarily the only way of declaring a
>new type.

Sorry, it is.  How would you like a compiler to arbitrarily decide that
some of your references to variables are really declarations rather than
references (because the standard doesn't say that they aren't declarations),
and then reject your program for having illegal declarations?  Sorry, I
think we have to accept that the standard DOES say what a declaration is,
and that references are not declarations.

However, when I reread the section that you quote below,
    type foo(struct bar *arg);
declares the TAG bar, though it does not declare the type.
And the tag goes out of scope at the end of the function prototype.

OK, so Mr. Summitt and I both got lost in the rathole, and the HP ANSI C
compiler was right after all.  However, its warning was an optional one,
not a required one.

>>No part of the standard says that "struct bar *" declares a new type.
>>"struct bar *" must be a reference.

I was half right; a reference to a type which "shall" (but this is in a
Semantics section, not Contraints) be declared in the same scope.

>>Now:  The standard allows forward references for structure tags that
>>haven't been declared/[defined] yet.  It also allows references to structure
>>tags that are declared in outer scopes.  It does not explicitly say that a
>>single reference may take advantage of both of these features simultaneously.
>>But I think it must be allowed.  There is still no other meaning.
>
>I sort of agree, to the extent that neither analysis can be
>conclusively disproved.

We're both wrong here.

>>>If mentioning
>>>	struct bar *
>>>didn't suffice to "define" a struct bar (assuming it wasn't already "defined"),
>>
>>You betcha!  It doesn't!  RTFS.
Uh, you should have told me to RTFS.  It declares the tag bar.
>>
>>>then the one-line translation unit
>>>	struct bar *bp;
>>>would have to give some kind of an error, much like the "warning:
>>>struct bar never defined" which lint issues under the -h option.
>>
>>I think this might be true.  (Sorry, I'm not in the mood to look it up
>>at the moment.)

Ah, it wouldn't be true, because Semantics violations don't require
diagnostics.

>Well, I was, and I did, and from (still in section 3.5.2.3):
>	If a type specifier of the form
>		struct-or-union identifier
>	occurs prior to the declaration that defines the content,
>	the structure or union is an incomplete type.  It
>	declares a tag that specifies a type that may be used
>	only when the size of an object of the specified type is
>	not needed.  If the type is to be completed, another
>	declaration of the tag *in the same scope* ... shall
>	define the content [emphasis mine].

>Since section 3.5.2.3 specifically mentions that a later
>declaration in the same scope can complete a struct type (and
>the same point is made in the paragraph on incomplete types in
>section 3.1.2.5), I am led to believe that it was not the
>intention that a declaration in an outer scope be able to do so.

Section 3.5.2.3 explicitly "bars" inner scopes from completing the type,
but does not "bar" apparently-outer scopes.  Section 3.1.2.1 accomplishes
that (indirectly).

>I admit that there may be some ambiguity here.

It's gone, I think.  I think we don't even need an interpretation ruling.
--
Norman Diamond       diamond at tkov50.enet.dec.com
If this were the company's opinion, I wouldn't be allowed to post it.
Permission is granted to feel this signature, but not to look at it.