In another question, the topic of std::numeric_limits
came up. But the more I think about it, the more it seems like something is wrong w
If is_modulo
is true
for a signed type (e.g. int
) that is unchanged by the usual arithmetic conversions, then for any arithmetic operation other than division by zero there is a single correct result in the (mathematical) integers that modulo maps to a single value in the range of the type, and so the implementation is constrained to behave as if the actual result is the true result modulo the range of the type. So if an implementation wants to retain overflow arithmetic as being undefined it must set is_modulo
to false
.
This was discussed ad nauseam on the gcc mailing list and then under PR 22200 with the eventual conclusion that the value of is_modulo
should be false
for signed types; the change was made to libstdc++ in April of this year.
Note that in C++03 the language was significantly different:
18.2.1.2 numeric_limits members [lib.numeric.limits.members]56 - [...] A type is modulo if it is possible to add two positive numbers and have a result that wraps around to a third number that is less.
Given that with undefined behaviour anything is possible, it is arguable that the previous behaviour of libstdc++ (having is_modulo
as true
) was correct and consistent with the behaviour of g++; the earlier discussions on the linked PR should be read with this in mind.