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