clive@sco.com (Clive D.W. Feather) writes:

>maxtal@physics.su.OZ.AU (John Max Skaller) writes:
>> Right. Its been proposed, incomplete enum type will
>>probably be added to the language next week.
>
>What *are* you talking about ?

Please note the cross-posting!

John Max Skaller was no doubt talking about C++.

--
Fergus Henderson - fjh@munta.cs.mu.oz.au

In article <CLq4x7.MoE@ucc.su.OZ.AU> maxtal@physics.su.OZ.AU (John Max Skaller) writes:
> Right. Its been proposed, incomplete enum type will
>probably be added to the language next week.

What *are* you talking about ?

This discussion has pointed out some minor defects with the Standard
which will be addressed. I am currently of the view that no constraint
is violated, even if I am not entirely sure what is the exact definition
of the problem.

--
Clive D.W. Feather     | Santa Cruz Operation    | If you lie to the compiler,
clive@sco.com          | Croxley Centre          | it will get its revenge.
Phone: +44 923 816 344 | Hatters Lane, Watford   |   - Henry Spencer
Fax:   +44 923 210 352 | WD1 8YN, United Kingdom |

In article <CLKyHH.9Ln@x.co.uk> clive@sco.com (Clive D.W. Feather) writes:
>In article <2k9qko$i35@usenet.pa.dec.com> diamond@tkt.dec.com (Norman Diamond) writes:
>>In article <CKp643.L8z@x.co.uk> clive@sco.com (Clive D.W. Feather) writes:
>>>     enum foo { bar = sizeof (enum foo) };

>>[...] And if not, then the response to DR13Q5 has no leg to stand on.

>The current response is that, in the enum declaration, the size of enum
>foo is not known at the time that bar is declared, and so the value of
>the sizeof is undefined, and so the declaration is undefined.

The committee still has no leg to stand on.  To make the size of enum foo
unknown, the committee would have to add incomplete enum types.  If these
are not added to the standard, then sizeof has to come up with an answer,
because the example obeys all of the "shall not" and (vacuously) "shall"
clauses in the definition of sizeof.
--
 <<  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.

In article <2kbljh$t1f@usenet.pa.dec.com> diamond@tkt.dec.com (Norman Diamond ) writes:
>In article <CLKyHH.9Ln@x.co.uk> clive@sco.com (Clive D.W. Feather) writes:
>>>>     enum foo { bar = sizeof (enum foo) };
>> The current response is that, in the enum declaration, the size of enum
>> foo is not known at the time that bar is declared, and so the value of
>> the sizeof is undefined, and so the declaration is undefined.
> The committee still has no leg to stand on.  To make the size of enum foo
> unknown, the committee would have to add incomplete enum types.

No. The size of most types is implementation-defined. However, an
enumerated type is compatible with some implementation-defined integral
type. The implementation need not decide *which* integral type until the
end of the type specification, which is the closing brace. Until that
point, the size is not known, and sizeof(enum foo) does not have a
defined value.

--
Clive D.W. Feather     | Santa Cruz Operation    | If you lie to the compiler,
clive@sco.com          | Croxley Centre          | it will get its revenge.
Phone: +44 923 816 344 | Hatters Lane, Watford   |   - Henry Spencer
Fax:   +44 923 817 688 | WD1 8YN, United Kingdom |

In article <CLM8oC.FGG@x.co.uk> clive@sco.com (Clive D.W. Feather) writes:
>In article <2kbljh$t1f@usenet.pa.dec.com> diamond@tkt.dec.com (Norman Diamond ) writes:
>>In article <CLKyHH.9Ln@x.co.uk> clive@sco.com (Clive D.W. Feather) writes:
>>>>>     enum foo { bar = sizeof (enum foo) };
>>> The current response is that, in the enum declaration, the size of enum
>>> foo is not known at the time that bar is declared, and so the value of
>>> the sizeof is undefined, and so the declaration is undefined.

>> The committee still has no leg to stand on.  To make the size of enum foo
>> unknown, the committee would have to add incomplete enum types.

>No.

The alternative (which you deleted) is to define a result for the sizeof
operator, meeting the standard's written rules.

>The size of most types is implementation-defined. However, an
>enumerated type is compatible with some implementation-defined integral
>type. The implementation need not decide *which* integral type until the
>end of the type specification, which is the closing brace.

All true (or all can be true, depending on a correct interpretation or
technical correction) but all irrelevant.  The standard guarantees that
sizeof will produce a result for a program that obeys the "shall" and
"shall not" clauses.

