------- Additional Comments From veksler at il dot ibm dot com 2005-06-27
20:28 -------
(In reply to comment #13)
> Invalid as the C++ standard says:
> " True if the type is modulo.203) 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. Generally,
> this is false for floating types,
> true for unsigned integers, and true for signed integers on"
>
> it says "if possible" which means not always but some of the time.
It seems to me you are being subtly inconsistent.
Correct me if I misread your comments:
1. signed overflow is undefined
[letting the compiler do whatever it likes.
In that case the compiler may decide, among other things, to trap,
saturate or modulo].
2. It is OK for a compiler to set is_modulo because as it is undefined,
modulo result may be recieved from the random junk that "undefined"
produces. And to prove your point you refer to "...it is possible to
add two positive numbers and have a result that wraps around.."
The logic of 2. works both ways. Any logical conclusion will be
valid in the presense of "undefined". I can say that since <limits>
does not know exactly what gcc does or does not do, it wll *may*
be possible that the undefined behavior always leads to MAX_INT.
So, if we want to have a reasonable meaning for the sentance
"...it is possible to add ...", it should be read as
"...it is possible to choose such values that when added...".
Reading any other way does not make sense, especially if you put
the nondeterministic "undefined" into the mix.
This requires a DR to get a formal clarification, for people with
Andrew's point of view, and avoid future confusion.
Andrew: Don't you think that all this noise indicates that this is
not a clear cut case? When there is a dispute, aren't we choose
the most pragmatic and useful point of view (until a formal clarification
is given)? Don't you agree that:
1. Sometimes using "undefined" simplifies the compiler and improves
generated code.
2. (OTOH) Undefind situations are unhelpful the the users, they complicate
debugging, and make programming harder. Reducing rules that imply
undefined behavior semantics is good for the users.
3. Each language strikes a different balance between 1 and 2.
4. Claiming that numeric_limits<signed>::is_modulo based on "undefined"
does not help the user, because as a result you lose all the benefits of
is_modulo to begin with. Consider the example:
template <class T> T foo(T a, T b)
{
// For example simplicity, this "if" is not generic.
if (numeric_limits<T>::is_modulo)
return trivial_code (a+b); // undefined for signed
else
return contorted_slow_code(a, b);
}
is_modulo = true is unhelpful, it will trigger the undefined case,
a case that the code tries to avoid. It makes it more difficult to
write generic code that avoids the trouble.
It is much more helpful to go for is_modulo = false.
5. There is no performance penatly for is_modulo = false, so item 1 does
not come into play.
6. According to 3, the language should strike a balance between 1 and 2.
Since 1 is not playing any role here, then 2 wins and the language
should go for the semantics that does not depend on "undefined".
7. The text of the standard may be interpreded both ways (a fact: several
people draw contradictory conclusions from the document). In that
case we should choose what makes more sense if we would write the
document.
8. When interpreting an ambiguous document (7), we should take the motives
of the writers and the whole document objectives into account.
According to 6, is_modulo = false strikes the best balance, as a result
it would have been preferred by any reasonable committy.
Michael
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22200
