[comp.lang.c] typedef laxity

campbell@maynard.BSW.COM (Larry Campbell) (04/06/88)

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 */

But none of the compilers I've tested (pcc, VAX-11 C, Wang VS C, Turbo C)
complain about it, and, even worse, _lint_ doesn't complain!

Does anyone know of a lint or compiler that will complain about it?
Does anyone disagree that lint's silence in this case is a bug?
(Especially since lint does complain about mixing enum types...)
-- 
Larry Campbell                                The Boston Software Works, Inc.
Internet: campbell@maynard.bsw.com          120 Fulton Street, Boston MA 02109
uucp: {husc6,mirror,think}!maynard!campbell         +1 617 367 6846

gwyn@brl-smoke.ARPA (Doug Gwyn ) (04/06/88)

In article <1070@maynard.BSW.COM> campbell@maynard.BSW.COM (Larry Campbell) writes:
>It seems to me someone should complain about this code:

Ok, if it makes you happy I'll complain about it.

>Does anyone know of a lint or compiler that will complain about it?

No, you appear to have a misperception regarding typedef.  It does not
introduce a new type, but rather just a synonym for an existing type.
This is intentional, sorry.

nevin1@ihlpf.ATT.COM (00704a-Liber) (04/07/88)

In article <1070@maynard.BSW.COM> campbell@maynard.BSW.COM (Larry Campbell) writes:
>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 */
>
>But none of the compilers I've tested (pcc, VAX-11 C, Wang VS C, Turbo C)
>complain about it, and, even worse, _lint_ doesn't complain!

Someone IS complaining about this code:  you!  Remember, this is C, not
Pascal :-)!  This is perfectly legitimate C code, since:

"typedef does not introduce brand new types, only synonyms for types which
could be specified in another way."  (K&R 1, C Reference Manual, section
8.8.  Almost the same wording appears in section 3.5.6 of dpANS).

Since this is perfectly legal, I don't want my compiler to complain about
it.

>Does anyone know of a lint or compiler that will complain about it?
>Does anyone disagree that lint's silence in this case is a bug?
>(Especially since lint does complain about mixing enum types...)

I'm not sure how you could mix enum types within C's scoping rules, so this
should always be flagged as an *error* (correct me via email if I'm wrong
about this, though).

