This is an archive of the discontinued LLVM Phabricator instance.

[analyzer] clarify error messages about uninitialized function arguments
ClosedPublic

Authored by danielmarjamaki on Feb 24 2017, 8:45 AM.

Details

Summary

This patch clarify the error messages about uninitialized function arguments.

It can be really hard to see the problem if there are 10-20 arguments like:

printf("debug:....", a, b.c, d, e, ...);

with no info about which argument is uninitialized and with a complicated path to investigate it's hard to see the bug.

Diff Detail

Repository
rL LLVM

Event Timeline

zaks.anna edited edge metadata.Feb 24 2017, 9:53 PM

I agree this can clarify the error message quite a bit!

lib/StaticAnalyzer/Checkers/CallAndMessageChecker.cpp
160 ↗(On Diff #89677)

Let's use llvm::getOrdinalSuffix() so that we write "1st argument" instead of "argument number '1'".

211 ↗(On Diff #89677)

Have you considered using llvm::raw_svector_ostream here as well as passing it an argument to describeUninitializedArgumentInCall? For example, see MallocChecker.cpp.

minor updates. Use llvm::getOrdinalNumber(). Use llvm::Twine.

danielmarjamaki marked an inline comment as done.Feb 28 2017, 7:35 AM
danielmarjamaki added inline comments.
lib/StaticAnalyzer/Checkers/CallAndMessageChecker.cpp
211 ↗(On Diff #89677)

I changed so describeUninitializedArgumentInCall() returns an llvm::Twine instead of std::string. hope you like it.

zaks.anna added inline comments.Mar 1 2017, 1:32 PM
lib/StaticAnalyzer/Checkers/CallAndMessageChecker.cpp
211 ↗(On Diff #89677)

I do not think it's safe to use llvm:Twine here. See http://llvm.org/docs/ProgrammersManual.html#the-twine-class

How about using llvm::raw_svector_ostream as I suggested?

danielmarjamaki added inline comments.Mar 2 2017, 2:27 PM
lib/StaticAnalyzer/Checkers/CallAndMessageChecker.cpp
211 ↗(On Diff #89677)

sure I can use llvm::raw_svector_ostream instead. I can try to update the patch soon.

I just wonder how it is unsafe. I did consider if llvm::Twine would be safe. Is there a particular return that you can point out? The function mostly returns constant string literals. Those should be safe right? Then the function also have a few returns like this:

return llvm::Twine(ArgumentNumber + 1) +
           llvm::getOrdinalSuffix(ArgumentNumber + 1) +
           " function call argument is an uninitialized value";

Yes we need to be careful for such code. However since llvm::getOrdinalSuffix() returns a StringRef this particular code should be safe right?

When the stream is used I have to tweak each return statement. I thought that was a bit unfortunate. But it's not a biggie.

danielmarjamaki added inline comments.Mar 2 2017, 4:00 PM
lib/StaticAnalyzer/Checkers/CallAndMessageChecker.cpp
211 ↗(On Diff #89677)

After some more reading in the llvm::Twine docs I am also thinking that I misuse it. so I will change the code.

Fix review comment

danielmarjamaki marked 2 inline comments as done.Mar 3 2017, 6:30 AM
NoQ edited edge metadata.Mar 3 2017, 2:45 PM

The code looks good to me, but i'm expressing a tiny doubt: regardless of the output format, the user always has the relevant argument highlighted anyway (column number, tilde-underlined in command line, blue-ish box in scan-build, etc.), so the only significant clarification i see is on test files, where the column is not obvious.

If having that information duplicated to the warning message is considered useful (easier to read, catchy), i'm ok with it :)

The definitive document on this debate is https://clang.llvm.org/diagnostics.html : it begins with explicitly encouraging highlights through column numbers and underlines, but it doesn't provide an opinion on including this info in the warning message. So i'm confused.

No the argument is not shown with tilde/column number.

Code example:

void f(int x, ...);

void dostuff() {
  int x[10];
  f(12,3,4,5,x[3],6,7,8);
}

Output:

C:\Users\danielm>\llvm\build\Debug\bin\clang -cc1 -analyze -analyzer-checker=core test3.c
test3.c:6:3: warning: Function call argument is an uninitialized value
  f(12,3,4,5,x[3],6,7,8);
  ^~~~~~~~~~~~~~~~~~~~~~
NoQ accepted this revision.Mar 6 2017, 11:52 PM

Oh well, that's not good. Probably that's because we always highlight the current statement in path-sensitive reports. I guess we could improve upon that in the bug reporter.

This revision is now accepted and ready to land.Mar 6 2017, 11:52 PM
This revision was automatically updated to reflect the committed changes.