[cfe-dev] david's integer overflow stuff

[David Chisnall]

Hi John,

The trap handler I was using was:

long long __overflow_handler(long long a, long long b, unsigned char op, unsigned char width)

Where a and b were the two operands, op represented the operation, and width gave the number of bits in the original.  The low bit in op indicated whether it was a signed or unsigned operation, and then the other 7 bits could be used for identify the type of operation (add, subtract, and multiply were the only ones used, as divide can't overflow).  

The sign bit was largely superfluous, as Chris removed the -ftrapu option, which would have caused it to be unset, but it is very important for preventing a certain kind of security vulnerability (in particular, when you do malloc(a * b), it would trap if a*b overflowed), because this kind of wrapping is well defined by the standard, even if it's not always used correctly.  

The purpose of this was to make implementing calloc()-style wrappers that were overflow-safe trivial - for example by substituting 0 for the result when it overflowed, so the wrapper would just need to be:

void *safe_malloc(size_t a, size_t b)
{
	size_t s = a * b;
	if (s == 0) { return NULL; }
	return malloc(s);
}

This handler is enough for the CERT AIR stuff to generate a helpful error message when you violate the semantics of the model, for other code to throw an exception, and for LanguageKit to be able to box things that overflow in an object.

I'd like to reinstate support for this handler with an -ftrapv-handler= option, if no one objects, so we default to aborting on overflow if -ftrapv is provided alone, and only call the handler if it is.

Your handler looks better suited to providing detailed error diagnostics for a more general case, so I don't believe that there is any conflict between the two.

David

On 13 Sep 2010, at 06:29, John Regehr wrote:

> David, can you give some details (or a pointer) about the trap handling 
> interface you have been using?
> 
> Our trap interface is below.  It needs work but it has been useful in 
> making it possible to print highly informative error messages about 
> integer problems.
> 
> Moving forward, it seems to make sense to give clang -trapv (or -fcheckv 
> or whatever) the ability to:
> 
> - abort
> 
> - call a lightweight trap handler, designed for performance
> 
> - call a heavyweight trap handler like ours below, designed for verbosity
> 
> John
> 
> 
> static unsigned long long undefined_behavior_trap_handler (unsigned int line,
> 					     unsigned int column,
> 					     char *filename,
> 					     char *opstr,
> 					     char *rule,
> 					     signed char ub,
> 					     signed char ltype,
> 					     signed char rtype,
> 					     unsigned long long lvalue,
> 					     unsigned long long rvalue)
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev


-- Sent from my Cray X1