>Until that point, the size is not known, and sizeof(enum foo) does not have a
>defined value.

Now the pendulum swings back.  This effect requires incomplete enum types.
--
 <<  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.

In article <2kcg16$oah@usenet.pa.dec.com> diamond@tkt.dec.com (Norman Diamond ) writes:
>In article <CLM8oC.FGG@x.co.uk> clive@sco.com (Clive D.W. Feather) writes:
>>>>>>     enum foo { bar = sizeof (enum foo) };
>> The size of most types is implementation-defined. However, an
>> enumerated type is compatible with some implementation-defined integral
>> type. The implementation need not decide *which* integral type until the
>> end of the type specification, which is the closing brace.
>> Until that point, the size is not known, and sizeof(enum foo) does not have a
>> defined value.
> The standard guarantees that sizeof will produce a result for a program
> that obeys the "shall" and "shall not" clauses.
> Now the pendulum swings back.  This effect requires incomplete enum types.

Okay, now I see what you're getting at. Hmm.

ISO 6.1.2.5: "... *incomplete types* (types that describe objects but
lack information needed to determine their sizes)". So the type is
incomplete until the closing brace, and a diagnostic is required. The
response to the Defect Report is wrong.

I don't see anywhere in the Standard that claims to be a complete list
of incomplete types, so can you see any problem with that interpretation ?

--
Clive D.W. Feather     | Santa Cruz Operation    | If you lie to the compiler,
clive@sco.com          | Croxley Centre          | it will get its revenge.
Phone: +44 923 816 344 | Hatters Lane, Watford   |   - Henry Spencer
Fax:   +44 923 817 688 | WD1 8YN, United Kingdom |

In article <CLKyHH.9Ln@x.co.uk>, clive@sco.com (Clive D.W. Feather) writes:
>In article <2k9qko$i35@usenet.pa.dec.com> diamond@tkt.dec.com (Norman Diamond) writes:
>> Sorry about this late response to Mr. Feather's posting of 4 Feb. 1994.
>> I have finally figured out what bothers me about this ruling.
>> In article <CKp643.L8z@x.co.uk> clive@sco.com (Clive D.W. Feather) writes:
>>> There is no such thing as an incomplete enumerated type. This leads to
>>> the question of the following code:
>>>     enum foo { bar = sizeof (enum foo) };
>>> This was addressed in DR13Q5, which states (roughly) that the words
>>> "subsequent declaration that uses the tag" in ISO 6.5.2.3 apply after
>>> the closing brace (i.e. "subsequent" to the whole declaration, which
>>> ends at the closing brace). So the second enum foo has no referent, and
>>> so the behaviour is undefined. (It cannot refer to another enum foo in an
>>> outer scope because the new "foo" tag *is* in scope.)
>[...]
>> And if not, then the response to DR13Q5 has no leg to stand on.
>
>You weren't the only one it bothered. A later draft of RR1 arrived here
>today, and I now remember that we changed this because of such questions.
>
>The current response is that, in the enum declaration, the size of enum
>foo is not known at the time that bar is declared, and so the value of
>the sizeof is undefined, and so the declaration is undefined.

So we now have a new kind of incomplete type? Will this be added to the
list of possible incomplete types?

>
>--
>Clive D.W. Feather     | Santa Cruz Operation    | If you lie to the compiler,
>clive@sco.com          | Croxley Centre          | it will get its revenge.
>Phone: +44 923 816 344 | Hatters Lane, Watford   |   - Henry Spencer
>Fax:   +44 923 817 688 | WD1 8YN, United Kingdom |

--

