This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of C++17 status.

### 2422. `std::numeric_limits<T>::is_modulo` description: "most machines" errata

Section: 17.3.5.2 [numeric.limits.members] Status: C++17 Submitter: Melissa Mears Opened: 2014-08-06 Last modified: 2017-07-30

Priority: 2

View all other issues in [numeric.limits.members].

View all issues with C++17 status.

Discussion:

The seemingly non-normative (?) paragraph 61 (referring to N3936) describing how "most machines" define `std::numeric_limits<T>::is_modulo` in [numeric.limits.members] appears to have some issues, in my opinion.

> -61- On most machines, this is `false` for floating types, `true` for unsigned integers, and `true` for signed integers.

Issues I see:

1. Very minor: change clause 2 to "this is `false` for floating point types". Other uses of the term say "floating point types" rather than just "floating types" — see nearby `is_iec559`, `tinyness_before`, etc.

2. `is_modulo` must be `true` for unsigned integers in order to be compliant with the Standard; this is not just for "most machines". For reference, this requirement is from [basic.fundamental] paragraph 4 with its footnote 48.

3. Depending on the definition of "most machines", `is_modulo` could be `false` for most machines' signed integer types. GCC, Clang and Visual Studio, the 3 most popular C++ compilers by far, by default treat signed integer overflow as undefined.

As an additional note regarding the definition of `is_modulo`, it seems like it should be explicitly mentioned that on an implementation for which signed integer overflow is undefined, `is_modulo` shall be `false` for signed integer types. It took bugs filed for all three of these compilers before they finally changed (or planned to change) `is_modulo` to `false` for signed types.

[2014-12 telecon]

HH: agree with the proposal, don't like the phrasing
AM: second note feels a bit wooly
WB: not even happy with the first note, notes shouldn't say "shall"
JW: the original isn't very prescriptive because "on most machines" is not something the standard controls.
AM: "On most machines" should become a note too?
AM: first note is repeating something defined in core, shouldn't say it normatively here. Change "shall" to "is"?
MC: don't like "signed integer overflow is left undefined" ... it's just plain undefined.
AM: implementations can define what they do in that case and provide guarantees.
WB: in paragraph 61, would like to see "this" replaced by "is_modulo"
AM: Move to Open

[2015-05-05 Lenexa]

Marshall: I will contact the submitter to see if she can re-draft the Proposed Resolution

Previous resolution [SUPERSEDED]:

> 1. Edit 17.3.5.2 [numeric.limits.members] around p60 as indicated:

>    >     static constexpr bool is_modulo;

>    > -60- True if the type is modulo.(footnote) 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`.

>    > -??- [Note: `is_modulo` shall be `true` for unsigned integer types (6.8.2 [basic.fundamental]). — end note]

>    > -??- [Note: `is_modulo` shall be `false` for types for which overflow is undefined on the implementation, because such types cannot meet the modulo requirement. Often, signed integer overflow is left undefined on implementations. — end note]

>    > -61- On most machines, this is `false` for floating point types, `true` for unsigned integers, and `true` for signed integers.

>    > -62- Meaningful for all specializations.

[2016-05-21 Melissa Mears comments and provides improved wording]

GCC and Clang have `-fwrapv` and MSVC (as of a May 2016 preview build) has `/d2UndefIntOverflow-` as compiler command line flags to define signed integer overflow as wrapping. Such implementations can't set `is_modulo` to `true` for signed integer types when these options are enabled, because if translation units using opposite settings were linked together, the One Definition Rule would be violated.

Previous resolution [SUPERSEDED]:

> 1. Edit 17.3.5.2 [numeric.limits.members] around p60 as indicated:

>    >     static constexpr bool is_modulo;

>    > -60- True if the type is modulo.(footnote) 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`.

>    > -??- [Note: `is_modulo` is `true` for unsigned integer types (6.8.2 [basic.fundamental]). — end note]

>    > -??- [Note: `is_modulo` is `false` for signed integer types (6.8.2 [basic.fundamental]) unless an implementation, as an extension to this International Standard, defines signed integer overflow to wrap as specified by the reference mentioned in footnote 217. — end note]

>    > -??- [Note: `is_modulo` is `false` for floating point types on most machines. — end note]

>    > -61- On most machines, this is `false` for floating types, `true` for unsigned integers, and `true` for signed integers.

>    > -62- Meaningful for all specializations.

[2016-06, Oulu]

We believe that the notes about unsigned integer types and floating point types are already evident from what the standard describes and should be removed. Furthermore the suggested note for signed integer types really shouldn't refer to a footnote in the own document, because footnotes have no stable identifiers. The below given revised resolution has been changed accordingly.

[2016-06 Oulu]

Added rationalization for changes. Moved to Ready.

Friday: status to Immediate

Proposed resolution:

1. Edit 17.3.5.2 [numeric.limits.members] around p60 as indicated:

   >     static constexpr bool is_modulo;

   > -60- True if the type is modulo.(footnote) 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`.

   > -??- [Example: `is_modulo` is `false` for signed integer types (6.8.2 [basic.fundamental]) unless an implementation, as an extension to this International Standard, defines signed integer overflow to wrap. — end example]

   > -61- On most machines, this is `false` for floating types, `true` for unsigned integers, and `true` for signed integers.

   > -62- Meaningful for all specializations.