danielmarjamaki abandoned this revision.
danielmarjamaki added a comment.
Herald added subscribers: llvm-commits, a.sidorin, rnkovacs.
I will not continue working on this. Feel free to take over the patch or write
a new patch.
Repository:
rL LLVM
https://reviews.llvm.org/D30489
danielmarjamaki updated this revision to Diff 119590.
danielmarjamaki added a comment.
Herald added a subscriber: szepet.
As suggested, use a ProgramState trait to detect VLA overflows.
I did not yet manage to get a SubRegion from the DeclStmt that matches the
location SubRegion. Therefore I am
xazax.hun added a comment.
In https://reviews.llvm.org/D30489#769916, @NoQ wrote:
> An idea. I believe the safest way to find the bugs you mentioned would be to
> replace extent-as-a-symbol with extent-as-a-trait.
>
> I.e., currently we construct `extent_$3{SymRegion{conj_$1{char *}}}`, assume
NoQ added a comment.
An idea. I believe the safest way to find the bugs you mentioned would be to
replace extent-as-a-symbol with extent-as-a-trait.
I.e., currently we construct `extent_$3{SymRegion{conj_$1{char *}}}`, assume
that it is equal to `reg_$0` (which produces a `SymSymExpr`) and
xazax.hun added a comment.
In https://reviews.llvm.org/D30489#728945, @danielmarjamaki wrote:
> I would propose that I rename and cleanup RangeConstraintManager::uglyEval()
> and add it. When I tested it, the Z3 does not seem to handle this.
What do you mean by Z3 not handling this? I mean,
danielmarjamaki added a comment.
This revision now requires changes to proceed.
Ping. Any comments?
Repository:
rL LLVM
https://reviews.llvm.org/D30489
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
danielmarjamaki added a comment.
I would propose that I rename and cleanup RangeConstraintManager::uglyEval()
and add it. When I tested it, the Z3 does not seem to handle this.
Repository:
rL LLVM
https://reviews.llvm.org/D30489
___
cfe-commits
danielmarjamaki updated this revision to Diff 94509.
danielmarjamaki added a comment.
This is just work in progress!!
With these changes Clang static analyzer will detect overflow in this sample
code:
void foo(int X) {
char *Data = new char[X];
Data[X] = 0; // <- error
delete[]
xazax.hun added a comment.
In https://reviews.llvm.org/D30489#689947, @zaks.anna wrote:
> Should we just remove ArrayBoundChecker.cpp or is there a value in keeping it
> around?
I think once ArrayBoundCheckerV2 is in production we should only keep
ArrayBoundChecker there as educational
danielmarjamaki added a comment.
> Also, in your state dumps no information is actually lost. The fact that the
> value of variable sz is reg_$0 is trivial: you could ask the Store what's
> the value of the variable sz and it'd say reg_$0 if there are no bindings
> over it.
Thanks. I have
zaks.anna requested changes to this revision.
zaks.anna added a comment.
This revision now requires changes to proceed.
Following Gabor's suggestion, we should investigate if ArrayBoundCheckerV2
supports this. If not it's possible that we are hitting the Constraint Solver
limitations.
NoQ added a comment.
In https://reviews.llvm.org/D30489#691475, @danielmarjamaki wrote:
> Do you agree that this is the problem? Would it be a good idea to try to keep
> the sz in the ProgramState?
Environment stores values only temporarily. It's kind of a scratch pad for
temporary symbolic
danielmarjamaki added a comment.
To me it seems that the extent is calculated properly in ArrayBoundsV2.
Existing code:
DefinedOrUnknownSVal extentVal =
rawOffset.getRegion()->getExtent(svalBuilder);
This ugly little debug code will extract the needed VLA information from the
zaks.anna added a comment.
Gábor's suggestion sounds good to me. I think ArrayBoundCheckerV2 checker has a
higher chance to be productized / moved out of alpha in the future.
Should we just remove ArrayBoundChecker.cpp or is there a value in keeping it
around?
Repository:
rL LLVM
xazax.hun added a comment.
There is an alternative approach idea:
This is not found by ArrayBoundCheckerV2? If no, an alternative approach would
be to properly set the constraints on the extent of the VLA's memory region.
After that, maybe ArrayBoundCheckerV2 would work automatically on this
danielmarjamaki created this revision.
This is a work in progress patch. I try to detect such error:
void foo(int X) {
int Buf[X];
Buf[X] = 0;
}
The patch successfully detects this bug. However it writes FP when you try to
take the address.
I would like to know if you think my
16 matches
Mail list logo
