On 2014-04-10 14:38:46 -0700, Russ Allbery wrote: > I don't want, necessarily, to have slower code to make handling > corner cases easier. However, I am generally happy to have slower > code in return for making the system more secure, as long as the > speed hit isn't too substantial. Security is a much bigger problem > than performance right now for most people.
I agree that security (in the hypothesis that bugs may remain in the software) is preferable to speed, but assuming wrapped signed arithmetic is the wrong thing to do, and using -fwrapv may reveal bugs. For instance, you may have tests like: a + C1 > b + C2 where C1 and C2 are two constants such that C2 > C1 > 0. Without -fwrapv, the compiler would typically rewrite the above test as: a > b + C3, where C3 = C2 - C1. But with -fwrapv, you'll still get the same test a + C1 > b + C2. If a + C1 overflows (which is a bug in the code, but was hidden by the optimization), this will give a different (and wrong) result. The behavior without -fwrapv is closer to what the user would expect. So, using -fwrapv gives a false sense of security. IMHO, in general, for security, it is better to run code with a sanitizer (such as "clang -fsanitize=undefined -fno-sanitize-recover", assuming that the code does not use floating point), as long as denial of service due to a crash from a bug is regarded as preferable to uncontrolled behavior. -- Vincent Lefèvre <vinc...@vinc17.net> - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140414105605.ga5...@ypig.lip.ens-lyon.fr