Newsgroups: comp.lang.c
Path: utzoo!henry
From: henry@utzoo.uucp (Henry Spencer)
Subject: Re: Standard Clarification
Message-ID: <1989Oct21.233915.23217@utzoo.uucp>
Organization: U of Toronto Zoology
References: <20974@gryphon.COM> <1150@crdos1.crd.ge.COM> <23218@cup.portal.com>
Date: Sat, 21 Oct 89 23:39:15 GMT

In article <23218@cup.portal.com> Tim_CDC_Roberts@cup.portal.com writes:
>    #define d define
>    #d a include
>    #a <stdio.h>
>
>MSC complains that "d" is an unknown preprocessor directive and aborts.
>Does the standard require that this construct should compile correctly?

Section 3.8.3 (Oct 1988 draft, roughly current except for wording changes):

"If a # preprocessing token, followed by an identifier, occurs lexically
at the point at which a preprocessing directive could begin, the identifier
is not subject to macro replacement."

In other words, ANSI C specifically says that it *doesn't* work.

>    #define abcde getchar
>           ...
>      ch = abcde();
>
>The preprocessor substituted 'getchar' for 'abcde', but then failed to
>expand the 'getchar()' macro from stdio...

Unless I have missed some fine point, your preprocessor is wrong again.
This is legal.

It should be remembered that the preprocessor was *very* vaguely defined
in the old days, and tricky fine points like this varied widely, indeed
wildly, between implementations.  ANSI C has nailed down most of it, but
the macro-replacement section in the draft standard is easily one of the
two or three trickiest parts of the whole document.  (Indeed, there are
still one or two small fuzzy areas that were overlooked.)  It will be
quite a while before all preprocessors comply exactly.
-- 
A bit of tolerance is worth a  |     Henry Spencer at U of Toronto Zoology
megabyte of flaming.           | uunet!attcan!utzoo!henry henry@zoo.toronto.edu