Bram Moolenaar <[email protected]> wrote: > Dominique Pellé wrote: > >> "Bram Moolenaar wrote: >> >> >> getchar.c: In function 'check_map': >> >> getchar.c:5221:7: warning: assuming signed overflow does not occur when >> >> assuming that (X - c) <= X is always true [-Wstrict-overflow] >> >> if (len > mp->m_keylen - 3) >> >> ^ >> > >> > That looks like a compiler problem. >> >> >> Line getchar.cpp:5221 is as follows: >> >> 5221 if (len > mp->m_keylen - 3) >> >> I don't think that it is spurious warnings, What gcc is saying >> here is that when it compiled the code, it made an optimization >> which assumed that an addition or subtraction did not overflow >> on 32 bits. This is a fair assumption, since overflow with sign >> integer is undefined behavior. It is only well defined with unsigned >> integers. However, lots of code wrongly assume that signed >> integer overflow wrap, which is not correct, and can cause real >> bugs when cranking up optimizations. Hence the warning. > > Unfortunately this is caused by recent C standard where people writing > compiler optimizers forced this "undefined behavior" so that they could > make programs 0.1% faster. Before this signed integers always > predictably overflowed, since practically all CPUs work that way. > I never like "undefined behavior".
It optimizes even for CPUs that work this way. The optimization can skip some 'if' when the outcome can be determined to be always true of false at compilation time. This is especially useful when inlining functions and using LTO as the compiler gets more knowledge about each conditions, assuming that no overflow happen. Compiler can eve remove loops and compute the result instead without loop. See: http://www.airs.com/blog/archives/120 But it is dangerous for old code. We can compile Vim with -fno-strict-overflow to disable these optimizations, but I'd rather not compile with -fno-strict-overflow and fix bugs instead when we find them. ubsan (undefined behavior sanitizer) detects signed integers at runtime. There were patches that fixed such signed overflows. Some of them were real bugs. I found those at least: commit f4f1956724f70a7def3bcf8a2d77cf1f8c9dd28c Author: Bram Moolenaar <[email protected]> Date: Wed Nov 28 18:22:11 2012 +0100 updated for version 7.3.739 Problem: Computing number of lines may have an integer overflow. Solution: Check for MAXCOL explicitly. (Dominique Pelle) commit bacd9da40eca8c1b3f93f01462cedf346141b824 Author: Bram Moolenaar <[email protected]> Date: Wed Feb 17 18:20:37 2010 +0100 updated for version 7.2.366 Problem: CTRL-B doesn't go back to the first line of the buffer. Solution: Avoid an overflow when adding MAXCOL. Regards Dominique -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
