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.
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
false
for floating types,true
for unsigned integers, andtrue
for 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_modulo
shall betrue
for unsigned integer types (6.8.2 [basic.fundamental]). — end note] -??- [Note:is_modulo
shall befalse
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 isfalse
for floating point types,. -62- Meaningful for all specializations.true
for unsigned integers, andtrue
for 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_modulo
istrue
for unsigned integer types (6.8.2 [basic.fundamental]). — end note] -??- [Note:is_modulo
isfalse
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
isfalse
for floating point types on most machines. — end note]-61- On most machines, this is. -62- Meaningful for all specializations.false
for floating types,true
for unsigned integers, andtrue
for 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_modulo
isfalse
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. -62- Meaningful for all specializations.false
for floating types,true
for unsigned integers, andtrue
for signed integers