Now, if you want lint to issue a warning about mixing typedefs, it's fine
by me (since I don't use them very often).  But please make sure that a
flag to lint is provided to turn these warnings off.
-- 
 _ __			NEVIN J. LIBER	..!ihnp4!ihlpf!nevin1	(312) 510-6194
' )  )				"The secret compartment of my ring I fill
 /  / _ , __o  ____		 with an Underdog super-energy pill."
/  (_</_\/ <__/ / <_	These are solely MY opinions, not AT&T's, blah blah blah

meissner@xyzzy.UUCP (Michael Meissner) (04/08/88)

In article <1070@maynard.BSW.COM> campbell@maynard.BSW.COM (Larry Campbell) writes:
| 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 */
| 
| But none of the compilers I've tested (pcc, VAX-11 C, Wang VS C, Turbo C)
| complain about it, and, even worse, _lint_ doesn't complain!
| 
| Does anyone know of a lint or compiler that will complain about it?
| Does anyone disagree that lint's silence in this case is a bug?
| (Especially since lint does complain about mixing enum types...)

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).
-- 
Michael Meissner, Data General.		Uucp: ...!mcnc!rti!xyzzy!meissner
					Arpa/Csnet:  meissner@dg-rtp.DG.COM

davidsen@steinmetz.ge.com (William E. Davidsen Jr) (04/08/88)

In article <1070@maynard.BSW.COM> campbell@maynard.BSW.COM (Larry Campbell) writes:
| 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 */

  The Xenix compiler will complain if you set the warning level higher
than the default. I ran your code with -W3 and got a "strong type
mismatch." I also use the -Zg option to produce my function prototypes
for a "proto.h" file. Output follows (I *like* compilers which can give
you a listing!).



                                                                       PAGE   1
                                                                       04-07-88
                                                                       12:48:07

  Line#  Source Line                   Xenix 8086/80286 C Compiler Release 2.00

      1  typedef int TEMP;
      2  typedef int PRES;
      3  
      4  TEMP tx, ty;
      5  PRES px, py;
      6  
      7  main() {
      8    ty = py;
***** x.c(8) : warning 50: strong type mis-match
      9    px = py;
     10    ty = (TEMP)py;
     11  }
***** x.c(11) : warning 35: no return value



Global Symbols

Name                            Type             Size    Class    Offset

main. . . . . . . . . . . . . . near function     ***    global     0000
px. . . . . . . . . . . . . . . int                 2    common      ***
py. . . . . . . . . . . . . . . int                 2    common      ***
tx. . . . . . . . . . . . . . . int                 2    common      ***
ty. . . . . . . . . . . . . . . int                 2    common      ***

Code size = 0023 (35)
Data size = 0000 (0)
Bss size  = 0000 (0)

No errors detected

-- 
	bill davidsen		(wedu@ge-crd.arpa)
  {uunet | philabs | seismo}!steinmetz!crdos1!davidsen
"Stupidity, like virtue, is its own reward" -me

throopw@xyzzy.UUCP (Wayne A. Throop) (04/08/88)

> 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

gp@picuxa.UUCP (Greg Pasquariello X1190) (04/08/88)

In article <1070@maynard.BSW.COM> campbell@maynard.BSW.COM (Larry Campbell) writes:
>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 */
>
>But none of the compilers I've tested (pcc, VAX-11 C, Wang VS C, Turbo C)
>complain about it, and, even worse, _lint_ doesn't complain!


The compiler does not complain about this, because it is not really a type
clash.  Typedef simply creates synonyms for a type.  The compiler treats both
"new types" the same as int.

>Larry Campbell                                The Boston Software Works, Inc.

Greg Pasquariello
ihnp4!picuxa!gp
                                                                      
                                                               
                                                            
                                                                
                                                
                                                     
                                  

campbell@maynard.BSW.COM (Larry Campbell) (04/12/88)

In article <542@picuxa.UUCP> gp@picuxa.UUCP (Greg Pasquariello X1190) writes:
<>In article <1070@maynard.BSW.COM> campbell@maynard.BSW.COM (Larry Campbell) writes:
<>>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 */
<>>
<>>But none of the compilers I've tested (pcc, VAX-11 C, Wang VS C, Turbo C)
<>>complain about it, and, even worse, _lint_ doesn't complain!
<>
<>
<>The compiler does not complain about this, because it is not really a type
<>clash.  Typedef simply creates synonyms for a type.  The compiler treats both
<>"new types" the same as int.
<>
<>Greg Pasquariello
<>ihnp4!picuxa!gp

Well, I have gotten several mail messages and seen several followups all
saying the same thing:  "That's just the way it works."  As opposed to
saying "It works this way because of <insert good idea>".  I still haven't
heard anyone argue that mixing types (all right, mixing type NAMES) like this
is a good programming practice, and haven't heard any arguments as to why
it's a _good thing_ that lint doesn't complain.

I _know_ how it works.  I am arguing that how it works is a _bad thing_.
I would like lint, at least, to complain.  Can anyone convince me that
it shouldn't?  (For example, show me a code fragment where it is both
reasonable and readable to mix type names as in the above example.)
-- 
Larry Campbell                                The Boston Software Works, Inc.
Internet: campbell@maynard.bsw.com          120 Fulton Street, Boston MA 02109
uucp: {husc6,mirror,think}!maynard!campbell         +1 617 367 6846

karl@haddock.ISC.COM (Karl Heuer) (04/12/88)

