[numeric.limits.members] The example for `is_modulo` is not quite correct for small signed integer types

[frederick-vs-ja]

[numeric.limits.members] currently states:

57. true if the type is modulo.¹⁸²⁾ A type is modulo if, for any operation involving +, -, or * on values of that type whose result would fall outside the range [min(), max()], the value returned differs from the true value by an integer multiple of max() - min() + 1.
58. [Example 1: is_modulo is false for signed integer types ([basic.fundamental]) unless an implementation, as an extension to this document, defines signed integer overflow to wrap. — end example]

On most modern platforms, signed char is 8-bit and int is 32-bit. For any operation involving +, -, or * on two signed char values, the operands are converted to int first, and the behavior is always well-defined and the result (of type int) is always mathematically correct.

There seems to be different interpretations for this case.

1. On these platforms, signed char simply satisfies the condition for is_modulo because the value returned always differs from the true value by zero.
2. Even if we require converting back returned value to singed char, it would always differ from an integer multiple of 256.
3. Given signed char values are converted due to usual arithmetic conversion first, we may said that signed char values don't actually participate in arithmetic operations (see also LWG554). As a result, is_modulo should be vacuously true for signed char (and other non-promoted integer types).

So IIUC std::numeric_limits<signed char>::is_modulo should be true on these platforms and the example is incorrect.

Also, it's not clear why std::numeric_limits<bool>::is_modulo is false. This doesn't seem correct unless the returned value is required to be converted back to bool.

[eisenwave]

On these platforms, signed char simply satisfies the condition for is_modulo because the value returned always differs from the true value by zero.

It could be argued that integer promotion means you're not operating on values of signed char in the first place, so the standard doesn't define whether signed char addition is modular. I don't think you can infer that the condition is satisfied.

Even if we require converting back returned value to singed char, it would always differ from an integer multiple of 256.

Yeah right. If you wrap on 127 + 1 and get -128 after converting back, the mathematical result 128 and the effective result are exactly 256 apart. If you don't convert back, you just get 128, which is 0 * 256 apart from the mathematical result.

So IIUC std::numeric_limits<signed char>::is_modulo should be true on these platforms and the example is incorrect.

I don't think it would match the spirit of the wording if signed char was modulo despite having signed integer overflow UB spiritually, even if integer promotion prevents it from happening.

Also, it's not clear why std::numeric_limits<bool>::is_modulo is false. This doesn't seem correct unless the returned value is required to be converted back to bool.

It's not clear to me what the value of <bool>::is_modulo should be. The current design (implemented by all compilers) seems to be that is_modulo is inherited from <int>::is_modulo if integer promotion happens, which is consistent with signed char. However, the wording doesn't unambiguously support that; there aren't any + or - operations that operate directly on bool anyway, no matter the implementation choices. Why would it then be false or true?

[eisenwave]

I'm marking this not-editorial because this seems like a normative wording defect. It's unclear what numeric_limits<bool>::is_modulo is supposed to be from the wording (or generally, whether integral promotion is relevant to is_modulo), and fixing it seems like LWG issue territory.

[jensmaurer]

CWG2855 addressed overflow UB in ++