David Brown <david.brown@hesbynett.no> writes:Sure. But if it were not UB, then a conforming implementation could not make such choices or give me such choices. UB does not mean that I definitely have such choices (as my poor wording implies), but that implementations are able to give me the choice.
[...]UB means precisely that I can choose trapping, or IB, or optimising onNo, it means that the implementation can make that choice (or allow you
the assumption it does not happen.
to make that choice). A conforming compiler could generate code on the
assumption that signed overflow never happens, and not give the
programmer any options.
If the standards had said integer overflow was IB, then that puts limits on what the compiler can do - and therefore on what it can do to help the programmer. Exactly what options it had would depend on the wording of the standard, such as whether it required an "implementation-defined value" or, like narrowing conversions to signed integer types, "either the result is implementation-defined or an implementation-defined signal is raised". However, even in that later case I think it would be more confusing for a lot of programmers - many programmers, quite reasonably, have an intuition that "UB" means "don't do this" or "this is not legal in C". They also have the intuition that "IB" means "this works according to the underlying hardware". If the standards had said integer overflow was IB, most programmers would immediately assume that meant wrapping behaviour.
More interesting, I think, is the possible future "erroneous behaviour" marker. My understanding is that it lets the compiler have traps or other run-time detection, or provide unspecified values, while making it clear that erroneous behaviour is a result of software bugs.
[...]It is obvious - to me, anyway - that signed overflow is a mistake in the code. It is trying to do something that cannot be done. What is the single-digit sum of 5 and 8? There is no answer. The answer is not 3, or 9. Putting your hand in the air and asking the teacher for help might be appropriate sometimes, but it is not a correct answer.
Making this UB is an admission of the blindingly obvious - there is noTrapping or raising/throwing an exception on overflow would also be an
correct answer when signed integer overflow occurs. It tells
programmers that it is a mistake to let your arithmetic overflow, and
it allows tools to help programmers avoid these mistakes, and it
allows compilers to give programmers the most efficient results from
known good code rather than adding unnecessary run-time checks that
are never triggered.
admission of the blindingly obvious.
Throwing some kind of exception or trap can definitely be helpful at times. And I agree that it would make it obvious that there has been a problem detected. But throwing exceptions or traps can cause more problems (the Ariane 5 failure was caused by the exception handler, not the overflow fault). That does not mean it is better to ignore overflows - it means there is no appropriate action that is suitable in every situation. I am far from convinced that there is even a reasonable choice of default action that could be usefully made.
And a sufficiently clever compilerSure - but in practice having strict overflow checks would significantly reduce optimisation and re-arrangement possibilities, as well as having to include the checks themselves. You might allow non-strict checks in some manner (thus allowing optimisations like "a + b - a" reducing to just "b"), but I think that might be hard to specify and would reduce the debugging help of the checks.
can omit some (not all) checks in cases where it can be statically
proved that overflow doesn't occur, and/or hoist some checks out of
loops.
Of course those kinds of checks are not in the "spirit of C".Indeed.
And if we want to move away from the "spirit of C", then I think we should move away from the /language/ of C. In C, people do not expect exceptions or sudden jumps from their code - they expect that if there is checking for errors, it is explicit in the code. In many other languages, there is a much clearer understanding that lots of things can fail and cause immediate exits from the function - and code is (hopefully!) written to handle that.
[...]There are disadvantages in having a trap. It can (depending on hardware) mean extra code to detect the zero - usually that run-time cost is negligible, but sometimes it is not. It will mean extra code to handle the exception - again, often but not always negligible. Those costs apply even if the programmer has made sure that division by zero never occurs. And if a trap is thrown, what then? I think that a programmer that is careful enough to see that a division expression might throw, and handle the trap or exception appropriately, is going to be careful enough to avoid the problem in the first place. So the trap is going to be unexpected and handled badly. A badly handled division by zero exception left the USS Yorktown dead in the water for three hours.
What's the difference between these programs?>I am happy knowing that I cannot divide by 0,Yup. That should be a trap.
For some programs, yes. For others, no.
Is it better /not/ to trap? There is no general rule. If you have tried to divide by zero, something has gone wrong before the division, and there are no good answers to what will go wrong afterwards. Sometimes it is possible to do damage limitation - sometimes not.
The correct way to handle the situation is to avoid it - be sure that you are not dividing by zero in the first place. Identify and handle the problem where it occurs - when this zero is created, or the circumstances leading to that point - rather than trying to do a post-mortem after the failed division. And if you are doing that, then what benefit is there in having trapping for division by zero? It becomes just a waste of effort.
(There are other ways of handling such things, like the use of NaN's in floating point, or extending your integers with some kind of "invalid" indicators.)
[...]Checking for syntax errors is cheap - PC computing power is, in this context, pretty much free and unlimited. If I am using a target environment where run-time resources are plentiful, I would not be using C in the first place.
I don't want to pay the price for checks, traps, and limitedI don't want to pay the price of checking for syntax errors when I know
re-arrangements and optimisations when I know my expressions don't
overflow. But I am also happy to be able to get a trap when I ask for
it.
my code is syntactically correct. But I never know that, because I'm
fallible.
I admit that's not a very strong argument. There are real differencesPerhaps I work in a field where that difference is more extreme than for many programmers, and I thus feel it more than most.
between compile-time and run-time checks.
Les messages affichés proviennent d'usenet.