tenative definition of incomplete type object
Ronald F. Guilmette
"... If a translation unit contains one or more tenative definitions
for an identifier, and the translation unit contains no external
definition for that identifier, then the behavior is exactly as if
the translation unit contains a file scope declaration of that
identifier, with the composite type as of the end of the translation
unit, with an initializer equal to zero."
I would like to know if this rule renders the following complete translation
unit subject to a manditory diagnostic. I'm inclined to question whether
or not it does, based on the above quoted rule (on the one hand) and on the
rule that immediately follows it in the text of the standard (on the other).
struct incomplete;
struct incomplete tenative;
The issue as I see it is that the above quoted rule effectively requires
implementations to pretend to provide an initializer (with value zero) for
an object whose type is incomplete.
Surely, you cannot have an initializer for an incomplete type thing... can
you???
--
-- Ronald F. Guilmette ------------------------------------------------------
------ domain address: r...@netcom.com ---------------------------------------
------ uucp address: ...!uunet!netcom.com!rfg -------------------------------
Norman Diamond
>Section 3.7.2 of the "classic" ANSI C standard says:
> "... If a translation unit contains one or more tenative definitions
> for an identifier, and the translation unit contains no external
> definition for that identifier, then the behavior is exactly as if
> the translation unit contains a file scope declaration of that
> identifier, with the composite type as of the end of the translation
> unit, with an initializer equal to zero."
>I would like to know if this rule renders the following complete translation
>unit subject to a manditory diagnostic.
> struct incomplete;
> struct incomplete tenative;
If the declaration of tenative requires knowledge of the size of tenative,
then the behavior is already undefined. I'd like to see an interpretation
ruling say just when an implementation is allowed to require that the size
of an object be known.
I wonder if undefined behavior can include the omission of subsequent
diagnostics that would otherwise be mandatory :-)
>I'm inclined to question whether
>or not it does, based on the above quoted rule (on the one hand) and on the
>rule that immediately follows it in the text of the standard (on the other).
I think that it does, for the reason that you say. (The Constraint involved
is in section 3.5.7.)
The subsequent text in 3.7.2 says: "If the declaration of an identifier
for an object is a tentative definition and has internal linkage, the
declared type shall not be an incomplete type." This does not contradict
the preceding discussion. This distinguishes the following two examples:
legal:
int tentative[];
int tentative[] = { 3, 4 };
illegal:
static int tentative[];
static int tentative[] = { 3, 4 };
--
<< If this were the company's opinion, I would not be allowed to post it. >>
A program in conformance will not tend to stay in conformance, because even if
it doesn't change, the standard will. Force = program size * destruction.
Every technical corrigendum is met by an equally troublesome new defect report.
Karl Heuer
>The subsequent text in 3.7.2 says: "If the declaration of an identifier
>for an object is a tentative definition and has internal linkage, the
>declared type shall not be an incomplete type." This does not contradict
>the preceding discussion. This distinguishes the following two examples:
>legal:
> int tentative[];
> int tentative[] = { 3, 4 };
>illegal:
> static int tentative[];
> static int tentative[] = { 3, 4 };
Since the latter definition is in fact useful, and doesn't seem to be any
harder to implement than the former, why did the Committee make it illegal?
(If you provide examples, please demonstrate that the presence of the
"static" keyword is critical.)
Karl W. Z. Heuer (ka...@osf.org), The Walking Lint
Michael J. Eager
>Section 3.7.2 of the "classic" ANSI C standard says:
>
> "... If a translation unit contains one or more tenative definitions
> for an identifier, and the translation unit contains no external
> definition for that identifier, then the behavior is exactly as if
> the translation unit contains a file scope declaration of that
> identifier, with the composite type as of the end of the translation
> unit, with an initializer equal to zero."
>
>I would like to know if this rule renders the following complete translation
>unit subject to a manditory diagnostic. I'm inclined to question whether
>or not it does, based on the above quoted rule (on the one hand) and on the
>rule that immediately follows it in the text of the standard (on the other).
>
> struct incomplete;
> struct incomplete tenative;
>
>The issue as I see it is that the above quoted rule effectively requires
>implementations to pretend to provide an initializer (with value zero) for
>an object whose type is incomplete.
>
>Surely, you cannot have an initializer for an incomplete type thing... can
>you???
No. 3.5.7 Initializers, constraints, says "The type of the entity to be initialized
shall be an object type or an array of unknown size".
As I read it, the sentence you quote says that it has the composite
type as of the end of the compilation unit, which in this case is incomplete.
The sentence following the section you quote seems clear: "If the declaration
of an identifier for an object is a tentative definition and has internal linkage,
the declared type shall not be an incomplete type."
---
Michael J. Eager Michae...@eagercon.com
Eager Consulting (415) 325-8077
1960 Park Boulevard, Palo Alto, CA 94306-1141