This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: Preprocessing oddity breaks binutils
- To: Zack Weinberg <zack at rabi dot columbia dot edu>
- Subject: Re: Preprocessing oddity breaks binutils
- From: Andreas Schwab <schwab at issan dot cs dot uni-dortmund dot de>
- Date: 04 Jun 1999 10:29:23 +0200
- Cc: Dave Brolley <brolley at cygnus dot com>, Mark Mitchell <mark at codesourcery dot com>, egcs-bugs at egcs dot cygnus dot com, binutils at sourceware dot cygnus dot com
- References: <199906021849.OAA24100@blastula.phys.columbia.edu>
Zack Weinberg <zack@rabi.columbia.edu> writes:
|> On Wed, 02 Jun 1999 12:04:06 -0400, Dave Brolley wrote:
|> >I agree that this is probably a long standing quirk bug in the
|> >preprocessor which is arguably a bug. Does anyone know of any source which
|> >relies on the current behaviour?
|>
|> FYI, cpplib uses the test.h in the subdirectory. I agree with Mark that
|> this is the right thing - #line should not affect the search path.
But #line changes the file name.
The standard says that the place where to search is implementation
defined. The cpp manual says: "It searches for a file named FILE first in
the current directory, [...]. The current directory is the directory of
the current input file."
About the #line directive the standard says:
[#4] A preprocessing directive of the form
# line digit-sequence "s-char-sequence-opt" new-line
sets the presumed line number similarly and changes the
presumed name of the source file to be the contents of the
character string literal.
Thus the current behaviour of cpp is more in the spirit of the standard,
and IMHO cpplib is wrong.
Andreas.
--
Andreas Schwab "And now for something
schwab@issan.cs.uni-dortmund.de completely different"
schwab@gnu.org