On Mon, 1 Jan 2007, Geert Bosch wrote: > As undefined execution can result in arbitrary badness, > this is really at odds with the increasing need for many > programs to be secure. Since it is almost impossible to > prove that programs do not have signed integer overflow, > it makes far more sense to define behavior in such cases.
For a program to be secure in the face of overflow, it will generally need explicit checks for overflow, and so -fwrapv will only help if such checks have been written under the presumption of -fwrapv semantics. Unchecked overflow will generally be a security hole whether or not -fwrapv is used. -ftrapv *may* be safer, by converting overflows into denial-of-service, but that may not always be safe either (and is probably very slow), and explicit checks would still be needed for unsigned overflow: computing an allocation size as n*sizeof(T) will likely use unsigned arithmetic, and undetected overflow is a problem there as well. Examples of overflow checks that require -fwrapv semantics have been noted in this thread, but users expecting security through such checks need to audit the rest of their code for unchecked overflow both signed and unsigned. If they do such an audit and go for checks requiring -fwrapv rather than checks that work without -fwrapv, then they can add -fwrapv (or autoconf could provide AC_WRAPV for such programs to use, that would add -fwrapv to both the default CFLAGS and any provided by the user). Note that if you want wrapping semantics with GCC you can cast to unsigned, do unsigned arithmetic and cast back, since GCC defines the results of converting out-of-range unsigned values to signed types. (Likewise, GCC provides two different ways of allowing aliasing locally rather than using -fno-strict-aliasing globally: you can use unions or the may_alias attribute.) -- Joseph S. Myers [EMAIL PROTECTED]
