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: eric_dana@bmc.com
Cc: gcc-gnats@gcc.gnu.org, dick_schoeller@bmc.com,
	Neil Booth <neil@daikokuya.demon.co.uk>
Subject: Re: preprocessor/5806: The preprocessor evaluates expression s in 64-bit, violating IS C++ 16.1.4
Date: Fri, 1 Mar 2002 13:26:51 -0800

 > The preprocessor evaluates expressions using 64-bits, violating ISO
 > C++ 16.1.4 and 5.19. The problems is generic and can be easily
 > reproduced. This causes the 32/64 bit test on Sequent provided
 > header files to be incorrectly parsed.
 
 Yes, you're right.  The preprocessor is obeying ISO C99 6.10.1p3:
 
   ... all signed integer types and all unsigned integer types act as
   if they have the same representation as, respectively, the types
   intmax_t and uintmax_t defined in the header <stdint.h>.
 
 You can see that this is substantially the same as C++ 16.1p4 [cpp.cond]
 except that intmax_t and uintmax_t have been substituted for long and
 unsigned long.  The former are required to be at least 64 bits wide.
 
 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?
 
 zw