|
From: Oliver G. <ol...@gm...> - 2007-10-17 13:44:21
|
Hello, is it possible to use Valgrind to detect if an integer type (32 bit) is used for a value too large for this type (like 2^32 * 1000)? I think this would be something like an "integer overflow", and seems quite difficult to write an automatic test to find such errors embedded in libraries - depending on the actual values the application might work correctly or not. If Valgrind would detect the integer overflow itself, it would be easier to find. Is something like this possible with Valgrind? Thanks, Oliver Gerlich |
|
From: Julian S. <js...@ac...> - 2007-10-17 16:05:25
|
> I think this would be something like an "integer overflow", and seems > quite difficult to write an automatic test to find such errors embedded > in libraries - depending on the actual values the application might work > correctly or not. I don't know of any Valgrind-based tool that will do that. But since Valgrind (meaning the Valgrind framework) will allow you to look at all the values computed by the program (as for example Memcheck does), you could certainly try building such a tool. It would be an interesting project, even. J |
> is it possible to use Valgrind to detect if an integer type (32 bit) is > used for a value too large for this type (like 2^32 * 1000)? Please give actual code. "2^32 * 1000" is 34000 [thirty four thousand.] Did you mean "(1<<32) * 1000" ? At compile time that is zero (with a warning), at runtime that is 1000 because the shift is by the bottom 5 bits only. What did you mean? > > I think this would be something like an "integer overflow", and seems > quite difficult to write an automatic test to find such errors embedded > in libraries - depending on the actual values the application might work > correctly or not. If Valgrind would detect the integer overflow itself, > it would be easier to find. Of course on x86 it is straightforward to use the Valgrind machinery to insert the instruction 'INTO' (interrupt if Overflow) after every arithemtic operation which generates a same-width result (add, subtract, compare, IMULx, IDIVx). But inferring unsigned vs. signed is nearly impossible, and it matters. Also, it is problematic to determine when LEA (Load Effective Address) is doing arithmetic as opposed to address calculation. The MULx and DIVx instructions also are difficult because the output is not the same width as the input. (When is the 32-bit result unsigned, when is it signed, when does it not matter?) -- |
|
From: Julian S. <js...@ac...> - 2007-10-17 17:30:57
|
> On Wednesday 17 October 2007 19:08, John Reiser wrote: > [...] > impossible, and it matters. Also, it is problematic to determine when LEA > (Load Effective Address) is doing arithmetic as opposed to address > calculation. The MULx and DIVx instructions also are difficult because the > output is not the same width as the input. (When is the 32-bit result > unsigned, when is it signed, when does it not matter?) Yes. Thinking about this more, the easy part is detecting wraparound/overflow in arithmetic. The hard part is determining what is significant. I imagine any such tool would get many false positives. For example, on ppc there is (iirc) no subtract-immediate instruction, as that is done using an add-immediate with negative immediate. So then "x - 16" turns into "x + 0xFFFFFFF0"; there is a wraparound, but it isn't significant. J |