Re: [patch] Re: preprocessor/2706: #defines expanded when -fpreprocessed given

["Zack Weinberg" <zackw at Stanford dot EDU>]

The following reply was made to PR preprocessor/2706; it has been noted by GNATS.

From: "Zack Weinberg" <zackw@Stanford.EDU>
To: Neil Booth <neil@daikokuya.demon.co.uk>
Cc: Nathan Sidwell <sidwell@codesourcery.com>, gcc-gnats@gcc.gnu.org,
   gcc-patches@gcc.gnu.org
Subject: Re: [patch] Re: preprocessor/2706: #defines expanded when -fpreprocessed given
Date: Fri, 4 May 2001 00:06:26 -0700

 On Fri, May 04, 2001 at 07:30:34AM +0100, Neil Booth wrote:
 > Zack Weinberg wrote:-
 > 
 > > It breaks c-torture/execute/920730-1t.c.  The traditional preprocessor
 > > doesn't recognize #include_next (in our limits.h), and passes it
 > > through to the compiler, which rejects it.
 > 
 > That's curious.  So it was only succeeding before because the integrated
 > CPP was processing a #include_next ignored by tradcpp?
 
 #include_next doesn't have IN_I.  It was succeeding because integrated
 CPP was *ignoring* it.
 
 GCC's limits.h and glibc's limits.h interact in a fashion which is
 probably illegal in the State of Georgia.  The upshot is that the test
 case gets all the info it needs without the #include_next operating.
 
 > I'll try to get tradcpp to do include_next in the next day or so, but
 > I'm a bit short of spare time at the moment.
 
 It shouldn't be too hard.  The difficulty is that the code to parse
 the directive, the code to scan the include path, and possibly the
 code to read the file are all tangled together in one huge function.
 *sigh*  If you don't get to it by Sunday I'll give it a shot, but
 tomorrow and Saturday are already booked solid.
 
 > Can we now close PR2706?
 
 My patch hasn't been applied yet.  I still need to test it on the
 mainline, and we need regression suite entries.
 
 zw