Re: preprocessor/5806: The preprocessor evaluates expression s in 64-bit, violating IS C++ 16.1.4

[Zack Weinberg <zack@codesourcery.com>]

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

From: Zack Weinberg <zack@codesourcery.com>
To: Neil Booth <neil@daikokuya.demon.co.uk>
Cc: eric_dana@bmc.com, gcc-gnats@gcc.gnu.org, dick_schoeller@bmc.com
Subject: Re: preprocessor/5806: The preprocessor evaluates expression s in 64-bit, violating IS C++ 16.1.4
Date: Thu, 14 Mar 2002 11:38:40 -0800

 On Fri, Mar 01, 2002 at 11:13:14PM +0000, Neil Booth wrote:
 > Zack Weinberg wrote:-
 > 
 > > The preprocessor ought to do this only in C99 mode; in C++ and
 > > presumably also C89 mode (I don't have a copy of C89 to check) it
 > > should use long/unsigned long, which may be 32 bits wide on some
 > > targets.  Unfortunately, doing this properly requires substantial
 > > changes to GCC, which are planned, but not currently practical.
 > > (We're already not quite compliant; preprocessor arithmetic uses the
 > > _host's_ idea of intmax_t, not the target's.)
 > > 
 > > Neil - as a stopgap, it occurs to me that we could mask intermediate
 > > values down to 32 bits when in C89/C++ mode and sizeof(target unsigned
 > > long) == 4.  Thoughts?
 > 
 > Sounds OK to me.  Like you, I have the C++ and C99 standards, but no C89
 > lying around.  I do believe that the C++ preprocessor section was copied
 > almost verbatim (with some changes for bool and true / false) from C89
 > though.
 
 I looked into this a little, and it founders on the usual problem:
 LONG_TYPE_SIZE can vary with target variables.  So this is blocked on
 the integrated -E mode.  We should make a serious effort to get that
 done for 3.2.
 
 zw