Path: utzoo!mnetor!uunet!lll-winken!lll-tis!ames!ll-xn!mit-eddie!uw-beaver!uw-june!uw-entropy!dataio!bright
From: bright@Data-IO.COM (Walter Bright)
Newsgroups: comp.lang.c
Subject: Re: Of Standards and Inventions: A Cautionary Tale
Message-ID: <1526@dataio.Data-IO.COM>
Date: 11 Apr 88 18:09:41 GMT
References: <10949@mimsy.UUCP> <1525@dataio.Data-IO.COM> <7637@brl-smoke.ARPA>
Reply-To: bright@dataio.UUCP (Walter Bright)
Organization: Data I/O Corporation; Redmond, WA
Lines: 22

In article <7637@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes:
<In article <1525@dataio.Data-IO.COM< bright@dataio.UUCP (Walter Bright) writes:
<<I don't understand why ANSI C doesn't allow casts and sizeofs in
<<preprocessor expressions. ...
<<In my compiler, they follow the same rules because it's the same code!
<We didn't want to mandate that the preprocessor be integrated into the
<language parser proper.  I agree that the language would be nicer if
<it WERE so integrated, but for historical reasons it wasn't.

What I proposed didn't mandate this. What I proposed was to COPY (or use
#ifdef's) the code for the expression parser into the preprocessor code.
This would then ensure that the behavior was the same. The only thing
that the preprocessor's parser couldn't handle would be symbol table
lookups of things that aren't macros. It could and should be able to
handle things like:

#if sizeof(long) != sizeof(int)

and:

#if (unsigned long) 1.2345e+6 > WHATEVER

variations of which I've wanted to do many times.