Token pasting in #include directive
Doug Gwyn
gwyn at smoke.BRL.MIL
Wed Nov 29 07:24:03 AEST 1989
In article <20961 at mimsy.umd.edu> chris at mimsy.umd.edu (Chris Torek) writes:
>The following is (apparently---anyone who can supply text proving otherwise
>is welcome to follow up) legal:
> #define x point.xpart
> #define y point.ypart
> #include <math.h>
>Thus, if <math.h> includes the line
> double pow(double x, double y);
>the compiler will attempt to parse the expansion
> double pow(double point.xpart, double point.ypart);
>which will give a syntax error.
I believe that's a valid analysis, for implementations that process
<>-style #includes "the usual way". However, conforming implementations
may implement standard headers by any of a number of techniques, some
of which would not involve applying externally-#defined macros (other
than NDEBUG) to the "contents" of the standard header.
For most implementations, however, it's a valid point to be taken into
consideration by the implementor. There is an even subtler problem to
consider:
#include <stdio.h>
void foo() {
int _iob; /* not file scope, so not reserved */
_iob = getchar(); /* getchar better not use _iob */
}
I think Sue Meloy of H-P called attention to this among many other
implementation notes in an issue of the Journal of C Language Translation.
More information about the Comp.std.c
mailing list