Chris Volpe    Phone: (518) 387-7766 (Dial Comm 8*833
GE Corporate R&D   Fax:   (518) 387-6560
PO Box 8, Schenectady, NY 12301  Email: volpecr@crd.ge.com

In article <CLMEMs.GBs@x.co.uk> clive@sco.com (Clive D.W. Feather) writes:
>I don't see anywhere in the Standard that claims to be a complete list
>of incomplete types, so can you see any problem with that interpretation ?

Hmm, I guess it's mostly part of the folklore.  ANSI Classic section 3.5.2.3
doesn't exactly prohibit the possibility of incomplete enum types, though I
thought it did.  ANSI Classic section 3.1.2.5, page 25 lines 7 to 11, might
be more problematic, because it defines incomplete array types and incomplete
structure or union types.  Since the committee has decided that (the ISO
equivalent of) this section has defined *all* of the integral types, it is
reasonable to infer that it also defines *all* of the incomplete types.
Perhaps a line should be added to this paragraph, saying that an enum type
is incomplete until the closing brace is reached.
--
 <<  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.

In article <2kecr2$73e@usenet.pa.dec.com> diamond@tkt.dec.com (Norman Diamond ) writes:
[in respect of whether incomplete enums exist]
> ANSI Classic section 3.1.2.5, page 25 lines 7 to 11, might
> be more problematic, because it defines incomplete array types and incomplete
> structure or union types.  Since the committee has decided that (the ISO
> equivalent of) this section has defined *all* of the integral types, it is
> reasonable to infer that it also defines *all* of the incomplete types.

There's a difference: 6.1.2.5 defines *all* of the integral types,
because it has the defining instance of the term: the one in italics.
The defining instance of "incomplete type" is in the first paragraph,
and any other instances of the term are examples or clarifications thereof.

--
Clive D.W. Feather     | Santa Cruz Operation    | If you lie to the compiler,
clive@sco.com          | Croxley Centre          | it will get its revenge.
Phone: +44 923 816 344 | Hatters Lane, Watford   |   - Henry Spencer
Fax:   +44 923 817 688 | WD1 8YN, United Kingdom |

Sorry about this late response to Mr. Feather's posting of 4 Feb. 1994.
I have finally figured out what bothers me about this ruling.

In article <CKp643.L8z@x.co.uk> clive@sco.com (Clive D.W. Feather) writes:
>There is no such thing as an incomplete enumerated type. This leads to
>the question of the following code:
>    enum foo { bar = sizeof (enum foo) };
>This was addressed in DR13Q5, which states (roughly) that the words
>"subsequent declaration that uses the tag" in ISO 6.5.2.3 apply after
>the closing brace (i.e. "subsequent" to the whole declaration, which
>ends at the closing brace). So the second enum foo has no referent, and
>so the behaviour is undefined. (It cannot refer to another enum foo in an
>outer scope because the new "foo" tag *is* in scope.)

If parse trees play any role in the definition of the C language, then the
operand of the sizeof operator is not a declaration.  It is a type-name.
ANSI Classic section 3.5.5 (page 70 lines 23 to 25) says that a type-name
is syntaxctiallcy a declaration that omits the identifier.  But is that
really a declaration?  If so, then every sizeof(type-name) expression runs
afoul of the now-famous Constraint in ANSI Classic section 3.5 (page 58
line 16) that a declaration shall declare something.  And if not, then the
response to DR13Q5 has no leg to stand on.

Incidentally, cast operators suffer the same problem.
--
 <<  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.

In article <2k9qko$i35@usenet.pa.dec.com> diamond@tkt.dec.com (Norman Diamond) writes:
> Sorry about this late response to Mr. Feather's posting of 4 Feb. 1994.
> I have finally figured out what bothers me about this ruling.
> In article <CKp643.L8z@x.co.uk> clive@sco.com (Clive D.W. Feather) writes:
>> There is no such thing as an incomplete enumerated type. This leads to
>> the question of the following code:
>>     enum foo { bar = sizeof (enum foo) };
>> This was addressed in DR13Q5, which states (roughly) that the words
>> "subsequent declaration that uses the tag" in ISO 6.5.2.3 apply after
>> the closing brace (i.e. "subsequent" to the whole declaration, which
>> ends at the closing brace). So the second enum foo has no referent, and
>> so the behaviour is undefined. (It cannot refer to another enum foo in an
>> outer scope because the new "foo" tag *is* in scope.)
[...]
> And if not, then the response to DR13Q5 has no leg to stand on.

You weren't the only one it bothered. A later draft of RR1 arrived here
today, and I now remember that we changed this because of such questions.

The current response is that, in the enum declaration, the size of enum
foo is not known at the time that bar is declared, and so the value of
the sizeof is undefined, and so the declaration is undefined.

--
Clive D.W. Feather     | Santa Cruz Operation    | If you lie to the compiler,
clive@sco.com          | Croxley Centre          | it will get its revenge.
Phone: +44 923 816 344 | Hatters Lane, Watford   |   - Henry Spencer
Fax:   +44 923 817 688 | WD1 8YN, United Kingdom |

In article <1994Feb4.180622.14073@cdf.toronto.edu> g2devi@cdf.toronto.edu (Robert N. Deviasse) writes:
>In article <CKp643.L8z@x.co.uk> clive@sco.com (Clive D.W. Feather) writes:
>>In article <rfgCKoJw5.2vq@netcom.com> rfg@netcom.com (Ronald F. Guilmette) writes:
>>> Here's the code.  It ain't complicated.
>>> enum { foo, bar = sizeof (foo) };
>>
>>What's wrong with that ? The scope of "foo" starts at the comma (ISO 6.1.2.1)
>>and its type is "int" (ISO 6.5.2.2). So the argument of the sizeof
>>operator has known type.

Yes.  Quite so.  The first line of the ``Semantics'' part of the (classic)
ANSI C standard explicitly says that enumerators have type `int' (in C
anyway).  I hadn't noticed that before.

Thank you again Norman.  Thank you again Clive.

>I believe what Ronald was refering to was that "enum" now (unless I've
>misinterpreted) refers to a subrange, and so
>     enum Small { first_Small=0,last_Small=127 };
>could be implemented as a character. Clearly, if this is so then the size of
>Small can't be known until it's definition is complete.

Yes.  This was exactly the line of thinking that made me raise the question.
But I see now that (in C at least) all enumerators have type `int', even
if an object having the (containing) enumeration type itself has a
(non-int) type... and perhaps also a size different from that of int.

I guess this is somewhat analogous to the situation regarding character
literals.  The type of a literal like 'x' is int, but you can still store
that whole value (without loss of precision) into a type `char' variable.
So might it be also for ``enumeration literals''.

So in C (at least) the code `enum { foo, bar = sizeof (foo) };' is per-
fectly valid.

In C++ of course, the situation is entirely different, because in C++,
enumerators actually have a type which is (distinctly) the type of
the containing enumeration type.  Thus, I would guess that the code
`enum { foo, bar = sizeof (foo) };' must get a required diagnostic in
C++.  (I sure hope so anyway.)

(It appears that some respondents failed to note that I had posted this
question to *both* the comp.std.c and comp.std.c++ newsgroups, and there
answers assumed that I was asking just about C++.)

>Personally, I don't see why Ron is complaining. The standard is evolving and
>so it's hard for compiler writers to keep up with it.

As I say, the question was about *both* C and C++.  The C++ standard is
still evloving, but the C standard was cast in concrete quite some time
ago.

--

-- Ron Guilmette, Sunnyvale, CA ---------- RG Consulting -------------------
---- domain addr: rfg@netcom.com ----------- Purveyors of Compiler Test ----
---- uucp addr: ...!uunet!netcom!rfg ------- Suites and Bullet-Proof Shoes -

In article <CKp643.L8z@x.co.uk> clive@sco.com (Clive D.W. Feather) writes:
>In article <rfgCKoJw5.2vq@netcom.com> rfg@netcom.com (Ronald F. Guilmette) writes:
>> As far as I can tell however, this code violates a constraint of the ANSI C
>> standard in that the ``sizeof'' operator is being applied to an expression
>> having an incomplete type.
>
>> Here's the code.  It ain't complicated.
>> enum { foo, bar = sizeof (foo) };
>
>What's wrong with that ? The scope of "foo" starts at the comma (ISO 6.1.2.1)
>and its type is "int" (ISO 6.5.2.2). So the argument of the sizeof
>operator has known type.
>
>There is no such thing as an incomplete enumerated type. This leads to
>the question of the following code:
>
>    enum foo { bar = sizeof (enum foo) };
>
>This was addressed in DR13Q5, which states (roughly) that the words
>"subsequent declaration that uses the tag" in ISO 6.5.2.3 apply after
>the closing brace (i.e. "subsequent" to the whole declaration, which
>ends at the closing brace). So the second enum foo has no referent, and
>so the behaviour is undefined. (It cannot refer to another enum foo in an
>outer scope because the new "foo" tag *is* in scope.)
>

I believe what Ronald was refering to was that "enum" now (unless I've
misinterpreted) refers to a subrange, and so
     enum Small { first_Small=0,last_Small=127 };
could be implemented as a character. Clearly, if this is so then the size of
Small can't be known until it's definition is complete.

Personally, I don't see why Ron is complaining. The standard is evolving and
so it's hard for compiler writers to keep up with it. If they stay too
bleeding edge, they'll get burned if/when the standard adjusts or ammends
any mistakes it's made.

>--
>Clive D.W. Feather     | And I am right, I'm sure you'll say,
>clive@sco.com          | To argue in this kind of way.
>Phone: +44 923 816 344 | - W.S.Gilbert
>Fax:   +44 923 817 688 |   (The Mikado)

Take care
    Robert

--
/----------------------------------+------------------------------------------\
| Robert N. Deviasse               |"If we have to re-invent the wheel,       |
| EMAIL: g2devi@cdf.utoronto.ca    |  can we at least make it round this time"|
+----------------------------------+------------------------------------------/