In article <1071@maynard.BSW.COM> campbell@maynard.UUCP (Larry Campbell) writes:
>>Typedef simply creates synonyms for a type.
>
>[I know, but] I am arguing that how it works is a _bad thing_.  I would like
>lint, at least, to complain.  Can anyone convince me that it shouldn't?

Okay, let's pretend we have such strictness.
  typedef int foo_t;
  typedef int bar_t;
  foo_t f1, f2;
  bar_t b1;
  int   i;

Now, which of the following expressions should be legal, and what should be
their types?
  -f1         f1 + 1      f1 - f2     f1 * 5      f1 / f2
  f1 + b1     f1 * b1     f1 = i      i = f1      f1 = b1

I'm not saying that dimensional analysis shouldn't be done, just that it's not
trivial to define the rules.  In fact I have a partially-written essay on
this, which I might post someday...

Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint

msb@sq.uucp (Mark Brader) (04/12/88)

> 	typedef int TEMPERATURE;
> 	typedef int PRESSURE;
> 	TEMPERATURE tx, ty;
> 	PRESSURE px, py;
> 	ty = py;		/* type clash */
> I _know_ how it works.  I am arguing that how it works is a _bad thing_.

People making complaints like this should always include a sentence
like the last one in their *original* posting; it saves on followups.

One advantage of the way it actually works is that you can continue to
use library functions conveniently.  For instance, abs() takes an int
argument and returns an int result.  So you can say:

	py = abs(px); /* never mind the direction, how hard it is pressing? */

Relatively recently, C has acquired the notion that certain conversions
(involving pointer types) can be done only by an explicit cast operator
and not by direct assignment.  Using this concept, the language could
similarly be changed to require that the above be written

	py = (PRESSURE) abs ((int) px);

to allow calling of library functions while also having the stricter typing
that the original poster is calling for.  However, I argue that this would
be a "bad thing", because it is no longer clear in the above form that both
casts shown are guaranteed to give exact conversions.

Of course, once the language allows you to mix PRESSURE and int in this way,
there's not much reason not to allow mixing PRESSURE and TEMPERATURE.  And
while it may seem silly with pressures and temperatures, the use of different
typedefs doesn't necessarily imply that the quantities are incommensurable.
How about
	typedef long CITY_POP, STATE_POP;
?

Finally, if you really want strict checking, you can get it by:

	typedef struct pressure {int value;} PRESSURE;
	typedef struct temperature {int value;} TEMPERATURE;

Then if you want to use them as integers, you have to say

	py.value = abs (px.value);

which is no worse than the cast version; but the direct assignment

	py = ty;

is illegal.  However, I'm certainly not advocating this method!

Mark Brader				"C takes the point of view
SoftQuad Inc., Toronto			 that the programmer is always right"
utzoo!sq!msb, msb@sq.com				-- Michael DeCorte

nevin1@ihlpf.ATT.COM (00704a-Liber) (04/13/88)

In article <1071@maynard.BSW.COM> campbell@maynard.UUCP (Larry Campbell) writes:

>Can anyone convince me that
>it shouldn't?  (For example, show me a code fragment where it is both
>reasonable and readable to mix type names as in the above example.)

Here is one that I see a lot among beginning C programmers:

	typedef	char *	string;

If I have the following declaration:

	string	foo;

I really don't want

	foo = "bar";

to be an error or even a warning from lint.
-- 
 _ __			NEVIN J. LIBER	..!ihnp4!ihlpf!nevin1	(312) 510-6194
' )  )				"The secret compartment of my ring I fill
 /  / _ , __o  ____		 with an Underdog super-energy pill."
