Hi Joseph, > "representable as signed long" constraint.
I included this in the original proposal mainly for the sake of formality, but it dawned on me that it is not correct in the literal sense as you point out: the preprocessor of course has no knowledge of C types (long, int, signedness) and all numbers are treated as (by some definition) preprocessor integers and evaluation is implementation-defined for large constants. > where all signed types have the same representation as intmax_t. This gets us closer to the point of what I was intending to make: intmax_t is at least as wide as (signed) long. Being somewhat unfamiliar with the codebase - as in, where to pull this information from - I put down the check as is given with the intention of eventually revisiting this. -- With Valediction, Kamila Szewczyk (https://iczelia.net) On 1/15/26 11:38 PM, Joseph Myers wrote: > On Thu, 15 Jan 2026, Andrew Pinski wrote: > >>> + pfile->state.parsing_args = saved_parsing_args; >>> + pfile->keep_tokens = saved_keep_tokens; >>> + pfile->state.prevent_expansion = saved_prevent_expansion; >>> + >>> + if (m > (unsigned long) LONG_MAX) >> I am not even sure this could ever happen as it would require more >> memory than the machine had to get to this point. > > I suspect this is trying to implement the bit of the paper with a > "representable as signed long" constraint. Which is not a coherent > specification, given that the preprocessor isn't supposed to know about > type sizes at all, so the specification is unclear whether it's actually > following the #if expression evaluation rules where all signed types have > the same representation as intmax_t. Furthermore, this would not be a > valid implementation of that part of the paper, since whatever version of > signed long is being referred to in the paper, it must clearly be one > associated with the *target* not the *host*, and LONG_MAX is for the host. >
