This is an archive of the discontinued LLVM Phabricator instance.

[PATCH] Github Issue: Create a check that warns about using %p printf specifier #43453
Needs RevisionPublic

Authored by giannicrivello on Dec 7 2022, 10:32 PM.

Details

Summary

Patched llvm-project/clang/lib/StaticAnalyzer/Checkers/UnixAPIChecker.cpp to account for the user passing a nullptr to the implementation dependent function printf(). Invoked with bin/scan-build -enable-checker optin.portability bin/clang -g test.cpp where the contents of test.cpp is:

c++
#include <stdio.h>
#include <stdlib.h>

int main() {
    int *p = nullptr;
    printf("%p", p);
}

now produces the warning:

test.cpp:6:5: warning: Passing a null pointer to printf() is implementation dependant. Portability warning [optin.portability.UnixAPI]
    printf("%p", p);
    ^~~~~~~~~~~~~~~
1 warning generated.

Diff Detail

Event Timeline

giannicrivello created this revision.Dec 7 2022, 10:32 PM
Herald added projects: Restricted Project, Restricted Project. · View Herald Transcript
giannicrivello requested review of this revision.Dec 7 2022, 10:32 PM
clementval removed a project: Restricted Project.Dec 7 2022, 11:35 PM
steakhal requested changes to this revision.Dec 16 2022, 6:23 AM

I appreciate that you are interested in tackling this. I do think it's a low-hanging fruit, so it's a good choice!

However, there are a couple of things we need to improve before we could proceed:

  1. Add tests demonstrating all possible aspects of your change.
  2. Generally, one should check preconditions in the Pre checker callbacks, and apply postconditions (effects) in Post checker callbacks.
  3. We should have a specific BugType pointer for the specific bug you hunt - in other words you should not reuse BT_mallocZero for your checker.
  4. One should be able to disable your rule in case something goes wild. So, your checker should be registered at the end of the file by applying the REGISTER_CHECKER() macro.
  5. One should update the documentation and also mention the new check in the release docs to give visibility.
  6. For matching if a function is interesting or not, you should use CallDescriptions instead of looking at the IdentifierInfo directly - unless there are other cases in the scope where we don't use this facility. However, for those case we should consider updating those to use CallDescriptionSet|Map.
  7. I can see that you directly use the isZeroConstant() on the value of the pointer. This might not work for all cases, e.g. when the pointer is symbolic. In that case, we might be able to prove that the pointer should be null, because the path-constraints we collected so far imply that.

Thanks for improving the detection!

This revision now requires changes to proceed.Dec 16 2022, 6:23 AM