Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!rutgers!ames!amdcad!sun!gorodish!guy
From: guy%gorodish@Sun.COM (Guy Harris)
Newsgroups: comp.lang.c
Subject: Re: enum type
Message-ID: <26189@sun.uucp>
Date: Fri, 21-Aug-87 03:13:18 EDT
Article-I.D.: sun.26189
Posted: Fri Aug 21 03:13:18 1987
Date-Received: Sat, 22-Aug-87 18:54:56 EDT
References: <2048@umn-cs.UUCP>
Sender: news@sun.uucp
Lines: 41

> 	enum color marker;
> 
> 	for (marker = yellow ; marker != red ; marker++)
   ...
> 
> Is there any way to make the above work without a lot of casts?

In general, no.

> 	enum color pen;
> 
> 	func( &pen );
   ...
> func( marker )
> enum color *marker;
> 
> Here lint complains that the the argument to func is used inconsistently.
> The code runs fine, but why does lint complain? 

Because it has a bug in it.  The problem is that PCC eventually treats "enum"s
as appropriately-sized integral objects ("char", "short", "int", "long").
This means that pointers to "enum"s get converted to pointers to that integral
object type, so it thinks "func" is getting passed a "char *".

This was fixed in our 3.2 release.  That fix, more or less, has been posted to
"comp.bugs.4bsd" and "comp.bugs.sys5".

> By the way does the ANSI C standard do anything new with enums? like
> provide succ(), pred(), lower(), and upper() functions that operate
> on enum types?

Yes, it does something new.  It does not, however, make "enum"s more
full-fledged data types, with "succ", "pred", etc.  operators.  Instead, it
makes "enum"s *more* like "int"s, so that the "marker++" above would be
permitted, and so that they may be used in pointer arithmetic (and thus may be
used as array subscripts).  One hopes they do not intend to forbid compilers to
generate warnings when "enum" type mismatches are detected, as such mismatches
are usually errors.
	Guy Harris
	{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
	guy@sun.com