Content deleted Content added
→Explanation for removal: new section |
|||
Line 79:
The article says that integer overflow does not occur for unsigned integers in the C11 standard. This is true, but slightly misleading as readers will think it is a C11 innovation. Actually the same thing was true in the ANSI/C89 standard (3.1.2.5) and the C99 standard (6.2.5).
Apart from one word that seems redundant, both those standards have the same sentence as appears in C11. [[User:Zero0000|Zero]]<sup><small>[[User_talk:Zero0000|talk]]</small></sup> 04:28, 29 January 2023 (UTC)
== Explanation for removal ==
I am removing this:
:{{tq|Caution should be shown towards the latter choice [testing for overflow after the operation]. Firstly, since it may not be a reliable detection method (for example, an addition may not necessarily wrap to a lower value). Secondly, because the occurrence of overflow itself may in some cases be [[undefined behavior]]. In the C language, overflow of unsigned integers results in wrapping, but overflow of signed integers is undefined behavior. Consequently, a C [[compiler]] is free to assume that the programmer has ensured that signed overflow cannot possibly occur and thus its optimiser may silently ignore any attempt to detect overflow in the result subsequent to the calculation being performed without giving the programmer any warning that this has been done. It is thus advisable to always implement checks before calculations, not after them.}}
The wiki-reason for removal is that it is unsourced. The real-life reason for removal is that it is nonsense. A C compiler is ''not'' entitled to read the programmer's mind on whether a bit of code is intended for overflow detection, and ''not'' entitled to assume that the programmer has taken precautions to avoid overflow. The implementation-defined nature of integer overflow means that the result of the operation is not specified in the standard, not that there is no result or that the compiler is allowed to assume the result is different from what it might actually be. For example, if the programmer writes, given x,y known to be positive, "z = x + y; if (z < 0) ''something'';", the compiler ''is not'' allowed to generate code that might make z negative without executing ''something''. However, the compiler ''is'' allowed to generate code that will set z to INT_MAX in the event of overflow, and then optimise out the test because it knows that z will always be positive. That's what "implementation-defined" means.
Repeating myself a bit, "implementation-defined" means "the implementation has decided what the result will be". It does not ever mean "the implementation can make assumptions about the wishes of the programmer". If the implementation has decided that the result of integer overflow is silent wrap-around, then the compiler must generate code that is correct for silent wrap-around. It can't generate wrap-around code and then assume there was no wrap-around. Anyway, the most important reason for signed integer overflow being implementation-defined (and a good reason for testing before the operation for maximum portability) is that an implementation is allowed to generate a trap condition. [[User:Zero0000|Zero]]<sup><small>[[User_talk:Zero0000|talk]]</small></sup> 03:06, 12 September 2023 (UTC)
| |||