Re: struct type completion

Lawrence Kirby <lknews@xxxxxxxxxxxxxxx> wrote:
> On Mon, 18 Apr 2005 15:12:46 +0000, S.Tobias wrote:

Thank you very much for answering. However I disagree with you.

> > I'm trying to understand how structure type completion works.
> >
> > # A structure or union type of unknown
> > # content (as described in 6.7.2.3) is an incomplete type. It
> > # is completed, for all declarations of that type, by
> > ^^^
> > # declaring the same structure or union tag with its defining
> > # content later in the same scope.
> > ^^^^^
> > (6.2.5#23)
> >
> > # [#3] All declarations of structure, union, or enumerated
> > ^^^
> > # types that have the same scope and use the same tag declare
> > ^^^^^^^^^^^^
> > # the same type. The type is incomplete100) until the
> > ^^^^^^^^^^^^^^
> > # closing brace of the list defining the content, and complete
> > # thereafter.
> > (6.7.2.3#3)
> > (both excerpts are from n869.txt, but they're the same in the Std)
> >
> > So (eg. in a file scope):
> >
> > /* 1 */ struct mystruct object;
> > /* 2 */ struct mystruct { /*...*/ };
> >
> > line 1 defines `object' (although at this point the body of `struct
> > mystruct' is not yet known(?)); and line 1 does not work without
> > line 2.

> Line 1 is invalid.

I have tried this code with como and gcc, and both exhibit exactly
same behaviour - try it for yourself: compile as is (ok), delete
line 2 (error), insert line "test" after line 1 (error), move it
after line 2 (ok).

>When you define an object the type must be complete at
> the point of definition, it cannot be completed later.

Yes, I think so too.

>Note that you can
> define a pointer to an incomplete type whch is completed later. All
> pointer types are object types, even pointers to incomplete or function
> types.

I'm quite aware of that. You don't even have to complete the type
(unless you dereference the ptr) - the pointer is still valid. But this
is not what I want to talk about, and I really do mean an object where
I put the identifier `object'.

The code is a corner case I wanted to check after reading the above
quotes from the Standard. I think that they say that struct types
can be completed later. Please pay attention to the words I underlined;
I hope you can either agree to my interpretation, or understand
the reason to my misunderstanding and correct me.

Reminder: identifiers have the same scope, when their scopes end
at the same point. Above, the scopes of the declarations are different
(they start at different places), but both declarations have the same
scope (cf. 6.2.1 p. 6 and 7).

> > What I don't understand is, that the excerpts above seem to dictate that
> > line 2 fully defines the type for all instances of `struct mystruct'.
> > The type in line 1 must be a complete type; if it were not, then it
> > would not be the same type as in line 2, which seems to be required by
> > the second quote; and - what's obvious - we could not define `object'
> > (we can't define an object with incomplete type, can we?).

> At the point that line 1 is translated its type is incomplete. For any
> code after line 2 it would appear complete (except of course that it is
> invalid).

I thought so too. But this seems to contradict eg. the second quote
(both in fact): both declarations use the same tag, therefore they
declare the *same* type; a type cannot be both complete and incomplete.

[snipped example for pointers - agree, but a different matter]

I assume the type is complete (first quote), that is, both declarations
declare complete type (whatever incredible that sounds). However
the last sentence of the second quote seems to contradict it:

> > But then further description seems to contradict this: "... incomplete
> > until the closing brace ...". If the type in line 1 is complete, then
> > it needn't be completed, and can't of course be incomplete at the same
> > time.

(As I read it now, I think it may be understood that closing brace
completes the type, even for earlier declarations; hence there would
be no disagreement. But still, the wording is very contrived -
it would be simpler to say the definition of the (complete) struct
type may be found later in the translation unit.)

> A type can be incomplete at one point in the source file and then complete
> later on.

Hmmm.... I don't have an answer to that, but I strongly disagree.
If one is incomplete, the other complete, then they're different types,
I thought that was pretty logical. Could you give some example, or
a reference (c&v), please?

--
Stan Tobias
mailx `echo siXtY@xxxxxxxxxxxxxxxxxxxxxxxxxx | sed s/[[:upper:]]//g`
.

Relevant Pages

  • Re: struct type completion
    ... > # is completed, for all declarations of that type, by ... > # declaring the same structure or union tag with its defining ... define a pointer to an incomplete type whch is completed later. ...
    (comp.lang.c)
  • Re: struct type completion
    ... >>> # content later in the same scope. ... >> define a pointer to an incomplete type whch is completed later. ... the scopes of the declarations are different ... Maybe you could consider that completing the type ...
    (comp.lang.c)
  • Re: c99/c++ localised variable definition
    ... When variables are used only in a limited scope I find it better to ... Forcing variable declarations to the top of the function means extra ... > reason why things like ancillary counter variables seem reasonable, ... you can combine the decl and the initialization. ...
    (freebsd-arch)
  • Re: Making C better (by borrowing from C++)
    ... there's no way to be certain unless declarations are restricted not ... merely to the top of the scope, but to the top of the function. ... line by line for the matching declaration; the context switch between ... the two search modes costs at least as much as the nominally more ...
    (comp.lang.c)
  • Re: Identify new pairs in an array
    ... Leaving us to figure it out for ourselves from the code? ... [declarations below rearranged into groups I can comment on] ... One-character variable names suck even more when they ... You should limit the scope of variables to the smallest possible scope. ...
    (comp.lang.perl.misc)