Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!orchid!rbutterworth
From: rbutterworth@orchid.UUCP
Newsgroups: comp.lang.c
Subject: Re: enum
Message-ID: <11053@orchid.waterloo.edu>
Date: Tue, 6-Oct-87 09:53:31 EDT
Article-I.D.: orchid.11053
Posted: Tue Oct  6 09:53:31 1987
Date-Received: Sat, 10-Oct-87 04:34:48 EDT
References: <1177@laidbak.UUCP> <1314@haddock.ISC.COM>
Organization: U of Waterloo, Ontario
Lines: 33

In article <1314@haddock.ISC.COM>, karl@haddock.ISC.COM (Karl Heuer) writes:
> I just had the same thing happen to me.  I was somewhat surprised that lint
> complained, because I've always considered that to be a valid operation even
> in the strict-enum model.  My workaround was to write a macro
>   #define enum_foo_lt(x,y) ((int)(x) < (int)y)
> , but I dislike this because it doesn't typecheck the arguments

If the program is all in one source file:

    #if defined(lint)
        int enum_foo_lt(x,y) enum foo x,y; { return (int)x < (int)y; }
    #else
    #   define enum_foo_lt(x,y) ((int)(x) < (int)y)
    #endif

If it is in multiple files, put the function definition in a file
by itself without any of the #if stuff, and in "foo.h" put

    extern int enum_foo_lt();
    #if !defined(lint)
    #   define enum_foo_lt(x,y) ((int)(x) < (int)y)
    #endif

In either case, lint will see the function and give strict type
checking and the compiler will see the macro and give the speed.

Note that the second case matches nicely with the way ANSI is
setting up the standard library.  You include "foo.h" and get
access to enum_foo_lt() without knowing whether it is a macro,
a real function, or even a compiler built-in.  If you want to
use it as a real function (e.g. take its address) you must first
"#undef enum_foo_lt" and then "func(&enum_foo_lt);".
(too bad there isn't a #pushdef and a #popdef :-)