Re: Merge cpplib and front end hashtables, part 1

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

On Sat, May 12, 2001 at 10:58:43PM +0100, Joseph S. Myers wrote:
> On Sat, 12 May 2001, Neil Booth wrote:
> 
> > Hmm.  Are you referring to things like ordering of options on the
> > command line and macros based on what comes last, and other fun?  This
> > would address some of the issues, but many would still remain.  They
> > could all be handled with a different driver model, but I've not spent
> > much time on the driver stuff I proposed last year.
> 
> Yes.  As long as the macros get defined by different logic from the logic 
> that sets variables in cc1, these problems arise.
> 
> Allowing macros to be defined in cc1 rather than just the driver would
> also e.g. allow <limits.h> to be simplified - without needing multiple
> variants for different systems, and without each target where the size of
> "long" can vary having to do its own definitions of __LONG_MAX__ and such
> like, the compiler could unconditionally define macros such as __INT_MAX__
> using its knowledge of the type it has for int, ensuring <limits.h> does
> not get out of step with the compiler's types.  I don't know how your
> driver rewrite fits it, but allowing macros to be defined by cc1 seems
> like something that ought to be a natural useful consequence of integrated
> cpp.

C front end logic could certainly make calls to cpp_define().  The
difficulty is in ensuring that -save-temps generates an accurate
intermediate file.  Perhaps this is what you mean by making cc1 do
cpp0's job.

-- 
zw  But then one day I came up with a radical new paradigm for my business...
    I decided that from now on I would only sell boring stuff that people
    actually need.
    	-- Garry Trudeau, _Doonesbury_