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]

Reply via email to