NetNews Usenet Archive 1992 #31/NN_1992_31.iso/spool/comp/std/c/3267

Text File | 1992-12-24 | 5.0 KB | 111 lines

Newsgroups: comp.std.c
Path: sparky!uunet!haven.umd.edu!decuac!pa.dec.com!e2big.mko.dec.com!jrdzzz.jrd.dec.com!jit533.jit.dec.com!diamond
From: [e-mail] (Norman Diamond)
Subject: Re: Compatability of enum types and integer types
Message-ID: <[e-mail]>
Sender: [e-mail] (USENET News System)
Nntp-Posting-Host: jit533.jit.dec.com
Reply-To: [e-mail] (Norman Diamond)
Organization: Digital Equipment Corporation Japan , Tokyo
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Thu, 24 Dec 1992 08:58:25 GMT
Lines: 97

In article <[e-mail]> [e-mail] (Jerry Schwarz) writes:
>In article <[e-mail]>, [e-mail] (Ronald F. Guilmette) writes:
>>The ANSI C standard says (in 3.5.2.2):
>>    "Each enumerated type shall be compatible with an integer type;
>>    the choice of type is implementation-defined."

>It requires more for
>    enum E object ;
>    int object ;
>to be legal than that E and int be compatible.

>3.1.2.6 says that the "type of the identifier becomes the composite type".

Yes.

>It also gives the rules for determining a composite type and says nothing
>about combining enums and integer types.  Granted, this isn't a constraint
>section, but if there isn't a composite type then I think the compiler is
>justified in treating the above as an error.

It says about ALL potential combinations, "it is a type that is compatible
with both of the two types", and adds for some particular types, "and
satisfies the following conditions".  (Page 26 lines 11 to 12.)

The same reasoning allows the following two declarations at file scope:
    int object;
    int object;
and the following more obviously useful:
    int object;
    int object = 3;
(and also versions with internal linkage).

In article <[e-mail]> [e-mail] (John F. Woods) writes:
>[e-mail] (Norman Diamond) writes:
>>Being implementation-defined means that it must be documented.  Regarding
>>some other implementation-defined matters (e.g. which of two possible results
>>is obtained from the % operator) most of the regulars in this newsgroup seem
>>to feel that the implementation must define a result that is identical over
>>all usages.  This kind of opinion suggests that the documentation must tell
>>you which type you can use for `T'.
>>My opinion is that the documentation can tell you that the implementation
>>plays dirty pool.  However, I seem to be a minority of 1.

>I think you're a minority of two.  I can't see any way for a program to make
>use of this in a way that exposes the type yet is guaranteed.

Well, the undetermined matter is just how thoroughly the type is exposed.
Thank you for the support though!

>I think one can argue that
>    enum thing { small, big=INT_MAX };
>is required to be compatible with a type no shorter than int,

How do you argue this?  I cannot find any support for it in the standard.

>I think a [hypothetical implementation's] definition of
>    Enumeration types are compatible with "int", unless an object in a
>    translation unit is declared as an enumeration type and as an "int"
>    in the same translation unit or a different translation unit at link
>    link time, in which case enumeration types are compatible with "long".
>meets all the requirements present in the standard.

I agree.  But by analogy again, I thought a hyp. imp.'s definition of
    The result of % with one or two negative operands in the expression
    (a/b)*b + a%b is appropriate so that the expression will equal a,
    but in any other expression will alternate between permissible choices.
also meets all the requirements present in the standard, but no one agreed.

>I think it's pretty clear that the type compatibility of enumerations need
>*not* be identical over all usages:

Yup, page 62 line 39.

>It might be argued, however, that since the Standard could merely have said
>that enumerations are integral types, but are not *compatible* with any
>integral types, that there is an implicit requirement that one be able to
>take advantage of that type compatibility.

ANSI Classic 3.1.2.5, page 25 lines 1 to 2, includes enumerated types in the
category of integral types.

>I think the compatibility requirement only buys one the ability to pass
>enumerations to functions expecting integral types with some hope of
>portability (though I suspect that if enumerations can be unsigned types,
>it opens an even larger can of worms).

In order to pass enumerations to functions, you'd better make sure that the
same enumeration type is declared for the receiving function.  (My wording
is lazy; see ANSI Classic 3.1.2.6, page 26 lines 2 to 8, for exact wording.)
Of course, if you want to write implementation-dependent code for an
implementation that defines things nicely enough for you, you can do that.

I think enum types can be unsigned.  The can of worms is unchanged in size :-)
--
Norman Diamond       [e-mail]
If this were the company's opinion, I wouldn't be allowed to post it.
"It's been a lovely recession."