Path: utzoo!mnetor!uunet!husc6!think!ames!umd5!uvaarpa!mcnc!rti!xyzzy!throopw
From: throopw@xyzzy.UUCP (Wayne A. Throop)
Newsgroups: comp.lang.c
Subject: Re: typedef laxity
Message-ID: <796@xyzzy.UUCP>
Date: 18 Apr 88 16:14:43 GMT
References: <1070@maynard.BSW.COM> <757@xyzzy.UUCP> <759@xyzzy.UUCP> <2489@ihuxy.ATT.COM>
Organization: Data General, RTP NC.
Lines: 56

> lied@ihuxy.ATT.COM (Bob Lied)
>> throopw@xyzzy.UUCP (Wayne A. Throop)
>>It occurs to me that there is another way to do this, and a form of
>>integer subranges to boot, all within draft X3J11 C.  Consider:
>>  typedef enum {low_temperature=(-40), high_temperature=4000} temperature_t;
>>  typedef enum {low_pressure=0, high_pressure=500} pressure_t;
>>  temperature_t t;
>>  pressure_t p;
> You are trying to eat your cake and have it, too.

Correct.  I was asking if I could get away with it under the rules of
draft X3J11 C.  I am somewhat dissappointed that nobody addressed the
three main questions in any thorough way (though, of course Bob's
welcome comment comes closest).

> If temperature_t and pressure_t are distinct types, then
> they are also distinct from int.  Therefore,
> 	t = 32;
> should also give a type mis-match warning.

This is what I think may not be true.  Or rather, they may not be
"distinct" (in the sense of requiring a warning) from the integer type
they are guaranteed to be "compatible" with under the rules for
enumerations.  Note that this would account for the distinctness of
enumerated types, while still making sense of the fact that one can
assign an enumeration member name (presumably) without warning, despite
the "type clash" built into the X3J11 model.

The points I was asking about:

     1. should (t=32) get a diagnostic message?  If so, it seems
        necessary that (t=low_temperature) also get a diagnostic message.
        Whatever the answer, how is this answer reconciled with the fact
        that enumerated types are "distinct" according to draft X3J11?
     2. What about variables of the compatible type?  IE, is (t=i)
        grounds for a diagnostic?
     3. Is the behavior of values in "gaps" of the enumeration
        intended to be guaranteed to be the same as the behavior of such
        values for the compatible arithmetic type?  If so, then whatever
        the state of "distinctness" from other types, enumerations can
        be used to better document integer subrange usage.  (This third
        question is my primary interest... If it were guaranteed to
        work, I'd like to start using enums this way (among others).)

In any event, a current typechecking tool complains if anything is
assigned to an enumeration type except one of its member names or
another enumeration-valued expression (note that the former is not one
of the latter...).  This means that to get it to shut up about integer
assignments, one has to do (t=(temperature_t)32).  Which might
be a good idea anyway, if (p=32) would not warn and
(p=(temperature_t)32) would.

--
"I'm so *conFUSED*."
        --- "Vinnie", from "Welcome Back Kotter"
-- 
Wayne Throop      <the-known-world>!mcnc!rti!xyzzy!throopw