<br><br><div class="gmail_quote">On Sun, Jun 6, 2010 at 11:30 AM, Jordy Rose <span dir="ltr"><<a href="mailto:jediknil@belkadan.com">jediknil@belkadan.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
The design of this patch is such that it /creates/ overflow conditions,<br>
which are not errors. Consider a condition which reduces to (x-1 >=<br>
UINT_MAX), where x is unsigned. The new SimpleConstraintManager::EvalBinOp<br>
essentially rewrites this as (x >= UINT_MAX+1), which of course is an<br>
overflow for the type. This isn't an error, it's vacuously false, so we<br>
know that the true branch is infeasible.<br>
<br>
Similarly, if the condition comes down to ((x+2)-1 >= UINT_MAX), it's true<br>
iff (x >= UINT_MAX-1). The constraint manager rewrites this first to ((x+2)<br>
>= UINT_MAX+1) and then to (x >= UINT_MAX-1). Even though there was an<br>
intermediate "overflow" of UINT_MAX+1, the final constraint is still<br>
meaningful.<br></blockquote><div><br>I understand your point. I mean we should also report such tautology conditions to the user in some checker and re-use that results in the following evaluation.<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

<br>
I agree that a general overflow checker would be useful, but that's not<br>
what I was using it for here. None of the test cases are actually about<br>
true overflows.<br>
<br>
<br>
On Sun, 6 Jun 2010 11:04:09 +0800, Zhongxing Xu <<a href="mailto:xuzhongxing@gmail.com">xuzhongxing@gmail.com</a>><br>
wrote:<br>
<div><div></div><div class="h5">> Hi Jordy,<br>
><br>
> This patch looks good to me.<br>
><br>
> About overflow, in the future it could be filtered in another specific<br>
> integer overflow checker. For example, if we have code:<br>
><br>
>   if (x + c1 > c2) ...<br>
><br>
> and c2 - c1 > MAX_INT, it's better to process this case in a overflow<br>
> checker to say that this condition could never be true and emit a<br>
warning<br>
> about it. Then abort the path or proceed as the condition indicates.<br>
><br>
> With this integer overflow checker, the process of overflow in<br>
constraint<br>
> manager could be simpler or different. For example, we could emit<br>
warning<br>
> once an overflow occurs, and ignore their cancel out effects entirely.<br>
><br>
> On Sun, Jun 6, 2010 at 9:01 AM, Jordy Rose <<a href="mailto:jediknil@belkadan.com">jediknil@belkadan.com</a>><br>
wrote:<br>
><br>
>> *ping*<br>
>><br>
>> Very basic support for handling conditions involving addition and<br>
>> subtraction, such as this:<br>
>><br>
>>  char* name = malloc(1);<br>
>>  if (length+1 == 10) {<br>
>>    free(name);<br>
>>  }<br>
>>  if (length+1 == 10) {<br>
>>    name = malloc(1); // no-warning<br>
>>  }<br>
>>  free(name);<br>
>><br>
>> Fixes PR2695; next on the list would be to expand this for the case in<br>
>> PR4550, which uses shifts. These will be harder, of course, since<br>
shifts<br>
>> and the rest of the binary operations (except XOR) destroy information.<br>
>><br>
>> Hoping this is a reasonable way to implement this? In particular, I get<br>
>> the feeling that there's an easier way to perform APSInt operations and<br>
>> catch overflow.<br>
>><br>
>> _______________________________________________<br>
>> cfe-commits mailing list<br>
>> <a href="mailto:cfe-commits@cs.uiuc.edu">cfe-commits@cs.uiuc.edu</a><br>
>> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits</a><br>
>><br>
>><br>
</div></div></blockquote></div><br>