Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!iuvax!purdue!haven!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn)
Newsgroups: comp.std.c
Subject: Re: Token pasting in #include directive
Message-ID: <11701@smoke.BRL.MIL>
Date: 28 Nov 89 20:24:03 GMT
References: <11160@riks.csl.sony.co.jp> <1989Nov22.222413.3874@utzoo.uucp> <970@sdrc.UUCP> <20961@mimsy.umd.edu>
Reply-To: gwyn@brl.arpa (Doug Gwyn)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 30

In article <20961@mimsy.umd.edu> chris@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.