1

Suppose you have a code like this:

int* a = (int*) malloc(20);
a[3]=2;
pid_t q = fork();
if(!q) {
    char *a[5];
    for (q=4; ;--q) {
        if(q<0) break;
        a[q]="q";
    }
    execve("q", a, NULL);
}
if(q) kill(q, 9);
free(a);

It builds without any warning with gcc -Wall, clang -Wall, emits no warnings with cppcheck --enable=all.

Hovewer ommitted checking of malloc, fork and execve's return values for errors clearly leads to problems. How do I statically check the C source code for such mistakes?

Vi.
  • 37,014
  • 18
  • 93
  • 148
  • I don't think you can. These are typical runtime errors and `valgrind` might be able to help you. – Bart Friederichs Aug 25 '14 at 19:19
  • Why can't? Many functions have a documented return value in case of error. The static checker can verify if there is an `if` or `?` for the return value immediately following the invocation (or immediately inside the next called function that is also available for the checker) and show a warning if it is not. – Vi. Aug 25 '14 at 19:21
  • Okay, I guess it would be possible, but I have never heard of a tool that could do it. – Bart Friederichs Aug 25 '14 at 19:25
  • Maybe you can write your own! – Al.Sal Aug 25 '14 at 19:50
  • @Al.Sal, What's the easiest way to do it? A clang plugin? – Vi. Aug 25 '14 at 20:12
  • there is a clang tool that tries to do this sort of thing. http://clang-analyzer.llvm.org/ Never used it, so I'm not sure how well it works. – genisage Aug 25 '14 at 20:17
  • @genisage, Found `scan-build/c++-analyzer` in Android NDK package. When building, it only complains about `deprecated conversion from string constant to 'char*'` after malloc, otherwise showing `scan-build: No bugs found.`... – Vi. Aug 25 '14 at 21:03
  • @Vi. That's too bad, maybe you can write an extension to add the features you're looking for. – genisage Aug 25 '14 at 21:05
  • @FUZxxl, But it makes the code more C++-friendly (no warning is shown). – Vi. Aug 25 '14 at 21:08

3 Answers3

2

On failing to find a specialized solution I would turn to find and grep to search for each call to malloc, and any other function you deem important to check the return values of. I'd go through each one at a time and use my eyes to quickly scan the results.

find . -type f -name '*.[ch]*' -exec grep -HnA2 'malloc' {}  \; 

Increase the A2 passed to grep to A3 if you suspect more than two lines of trailing context would be better for catching the return value tests.

James Morris
  • 4,867
  • 3
  • 32
  • 51
  • Too low-tech: 1. requires manual work. If I manually check more than N cases, I stop being attentive; 2. It fails to notice things hidden behind macros or with unusual formatting; 3. It works only about when you know about a pitfall for the specific function. I expect the solution to contain database of known library functions that can catch thing that I personally don't know yet. – Vi. Aug 25 '14 at 21:05
  • Fair enough, am not unsurprised, but sometimes it's got to be done. – James Morris Aug 25 '14 at 21:06
1

I develop Cppcheck

If Cppcheck warned for every missing NULL pointer check after malloc it would write false positives. Some/most people assume/know that there will never be out-of-memory so the return value from malloc is not checked by design.

I do believe it would be useful for some people to have a checker for this. If anybody would like to have this in Cppcheck .. I am against putting this inside Cppcheck itself. I would suggest writing a addon (script) or rule (regular expression) instead. I could add it in the repository. Then those who wants this could use that addon/rule.

Daniel Marjamäki
  • 2,907
  • 15
  • 16
  • So Cppcheck can be extected to comprehend `unistd.h` functions? – Vi. Aug 26 '14 at 12:11
  • Yes. If you need this particular check I suggest that you use a rule or addon. But it is also possible to extend Cppcheck by tweaking cfg files - many of the internal Cppcheck checkers need knowledge about various functions etc to know what happens. This knowledge is not hardcoded, it is taken from xml files that users can tweak. – Daniel Marjamäki Aug 26 '14 at 12:55
  • I suggest that you read the "Writing rules" article that you can download here: http://sourceforge.net/projects/cppcheck/files/Articles/ if you think that rules are not enough, you can write an addon instead. Addons are more powerful, you have access to tokenlist+ast+valueflow, however there is no documentation for writing addons yet. – Daniel Marjamäki Aug 26 '14 at 12:56
0

So you want to check your source code against your (implicit) coding rules. I assume you compile with a recent gcc compiler ...

If the source code is large, it might make sense to write your own GCC extensions in MELT which is a domain specific language and plugin to extend GCC. However that requires some (weeks of) work.

Basile Starynkevitch
  • 223,805
  • 18
  • 296
  • 547