/  (_</_\/ <__/ / <_	These are solely MY opinions, not AT&T's, blah blah blah

mlight@hpiacla.HP.COM (Mike Light ) (04/14/88)

<>>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 */

{Well, I have gotten several mail messages and seen several followups all
{saying the same thing:  "That's just the way it works."  As opposed to
{saying "It works this way because of <insert good idea>".

Typedef is little different than a macro substitution for type definitions.
It wasn't meant to create a "new" type somehow different or incompatible
with other types.  Sounds to me like you need Pascal.

{Larry Campbell                                The Boston Software Works, Inc.

Mike Light -- Hewlett-Packard Co.   ..!hpda!hpiacla!mlight

peter@athena.mit.edu (Peter J Desnoyers) (04/15/88)

> (not sure who wrote this...)
>> 	typedef int TEMPERATURE;
>> 	typedef int PRESSURE;
>> 	TEMPERATURE tx, ty;
>> 	PRESSURE px, py;
>> 	ty = py;		/* type clash */
>> I _know_ how it works.  I am arguing that how it works is a _bad thing_.
>
My opinion of this is the following:

(1) I like strong typechecking. For true typechecking, typedef must
create a NEW type, rather than a synonym for an existing type.

(2) The language features necessary to do such typechecking are not
present in C. You can't require values in an expression to be of the
same type when they must be promoted to a possibly different type
before the expression is evaluated. You really need something
equivalent to overloading and inheritance to be able to do such
typechecking rationally.

Unless you turn C into a COMPLETELY different language (don't laugh -
they may do that to FORTRAN) I think we're stuck with typedef creating
an alias.

				Peter Desnoyers
				peter@athena.mit.edu

lied@ihuxy.ATT.COM (Bob Lied) (04/16/88)

In article <759@xyzzy.UUCP> throopw@xyzzy.UUCP (Wayne A. Throop) writes:
>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.  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.

	Bob Lied	ihnp4!ihuxy!lied

jay@splut.UUCP (Jay Maynard) (04/16/88)

In article <3415@haddock.ISC.COM> karl@haddock.ima.isc.com (Karl Heuer) writes:
>Okay, let's pretend we have such strictness.
>  typedef int foo_t;
>  typedef int bar_t;
>  foo_t f1, f2;
>  bar_t b1;
>  int   i;
>
>Now, which of the following expressions should be legal, and what should be
>their types?
>  -f1         f1 + 1      f1 - f2     f1 * 5      f1 / f2
>  f1 + b1     f1 * b1     f1 = i      i = f1      f1 = b1

My (non-C-guru, and therefore solely intuitive) take at this is that
typedef'd stuff should be freely intermixable with objects of the same
(typedef'd) type and the underlying type, but not other typedef'd types.
(As this would probably break _mountains_ of existing code, I, like
Larry Cipriani, suggest this should be a lint function...one that could
be turned off.) Assignments would not do automatic conversion between
typedef'd types, but could between the typedef'd type (is there a word
for that?? :-) and the underlying type.

This would make all the above except f1+b1, f1*b1, and f1=b1 legal.

>I'm not saying that dimensional analysis shouldn't be done, just that it's not
>trivial to define the rules.  In fact I have a partially-written essay on
>this, which I might post someday...

Please enlighten me as to the complications, as the above _seems_ too
easy...


-- 
Jay Maynard, EMT-P, K5ZC...>splut!< | GEnie: JAYMAYNARD  CI$: 71036,1603
uucp: {uunet!nuchat,hoptoad!academ!uhnix1,{ihnp4,bellcore}!tness1}!splut!jay
Never ascribe to malice that which can adequately be explained by stupidity.
Pledge #29: Vote for Kent Paul Dolan and the Birthright Party in '88!

mjy@sdti.UUCP (Michael J. Young) (04/18/88)

In article <4399@ihlpf.ATT.COM> nevin1@ihlpf.UUCP (00704a-Liber,N.J.) writes:
>Here is one that I see a lot among beginning C programmers:
>
>	typedef	char *	string;
>
>If I have the following declaration:
>
>	string	foo;
>
>I really don't want
>
>	foo = "bar";
>
>to be an error or even a warning from lint.

Actually, this probably isn't a good example.  A more likely implementation
of strong typing of typedefs would treat the base type as compatible with
a new type derived from it.  For example, in Modula-2 (taken directly from
Wirth's book):
	TYPE A = ARRAY [0..99] OF CHAR;
	     B = ARRAY [0..99] OF CHAR;
	     C = A;
Variables of type C are compatible with those of type A, but A and B are
incompatible.  Similarly, variables of type A are compatible with those of
type ARRAY [0..99] of CHAR.

Using this model, type string should be compatible with string literals, which
in this context are just char *.
-- 
Mike Young - Software Development Technologies, Inc., Sudbury MA 01776
UUCP     : {decvax,harvard,linus,mit-eddie}!necntc!necis!mrst!sdti!mjy
Internet : mjy%sdti.uucp@harvard.harvard.edu      Tel: +1 617 443 5779
"Bill & Opus in '88" -- Consider the alternatives!

throopw@xyzzy.UUCP (Wayne A. Throop) (04/18/88)

> 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

chris@mimsy.UUCP (Chris Torek) (04/19/88)

In article <796@xyzzy.UUCP> throopw@xyzzy.UUCP (Wayne A. Throop) writes:
>[enumerated types] 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 ....

As it happens, the most recent 4BSD compilers work this way.  For
instance, fed the following, cc complains about lines 8 and 10:

	1	enum pressure { p_low = 0, p_high = 760 };
	2	enum temperature { t_low = -273, t_high = 100 };
	3	f() {
	4		enum pressure p;
	5		enum temperature t;
	6		p = p_low;
	7		t = t_high;
	8		p = t_high;
	9		p = 100;
	10		p = t;
	11	}

This turns out to be quite easy to implement.  The routine `chkpun' is
the place where type clashes are noticed.  If either part of some
operator is an enumerated types, then if both are enumerations but the
two are not the same, complain; otherwise, pretend any enumerated type
is an |int|, and perform the usual tests (pointer vs integer, etc.).
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris@mimsy.umd.edu	Path:	uunet!mimsy!chris

throopw@xyzzy.UUCP (Wayne A. Throop) (04/21/88)

> chris@mimsy.UUCP (Chris Torek)
>> throopw@xyzzy.UUCP (Wayne A. Throop)
>>[enumerated types] 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.
> As it happens, the most recent 4BSD compilers work this way.  For
> instance, fed the following, cc complains about lines 8 and 10:
> 	1	enum pressure { p_low = 0, p_high = 760 };
> 	2	enum temperature { t_low = -273, t_high = 100 };
> 	3	f() {
> 	4		enum pressure p;
> 	5		enum temperature t;
> 	6		p = p_low;
> 	7		t = t_high;
> 	8		p = t_high;
> 	9		p = 100;
> 	10		p = t;
> 	11	}

Note: according to draft X3J11, a compiler has no reason to complain
about the assignment of t_high to p, because t_high is of type (int),
not of type (enum temperature).  I don't object to a lint-like tool
complaining about this, mind you: it's just that under the rules Chris
mentions above, it has no explicit reason to do so.

(Does anybody know *WHY* enumeration member names have integer type?
 This prohibits the reasonable diagnostic above, and at the same time
 limits enumerations to spanning at most (int) and ruling out (long) for
 no particular reason I can discern.)

(Also, does anybody have any comment about using enumermations as
 integer subranges, as the above example implies?  In particular is it
 guarangeed by draft X3J11 that (t=75) must work, or that (t=t_low,++p)
 must insure that ((int)t)==(-272), and all the rest that would make
 subranges useful?)

--
It is a lovely language, but it takes a very long time to say anything
in it, because we do not say anything in it, unless it is worth taking a
long time to say, and to listen to.
                        --- J.R.R. Tolkien
-- 
Wayne Throop      <the-known-world>!mcnc!rti!xyzzy!throopw