https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90081
--- Comment #8 from Harald van Dijk <harald at gigawatt dot nl> --- (In reply to jos...@codesourcery.com from comment #7) > No, INT8_C(5) must expand to have type int, not int_least8_t, if > int_least8_t promotes to int. See 7.20.4#3, "The type of the expression > shall have the same type as would an expression of the corresponding type > converted according to the integer promotions.". *Not* the type itself, > the promoted type. Good point, my earlier suggested definition is missing an extra + to handle that. > I think expanding the macro to its argument is clearly correct here, > including for UINT8_C, as the interpretation suggested in DR#456 > regarding having an unsigned type in #if leads to the obvious absurdities > I described in reflector message 13320 (15 May 2014). That pre-dates the DR's proposed committee response, which is from Oct 2014. Are absurdities not just the natural result of requiring all preprocessor number processing to be done in (u)intmax_t? We already have the situation that e.g. 0U > -1LL is required (under obvious assumptions about type widths) to give different results in #if expressions than outside of them, and GCC implements that.
