Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!umd5!uvaarpa!mcnc!rti!xyzzy!throopw
From: throopw@xyzzy.UUCP (Wayne A. Throop)
Newsgroups: comp.lang.c
Subject: Re: typedef laxity
Message-ID: <759@xyzzy.UUCP>
Date: 7 Apr 88 22:23:29 GMT
References: <1070@maynard.BSW.COM> <757@xyzzy.UUCP>
Organization: Data General, RTP NC.
Lines: 62

> meissner@xyzzy.UUCP (Michael Meissner)
>| campbell@maynard.BSW.COM (Larry Campbell)
>| It seems to me someone should complain about this code:
>| 	typedef int TEMPERATURE;
>| 	typedef int PRESSURE;
>| 	TEMPERATURE tx, ty;
>| 	PRESSURE px, py;
>| 	ty = py;		/* type clash */
> Actually if they complain about it, they are not following either K&R or
> the ANSI draft, which quite clearly says that typedefs do NOT create a new
> type, rather all it does is create a synonym for an existing type.  I've
> heard that the Microsoft 4.00 (and presumably 5.00) C does this with a
> compiler option.  Another way to get the protection is to use C++ and
> declare the types to be a class (instead of a typedef).

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;

Now, reading draft X3J11 on enumerated types from section 3.1.2.5,
compilers or lint have license to complain if p is assigned to t, because
"Each distinct enumeration constitutes a different enumerated type", as
opposed to typedefs which have always been synonyms for the same type.

And, on the other hand, it seems we can be sure that it is legal to
assign anything in the range -40 to 4000 to something of type
temperature_t (at least, if it is correctly cast), and to perform
arithmetic with results in that range, because the enumeration type is
guaranteed in 3.5.2.2 to be "compatible with an integer type".

Other than the obvious glitch (that being that these explicitly-ranged
integral types span at most type (int) because of the restriction that
all enumeration constants are of type (int)), this seems to provide
integer subrange types, at least for type-checking purposes, and on many
compilers, for minimal-sizing purposes.

It is quite possible that I've misinterpreted the standard in either
letter or intent, but it seems clear enough, and should be legal to
assign t anything in the range -40 to 4000, and do arithmetic within
that range, and further, that assignments from any other types ought to
be checked.

(In fact, the letter of the law says that the statement 
        t = low_temperature;
could legitimately raise a complaint, because low_temperature is of type
int, and t is of (distinct, mind you) an enumeration type.  It is not
clear to me whether the "usual arithmetic conversions" would apply... at
first glance, they would not.)

(Comments on this puzzling topic are, of course, welcome.  I'm
particularly interested if anybody thinks this trick is not cosher for
getting distinct integer subrange types.)

--
Of all the gin joints in all the towns in all the world, she walks into mine.
                                        --- Humphrey Bogart in "Casablanca"
-- 
Wayne Throop      <the-known-world>!mcnc!rti!xyzzy!throopw