Re: gcc 2.95.1 fixes for backslashes in #line, #include

[Zack Weinberg <zack@bitmover.com>]

Paul Eggert wrote:
> The following recent change to GCC's preprocessor broke ANSI C conformance:
> 
> 	Mon Dec  7 17:55:06 1998  Mike Stump  <mrs@wrs.com>
> 
> 		* cccp.c (ignore_escape_flag): Add support for \ as `natural'
> 		characters in file names in #line to be consistent
> 		with #include handling....
> 
> I realize that the change was made for the benefit of compiling for
> Microsoft, but the C standard requires that the file names in #line
> directives must be parsed as C strings.  For example, the following
> program must output a single " character followed by a newline, but
> GCC 2.95.1 incorrectly rejects this program:
> 
> 	#line 1 "\""
> 	main () { puts (__FILE__); }
> 
> Also, the old behavior was more useful, since it made it easier to
> write programs that generate C programs from arbitrarily-named files.
> 
> The patch below fixes this problem for cccp, and also fixes several
> related problems as noted below.  It changes the default behavior to
> be ANSI-compliant, as with previous versions of GCC; it also adds a
> new option -fbs-filenames for people who want the Microsoft-like
> behavior.
> 
> I haven't fixed cpplib, though I note that it already parses #include
> and #line filenames as plain strings; I'll CC this message to Zack
> Weinberg so that he can look at the issue.

I think your patch does the right thing.  cpplib does need to be
changed, but I don't have time in the near future to work on it,
unfortunately.  If you make a patch I will look at it and offer my
opinion, but Dave Brolley still owns this part of the code.

One question: What is the treatment of backslashes in #include <...>
with your patch?  For consistency, we should treat them the same as in
#include "..."  but I don't remember what the standard says about it.

zw

p.s. Please do not send gcc-related mail to <zack@rabi.columbia.edu>
anymore.