Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!cbatt!ihnp4!qantel!lll-lcc!lll-crg!seismo!vrdxhq!BMS-AT!stuart
From: stuart@BMS-AT.UUCP (Stuart D. Gathman)
Newsgroups: net.lang.c
Subject: Re: enum function bug?
Message-ID: <226@BMS-AT.UUCP>
Date: Mon, 29-Sep-86 00:57:36 EDT
Article-I.D.: BMS-AT.226
Posted: Mon Sep 29 00:57:36 1986
Date-Received: Tue, 30-Sep-86 13:26:49 EDT
References: <299@sdchema.sdchem.UUCP> <86900054@haddock> <572@opus.nbires.UUCP>
Organization: Business Management Systems, Inc., Fairfax, VA
Lines: 31
Summary: It's not this complicated!

In article <572@opus.nbires.UUCP>, rcd@nbires.UUCP (Dick Dunn) writes:

> The problem goes a little deeper than this.  Consider that if an enum is
> defined in a .h file, and that header file is used in two separate .c
> files, you have (by some annoyingly reasonable argument) two separate
> types!  [Substitute canonical discussion of name equivalence vs structural

Did you ever wonder how lint handles _structures_ in .h files?  It's really
very simple: anything defined in the same file (even included files)
with the same name is the same.  The same logic works for enum.  

Note that identical structures defined in different files (i.e.
a function returning a structure that is not defined with a .h file)
are considered different types by lint.  I like this because it
encourages defining global structures in only one place (a header file).

Lint keeps track of which file a definition is in with (I believe)
the #line output of cpp.

We have lint in Xenix and CTIX, two very different machines, and the
above is true for both.

I agree: cc should treat enum like structures.  I especially wish that
enum value names did not conflict with variable names.  When using
enum for switch cases or with enum variables, this use is obvious.
Assigning enum values to int's would give an error.  Is there ever
a legitimate reason for doing so?  (Why aren't you using an enum
variable?)  Note that you can still assign (or cast) an enum
variable to an int.
-- 
Stuart D. Gathman	<..!seismo!{vrdxhq|dgis}!BMS-AT!stuart>