std::numeric_limits<T>::is_modulo description: "most machines" errataSection: 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
falsefor floating types,truefor unsigned integers, andtruefor signed integers.
Issues I see:
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.
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.
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]:
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
-??- [Note:+,-, 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 ofmax() - min() + 1.is_moduloshall betruefor unsigned integer types (6.9.2 [basic.fundamental]). — end note] -??- [Note:is_moduloshall befalsefor 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 isfalsefor floating point types,. -62- Meaningful for all specializations.truefor unsigned integers, andtruefor signed integers
[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]:
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
-??- [Note:+,-, 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 ofmax() - min() + 1.is_moduloistruefor unsigned integer types (6.9.2 [basic.fundamental]). — end note] -??- [Note:is_moduloisfalsefor signed integer types (6.9.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_moduloisfalsefor floating point types on most machines. — end note]-61- On most machines, this is. -62- Meaningful for all specializations.falsefor floating types,truefor unsigned integers, andtruefor signed integers
[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:
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
-??- [Example:+,-, 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 ofmax() - min() + 1.is_moduloisfalsefor signed integer types (6.9.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. -62- Meaningful for all specializations.falsefor floating types,truefor unsigned integers, andtruefor signed integers