zaks.anna added a comment.
Sorry for the wait!
Repository:
rL LLVM
https://reviews.llvm.org/D30295
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
zaks.anna added inline comments.
Comment at: lib/StaticAnalyzer/Checkers/UndefResultChecker.cpp:134
+else if (I->isUnsigned())
+ OS << I->getZExtValue() << ", which is";
+else
Please print single quotes around the value.
===
zaks.anna accepted this revision.
zaks.anna added a comment.
This revision is now accepted and ready to land.
Thanks!
https://reviews.llvm.org/D36737
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listi
zaks.anna accepted this revision.
zaks.anna added a comment.
Once the comments by @paquette are addressed, LGTM. Thanks!
Comment at: lib/StaticAnalyzer/Checkers/UndefResultChecker.cpp:138
+
+OS << " larger or equal to the width of type '"
+ << B->getLHS()->get
zaks.anna added a comment.
Looks like the need to have the checker name in BugType along with the checker
names not being initialized early enough, leads to worse checker-writer
experience. Is there a way to ensure that the checker names are set at
construction?
Comment at:
zaks.anna added inline comments.
Comment at: lib/StaticAnalyzer/Core/BugReporterVisitors.cpp:651-652
+ } else if (StoreSite->getLocation().getAs()) {
+os << "Reach the max loop limit.";
+os << " Assigning a conjured symbol";
+if (R->canPrintPretty()) {
--
zaks.anna added inline comments.
Comment at: lib/StaticAnalyzer/Core/BugReporterVisitors.cpp:651-652
+ } else if (StoreSite->getLocation().getAs()) {
+os << "Reach the max loop limit.";
+os << " Assigning a conjured symbol";
+if (R->canPrintPretty()) {
--
zaks.anna accepted this revision.
zaks.anna added inline comments.
This revision is now accepted and ready to land.
Comment at: lib/StaticAnalyzer/Core/BugReporter.cpp:1674
const Decl *D = CalleeLC->getDecl();
-addEdgeToPath(PD.getActivePath(), PrevLoc,
-
zaks.anna added a comment.
These are great additions!
Going back to my comment about adding these to CheckerContext, I think we
should be adding helper functions as methods on CheckerContext as it is **the
primary place where checker writers look for helpers**. Two of the three
methods added t
zaks.anna added inline comments.
Comment at: include/clang/StaticAnalyzer/Checkers/Checkers.td:454
+def UnixAPIPortabilityChecker : Checker<"API">,
+ HelpText<"Finds implementation-defined behavior in UNIX/Posix functions">,
+ DescFile<"UnixAPIChecker.cpp">;
Do
zaks.anna added inline comments.
Comment at: include/clang/StaticAnalyzer/Checkers/Checkers.td:454
+def UnixAPIPortabilityChecker : Checker<"API">,
+ HelpText<"Finds implementation-defined behavior in UNIX/Posix functions">,
+ DescFile<"UnixAPIChecker.cpp">;
No
zaks.anna added a comment.
This generally sounds good. Definitely do submit these changes in small pieces!
See http://llvm.org/docs/DeveloperPolicy.html#incremental-development for
rationale.
https://reviews.llvm.org/D27753
___
cfe-commits mailing
zaks.anna added a comment.
Great cleanup! Some comments below.
Comment at: www/analyzer/alpha_checks.html:91
+(C, C++)
+Check for logical errors for function calls and Objective-C message
+expressions (e.g., uninitialized arguments, null function pointers,
fo
zaks.anna accepted this revision.
zaks.anna added a comment.
This revision is now accepted and ready to land.
Looks good with a nit!
Comment at: include/clang/StaticAnalyzer/Core/PathSensitive/SValBuilder.h:325
+ Loc makeNull() { return loc::ConcreteInt(BasicVals.getZeroWith
zaks.anna added a comment.
Should this revision be "abandoned" or is the plan to iterate on it?
Repository:
rL LLVM
https://reviews.llvm.org/D31320
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/list
zaks.anna added inline comments.
Comment at: lib/StaticAnalyzer/Core/SValBuilder.cpp:356
QualType ResultTy) {
- if (!State->isTainted(RHS) && !State->isTainted(LHS))
-return UnknownVal();
I am concerned that removing the g
zaks.anna added a comment.
> -(Anna) Scan-build-py integration of the functionality is nearly finished
> (see https://github.com/rizsotto/scan-build/issues/83) (--ctu switch performs
> both analysis phases at once). This I think could go in a different patch,
> but until we could keep the ctu-b
zaks.anna added inline comments.
Comment at: www/analyzer/alpha_checks.html:91
+(C, C++)
+Check for logical errors for function calls and Objective-C message
+expressions (e.g., uninitialized arguments, null function pointers,
szdominik wrote:
> zaks.anna wrote
zaks.anna added a comment.
> Maybe we should introduce another UMK_* for deeper analysis instead?
The difference here is not substantial enough to warrant a new level. The
general motivation for bumping these numbers is that we've set the timeouts
many years ago and the hardware improved quite
zaks.anna accepted this revision.
zaks.anna added a comment.
This revision is now accepted and ready to land.
Once Artem gives more details about the codebase he tested on, I think it would
be fine to commit this. We can revert/address concerns later if @a.sidorin or
anyone else raises concerns
zaks.anna accepted this revision.
zaks.anna added a comment.
This revision is now accepted and ready to land.
Thanks! Do you have commit access?
Repository:
rL LLVM
https://reviews.llvm.org/D34266
___
cfe-commits mailing list
cfe-commits@lists.ll
zaks.anna added a comment.
> eg. checkers for portability across linux/bsd should be off on windows by
> default, checkers for non-portable C++ APIs should be off in plain C code, etc
Is the checker you are moving to portability off and not useful on Windows?
https://reviews.llvm.org/D34102
zaks.anna accepted this revision.
zaks.anna added a comment.
This revision is now accepted and ready to land.
LGTM. Thank you!
(Not sure if @NoQ wants to do a final review.)
Do you have commit access or should we commit on your behalf?
https://reviews.llvm.org/D30406
___
zaks.anna added inline comments.
Comment at: lib/StaticAnalyzer/Core/SValBuilder.cpp:356
QualType ResultTy) {
- if (!State->isTainted(RHS) && !State->isTainted(LHS))
-return UnknownVal();
ddcc wrote:
> zaks.anna wrote:
> >
zaks.anna added a comment.
> In particular, there are patches to generate more symbolic expressions, that
> could also degrade the performance (but fix some fixmes along the way).
The patch you are talking about might be promising, but needs much more
investigation and tuning for performance vs
zaks.anna added a comment.
> Hmm, should there be new tests that demonstrate that we cover the new APIs?
Unless we use a new registration mechanism for some of these APIs, I'd be fine
without adding a test for every API that has localization constraints.
Repository:
rL LLVM
https://reviews.
zaks.anna added a comment.
This just supports the statement that this particular check should not go under
unix. I understand that it will be inconsistent with the name of the malloc
checker, which we probably should not change as people might be relying on the
package names. I think it's bette
zaks.anna added inline comments.
Comment at: lib/StaticAnalyzer/Core/SValBuilder.cpp:364
if (symLHS && symRHS &&
- (symLHS->computeComplexity() + symRHS->computeComplexity()) < MaxComp)
+ (symLHS->computeComplexity() + symRHS->computeComplexity()) < MaxComp)
re
zaks.anna added a comment.
I think we should have these is .rst format as this is what the rest of the
documentation predominantly uses. (Note, the formatting can be very basic, it's
the format that I care about.)
Otherwise, great to see this addition!
https://reviews.llvm.org/D36737
_
zaks.anna added inline comments.
Comment at: lib/StaticAnalyzer/Core/AnalyzerOptions.cpp:190
+ /* Default = */ false);
+ return shouldUnrollLoops() || explicitlyIncludeLoopExit;
}
I would rather keep this method
zaks.anna added inline comments.
Comment at: lib/StaticAnalyzer/Core/SValBuilder.cpp:364
if (symLHS && symRHS &&
- (symLHS->computeComplexity() + symRHS->computeComplexity()) < MaxComp)
+ (symLHS->computeComplexity() + symRHS->computeComplexity()) < MaxComp)
re
zaks.anna added a comment.
Is this blocked on the same reasons as what was raised in
https://reviews.llvm.org/D35109?
https://reviews.llvm.org/D35110
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/list
zaks.anna added a comment.
> But I've never used the taint tracking mode, so I don't know what would be a
> reasonable default for MaxComp.
that one is very experimental anyway. I'd just keep the functional changes to
tain out of this patch and use the current default that taint uses.
https:/
zaks.anna added a comment.
Thanks for addressing the non-determinism!!!
The ExplodedNodeSet is predominantly used to hold very small sets and it is
used quite a bit in the analyzer. Maybe we could we use SmallSetVector here
instead?
https://reviews.llvm.org/D37400
_
zaks.anna accepted this revision.
zaks.anna added a comment.
This revision is now accepted and ready to land.
Thank you!
Anna
https://reviews.llvm.org/D37400
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailm
zaks.anna added a comment.
How about committing the refactor of the code without test modifications. And
committing changes to the test separately?
https://reviews.llvm.org/D37809
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists
zaks.anna added inline comments.
Comment at: lib/StaticAnalyzer/Checkers/PthreadLockChecker.cpp:271
}
-assert(lockFail && lockSucc);
-C.addTransition(lockFail);
-
+// We might want to handle the case when the mutex lock function was
inlined
+// and returned
zaks.anna accepted this revision.
zaks.anna added a comment.
This revision is now accepted and ready to land.
LGTM.
Thanks!
I was wondering if there are other places where this propagation needs to be
added, for example, other calls to GenerateBlockFunction.
https://reviews.llvm.org/D40668
zaks.anna added a comment.
>> I tried to keep this as a minimal starting example because this currently
>> blocks @yamaguchi 's GSoC project for bash completion. There we want to
>> complete the values for -analyzer-config and we currently don't have a good
>> way to get a complete list of av
zaks.anna added a comment.
> What do you suggest? Should we widen the type of the difference, or abandon
> this patch and revert back to the local solution I originally used in the
> iterator checker?
Does the local solution you used in the iterator checker not have the same
problem?
https:/
zaks.anna added inline comments.
Comment at: lib/StaticAnalyzer/Checkers/OStreamFormatChecker.cpp:513
+
+bool OStreamFormatChecker::evalCall(const CallExpr *CE,
+CheckerContext &C) const {
gamesh411 wrote:
> NoQ wrote:
> > One
zaks.anna accepted this revision.
zaks.anna added a comment.
This revision is now accepted and ready to land.
Looks like @NoQ wetted the remaining code changes. The rest LGTM.
Thank you for preparing the patch!
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.l
zaks.anna added a comment.
Please, commit.
https://reviews.llvm.org/D38674
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
zaks.anna added a comment.
Just to be clear, since this leads to regression to the checker API, I am
asking to look into other ways of solving this problem. For example, is there a
way to ensure that the checker names are set at construction?
https://reviews.llvm.org/D37437
zaks.anna added a comment.
Please, change the commit description to be more comprehensive.
Comment at: lib/StaticAnalyzer/Checkers/ExprInspectionChecker.cpp:68
// (globals should not be invalidated, etc), hence the use of evalCall.
- FnCheck Handler = llvm::StringSwitch(C.g
zaks.anna accepted this revision.
zaks.anna added a comment.
LGTM!
https://reviews.llvm.org/D38728
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
zaks.anna accepted this revision.
zaks.anna added a comment.
This revision is now accepted and ready to land.
What kind of output will this start displaying?
(I believe currently the script does print the summary of the objects that are
added or deleted.)
https://reviews.llvm.org/D39269
___
zaks.anna added a comment.
I'd also include some info on how it's now possible to dump the issue hash. You
introduce a new debugging function here "clang_analyzer_hashDump" but it's not
mentioned in the commit message.
Thanks!
Comment at: lib/StaticAnalyzer/Checkers/ExprInsp
zaks.anna added a comment.
> Also if you check the code snippets in the coding standard:
> https://llvm.org/docs/CodingStandards.html#beware-unnecessary-copies-with-auto
> you can see that where we officially put the references.
Correct! The reference should not go with the type name.
George, p
zaks.anna created this revision.
I've sent the email to cfg-dev and the community is supportive of this change.
https://reviews.llvm.org/D39964
Files:
CODE_OWNERS.TXT
Index: CODE_OWNERS.TXT
===
--- CODE_OWNERS.TXT
+++ CODE_OWNE
zaks.anna updated this revision to Diff 81429.
zaks.anna added a comment.
Devin did not like the '*' in the diagnostic for ObjC objects, so remove the
'*'.
https://reviews.llvm.org/D27740
Files:
lib/StaticAnalyzer/Checkers/RetainCountChecker.cpp
test/Analysis/edges-new.mm
test/Analysis/i
zaks.anna updated this revision to Diff 81482.
zaks.anna added a comment.
Address Devin's comment regarding 'id'.
https://reviews.llvm.org/D27740
Files:
lib/StaticAnalyzer/Checkers/RetainCountChecker.cpp
test/Analysis/edges-new.mm
test/Analysis/inlining/path-notes.m
test/Analysis/objc-a
zaks.anna added a comment.
> Did you checked if same warnings may be emitted by another checkers? For
> example,
> ArrayBoundChecker may warn if index is tainted.
I second that. The GenericTaintChecker also reports uses of tainted values. It
is not clear that we should add a new separate chec
zaks.anna added a comment.
> I am doing it right now. Unfortunately I found a crash which I fixed,
Is it fixed in this patch?
> but then it turned out that overwrites of the iterator variable are not
> handled. I am working on this
> problem.
My suggestion is to commit this patch and address
zaks.anna added a comment.
And thank you for the awesome work and addressing the review comments!!!
https://reviews.llvm.org/D25660
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
zaks.anna added a comment.
Are there any negative effects from having the duplicates in edges?
When does this occur? It's a bit suspicious since we have a FromN, and a path
is split at that node, resulting in successors that are the same. Is it
possible that whoever split the state did not enco
zaks.anna added a comment.
Looks great overall. I have minor comments below. Thanks for the awesome
comments!!!
Comment at: lib/StaticAnalyzer/Checkers/GTestChecker.cpp:152
+
+ ProgramStateRef State = C.getState();
+
This could be moved up as you are using th
zaks.anna added a comment.
To deal with non-determinism, you can sort the results by non-pointer values,
such as identifiers, before producing the warnings.
It is not clear if you want to print all warnings or only the first one. Is it
an option to list all dead symbols in one warning message?
zaks.anna added a comment.
If this is a common mistake for checker writers, we could consider adding
assertions that check for this situation. We should make sure that we do not to
add any release builds overhead. Maybe we could put this check behind NDEBUG or
ensure that whatever code is added
zaks.anna created this revision.
zaks.anna added a reviewer: dcoughlin.
zaks.anna added subscribers: cfe-commits, dergachev.a.
The checker has several false positives that this patch addresses:
1. Do not check if the return status has been compared to error (or no error)
at the time when leaks
zaks.anna updated this revision to Diff 83160.
zaks.anna added a comment.
Addressed all comments
https://reviews.llvm.org/D28330
Files:
lib/StaticAnalyzer/Checkers/MacOSKeychainAPIChecker.cpp
test/Analysis/keychainAPI.m
Index: test/Analysis/keychainAPI.m
===
zaks.anna added a comment.
Thanks for the patch!
Could you, please, resubmit the patch with context as described here
http://llvm.org/docs/Phabricator.html
Also, please, add tests. See test/Analysis/ for examples.
Repository:
rL LLVM
https://reviews.llvm.org/D28348
__
zaks.anna added a comment.
I did not think of solution #1! It's definitely better than the pattern
matching I've added here. However, this checker fires so infrequently, that I
do not think it's worth investing more time into perfecting it.
I suspect the solution #2 is what this checker was try
zaks.anna created this revision.
zaks.anna added a reviewer: kubabrecka.
zaks.anna added a subscriber: cfe-commits.
There is a synchronization point between the reference count of a block
dropping to zero and it's destruction, which TSan does not observe. Do not
report errors in the compiler-emi
zaks.anna added a comment.
Phabricator still says that context is not available. Please, pass -U when
generating the patch.
Thanks!
Anna
Comment at: test/Analysis/gmalloc.c:1
+// RUN: %clang_cc1 -analyze
-analyzer-checker=core,alpha.deadcode.UnreachableCode,alpha.core.Ca
zaks.anna added a comment.
Thanks for working on this!
Comment at: lib/StaticAnalyzer/Checkers/GenericTaintChecker.cpp:443
+ if (auto LCV = Val.getAs())
+return C.getSymbolManager().getRegionValueSymbol(LCV->getRegion());
+
This might create a new symbol.
zaks.anna created this revision.
zaks.anna added reviewers: dergachev.a, dcoughlin.
zaks.anna added a subscriber: cfe-commits.
https://reviews.llvm.org/D28495
Files:
lib/StaticAnalyzer/Core/CallEvent.cpp
test/Analysis/inlining/InlineObjCClassMethod.m
Index: test/Analysis/inlining/InlineObjCC
zaks.anna added a comment.
Please, subscribe cfe-commits list on the patches as described in
http://llvm.org/docs/Phabricator.html.
Thanks!
Anna
Repository:
rL LLVM
https://reviews.llvm.org/D28297
___
cfe-commits mailing list
cfe-commits@lists.
zaks.anna added a comment.
Are there other cases where makeNull would need to be replaced?
Repository:
rL LLVM
https://reviews.llvm.org/D31029
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/
zaks.anna added inline comments.
Comment at: include/clang/StaticAnalyzer/Core/PathSensitive/CheckerHelpers.h:46
-} // end GR namespace
+bool isExprResultConformsComparisonRule(CheckerContext &C,
+BinaryOperatorKind CompRule,
zaks.anna added a comment.
Thanks!!!
Comment at: lib/StaticAnalyzer/Core/BugReporterVisitors.cpp:965
+
+// Performing operator `&' on an lvalue expression is essentially a no-op.
+// Then, if we are taking addresses of fields or elements, these are also
zaks.anna accepted this revision.
zaks.anna added a comment.
This revision is now accepted and ready to land.
This needs to be committed.
https://reviews.llvm.org/D27090
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/c
zaks.anna accepted this revision.
zaks.anna added a comment.
This revision is now accepted and ready to land.
This is done.
https://reviews.llvm.org/D27773
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman
zaks.anna added inline comments.
Comment at: lib/StaticAnalyzer/Checkers/MallocChecker.cpp:810
+if (CE->getNumArgs() == 2)
+ State = ProcessZeroAllocation(C, CE, 1, State);
} else if (CE->getNumArgs() == 3) {
Why did you remove the old beh
zaks.anna added a comment.
I think it's more valuable to report a warning here even if the error message
is not very precise. Marking something as in bounds when we know it's not does
not feel right and could lead to inconsistent states down the road.
Repository:
rL LLVM
https://reviews.llv
zaks.anna added a comment.
From what I recall, it is not clear that this patch is the step in the right
direction. At least, it need more investigation.
https://reviews.llvm.org/D27202
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://
zaks.anna added a comment.
> It is not supported to run the analyzer with some of the core checkers turned
> off.
Correct.
> Maybe we should change the behavior such that turning off core checkers turn
> off the warnings from those checkers but not the checkers themselves?
Having this as the
zaks.anna added a comment.
Thanks for working on this Dominic!!!
Can you talk a bit about your motivation for working on this project and what
your goals are?
Have you compared the performance when using Z3 vs the current builtin solver?
I saw that you mention performance issues on large codeb
zaks.anna added a comment.
The static analyzer is definitely the place to go for bug detection that
requires path sensitivity. It's also reasonably good for anything that needs
flow-sensitivity. Although, most flow-sensitive analysis (such as liveness) now
live in lib/Analysis/, which is used b
zaks.anna added a comment.
Before clang-tidy came into existence the guidelines were very clear. One
should write a clang warning if the diagnostic:
- can be implemented without path-insensitive analysis (including
flow-sensitive)
- is checking for language rules (not specific API misuse)
In m
zaks.anna added a comment.
> I tried to come up with some advice on where checks should go in
> http://clang.llvm.org/extra/clang-tidy/#choosing-the-right-place-for-your-check
The guidelines stated on the clang-tidy page seem reasonable to me.
> For example, IMO, AST-based analyses make more se
zaks.anna added a comment.
> @dcoughlin As a reviewer of both patches - could you tell us what's the
> difference between them? And how are we going to resolve this issue?
Unfortunately, @dcoughlin is on vacation this week; should be back next week.
Repository:
rL LLVM
https://reviews.llvm.
zaks.anna added a comment.
I agree that we should not print the values of all variables. The users will be
overwhelmed with the huge amount of information. It is very valuable to
highlight just the right information. (I believe even the current diagnostics
often produce too much info and highli
zaks.anna added a comment.
@xazax.hun,
Can we move this out of alpha?
Have this checkers been tested on a large codebase? What are false positive
rates?
Thanks!
Anna
Repository:
rL LLVM
https://reviews.llvm.org/D15227
___
cfe-commits mailing
zaks.anna added a comment.
Please, make sure future reviews go through cfg-dev list. See
http://llvm.org/docs/Phabricator.html.
Repository:
rL LLVM
https://reviews.llvm.org/D28297
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://li
zaks.anna added a comment.
Does the code you added detects array out of bounds cases without false
positives? Is it an option to just have this checkers produce a more precise
error message in the specific case.
A lot of work will probably need to be done to implement a proper array out of
bou
zaks.anna added a comment.
> In this checker, I give warnings for values which are both tainted and were
> also not checked by the programmer. So unlike GenericTaintChecker, I do
> implement the boundedness check here for certain, interesting constructs
> (which is controlled by the critical op
zaks.anna added inline comments.
Comment at: lib/StaticAnalyzer/Checkers/MallocChecker.cpp:885
+return;
+ State = MallocMemAux(C, CE, CE->getArg(0), UndefinedVal(), State);
+ State = ProcessZeroAllocation(C, CE, 0, State);
I am not sure this is
zaks.anna accepted this revision.
zaks.anna added a comment.
This revision is now accepted and ready to land.
Looks good. Thank you for catching this!
Do you have commit access or should I commit on your behalf?
https://reviews.llvm.org/D29643
___
zaks.anna added a comment.
Has this been cherry-picked into the clang 4.0 release branch? If not, we
should definitely do that!
Repository:
rL LLVM
https://reviews.llvm.org/D29303
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://li
zaks.anna added a comment.
> But as far as I remember, this produced false negatives in the tests not
> false positives.
Could you double check that? Maybe you still have some notes in your mail box
or just by looking at the code.
Did none of the checks work or just some of them?
Also, whic
zaks.anna added a comment.
Could you please split the patch into two - one with the previously reviewed
support for functions that take a single size value and another patch that
models the two size arguments (num and size). It's easier to review patches if
they do not grow new functionality. S
zaks.anna added inline comments.
Comment at: lib/StaticAnalyzer/Checkers/UndefResultChecker.cpp:76
if (Ex) {
+ bool ArrayIndexOutOfBounds = false;
+ if (isa(Ex)) {
Please, pull this out into a sub-rutine. Thanks!
https://reviews.llvm.org/D28278
zaks.anna added a comment.
I agree this can clarify the error message quite a bit!
Comment at: lib/StaticAnalyzer/Checkers/CallAndMessageChecker.cpp:160
if (ParamDecl->getType()->isPointerType()) {
-Message = "Function call argument is a pointer to uninitialized value";
zaks.anna accepted this revision.
zaks.anna added a comment.
This revision is now accepted and ready to land.
Looks great!
https://reviews.llvm.org/D30289
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/
zaks.anna added a comment.
> So it would be a wast of resources to duplicate these data. So now I am
> also working on the merged version.
Would it make sense to just resume the review on the merged patch?
https://reviews.llvm.org/D29419
___
cfe
zaks.anna added a comment.
> Firstly I uploaded Glib-MallocChecker-single-size-value.patch for code
> review, if submitted to UPSTREAM, then upload another one, correct?
Yes. By the way, you can model XXX_n variants similarly to how calloc is
modeled (see CallocMem).
Comment
zaks.anna accepted this revision.
zaks.anna added a comment.
This revision is now accepted and ready to land.
Thank you!
Repository:
rL LLVM
https://reviews.llvm.org/D28278
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm
zaks.anna added a comment.
No multi-file support is a long outstanding limitation of scan-build html
output. Great to see the patch!! Thank you for working on it!
> It's not as immediately clear this is a multi-file output.
In addition to Artem's suggestions, you might want to insert multiple
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
https://r
1 - 100 of 162 matches
Mail list logo
