Agreed too. Generic "error on overflow" is not an answer, and ignoring overflow
is not an answer either because flagging faulty memory allocations is an
important feature.
Brian
Sent with ProtonMail Secure Email.
‐‐‐ Original Message ‐‐‐
On Tuesday, March 2, 2021 6:09 PM, Jeff Law
Wow! I wasn't expecting that to work. Obviously we know that there is currently
no handler for binop_svalue in the constraints so I would have to watch it run
with
state merging disabled to see how it is managing the unroll. The fact that
merging
breaks it is indicative of what we are saying
On 3/2/21 6:40 PM, David Malcolm via Gcc-patches wrote:
>
>> My devil's advocate position would be if the analyzer raises
>> exception on
>> any possible overflow, will that overwhelm the user with false
>> positives?
> Presumably by "raise exception" you mean "issue a diagnostic and stop
>
On Tue, 2021-03-02 at 23:14 +, brian.sobulefsky wrote:
> I have been kicking these sorts of ideas around ever since I came to
> understand that
> the second "UNKNOWN" in the for loop that originally started this was
> due to the state
> merge as we loop. For now, and I don't mean this
I have been kicking these sorts of ideas around ever since I came to understand
that
the second "UNKNOWN" in the for loop that originally started this was due to
the state
merge as we loop. For now, and I don't mean this disrespectfully because it is
very
hard to get right, the whole issue of
On Tue, 2021-03-02 at 07:09 +, brian.sobulefsky wrote:
> Hi,
>
> It may not be worth altering at this point, but it seems like it
> would leave less
> bugs open if all the constraints go in as "closed" ranges and all
> evals are
> translated to closed intervals. So, if (idx > 0) and if (idx
Hi,
It may not be worth altering at this point, but it seems like it would leave
less
bugs open if all the constraints go in as "closed" ranges and all evals are
translated to closed intervals. So, if (idx > 0) and if (idx >= 1) are the same
constraint. I know this won't be an option for
On Sat, 2021-02-27 at 10:04 +, brian.sobulefsky wrote:
> Hi,
>
> Please find a patch to fix part of the bug PR analyzer/94362.
Thanks. Various comments inline below.
> This bug is a
> false positive for a null dereference found when compiling openssl.
> The cause
> is the
Hi,
Please find a patch to fix part of the bug PR analyzer/94362. This bug is a
false positive for a null dereference found when compiling openssl. The cause
is the constraint_manager not knowing that i >= 0 within the for block:
for ( ; i-- > 0; )
The bug can be further reduced to the
