Skip to content

[analyzer] Assert Callee is FunctionDecl in doesFnIntendToHandleOwnership() #101066

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 1 commit into from

Conversation

smanna12
Copy link
Contributor

@smanna12 smanna12 commented Jul 29, 2024

This patch replaces dyn_cast<> with cast<> for converting Callee to FunctionDecl, asserting non-null assumption to prevent undefined behavior due to null dereferences, reported by static analyzer tool and enforces the invariant that Callee must be a valid FunctionDecl.

…ship()

This patch replaces dyn_cast<> with cast<> for converting Callee to FunctionDecl, asserting non-null assumption to prevent undefined behavior due to null dereferences and enforces the invariant that Callee must be a valid FunctionDecl.
@smanna12 smanna12 requested a review from Szelethus July 29, 2024 19:00
@smanna12 smanna12 changed the title [analyzer] Assert Callee is FunctionDecl in doesFnIntendToHandleOwner… [analyzer] Assert Callee is FunctionDecl in doesFnIntendToHandleOwnership() Jul 29, 2024
@smanna12 smanna12 marked this pull request as ready for review July 29, 2024 19:00
@llvmbot llvmbot added clang Clang issues not falling into any other category clang:static analyzer labels Jul 29, 2024
@llvmbot
Copy link
Member

llvmbot commented Jul 29, 2024

@llvm/pr-subscribers-clang-static-analyzer-1

Author: None (smanna12)

Changes

This patch replaces dyn_cast<> with cast<> for converting Callee to FunctionDecl, asserting non-null assumption to prevent undefined behavior due to null dereferences and enforces the invariant that Callee must be a valid FunctionDecl.


Full diff: https://github.com/llvm/llvm-project/pull/101066.diff

1 Files Affected:

  • (modified) clang/lib/StaticAnalyzer/Checkers/StreamChecker.cpp (+1-1)
diff --git a/clang/lib/StaticAnalyzer/Checkers/StreamChecker.cpp b/clang/lib/StaticAnalyzer/Checkers/StreamChecker.cpp
index 4454f30630e27..534aa147aefb0 100644
--- a/clang/lib/StaticAnalyzer/Checkers/StreamChecker.cpp
+++ b/clang/lib/StaticAnalyzer/Checkers/StreamChecker.cpp
@@ -756,7 +756,7 @@ class NoStreamStateChangeVisitor final : public NoOwnershipChangeVisitor {
   bool doesFnIntendToHandleOwnership(const Decl *Callee,
                                      ASTContext &ACtx) final {
     using namespace clang::ast_matchers;
-    const FunctionDecl *FD = dyn_cast<FunctionDecl>(Callee);
+    const FunctionDecl *FD = cast<FunctionDecl>(Callee);
 
     auto Matches =
         match(findAll(callExpr().bind("call")), *FD->getBody(), ACtx);

@llvmbot
Copy link
Member

llvmbot commented Jul 29, 2024

@llvm/pr-subscribers-clang

Author: None (smanna12)

Changes

This patch replaces dyn_cast<> with cast<> for converting Callee to FunctionDecl, asserting non-null assumption to prevent undefined behavior due to null dereferences and enforces the invariant that Callee must be a valid FunctionDecl.


Full diff: https://github.com/llvm/llvm-project/pull/101066.diff

1 Files Affected:

  • (modified) clang/lib/StaticAnalyzer/Checkers/StreamChecker.cpp (+1-1)
diff --git a/clang/lib/StaticAnalyzer/Checkers/StreamChecker.cpp b/clang/lib/StaticAnalyzer/Checkers/StreamChecker.cpp
index 4454f30630e27..534aa147aefb0 100644
--- a/clang/lib/StaticAnalyzer/Checkers/StreamChecker.cpp
+++ b/clang/lib/StaticAnalyzer/Checkers/StreamChecker.cpp
@@ -756,7 +756,7 @@ class NoStreamStateChangeVisitor final : public NoOwnershipChangeVisitor {
   bool doesFnIntendToHandleOwnership(const Decl *Callee,
                                      ASTContext &ACtx) final {
     using namespace clang::ast_matchers;
-    const FunctionDecl *FD = dyn_cast<FunctionDecl>(Callee);
+    const FunctionDecl *FD = cast<FunctionDecl>(Callee);
 
     auto Matches =
         match(findAll(callExpr().bind("call")), *FD->getBody(), ACtx);

@steakhal
Copy link
Contributor

If this function only cares about FunctionDecls, why does it accept a generic Decl? I'd prefer a clear interface instead.

BTW, what does prevent a BlockDecl from taking ownership?

Copy link
Contributor

@Szelethus Szelethus left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Already under fix in #100719, I'm just a lazy bum and haven't fixed the buildbots. I'll try to speed things up!

@smanna12 smanna12 closed this Jul 30, 2024
@smanna12 smanna12 deleted the FixnullStaticbug branch July 30, 2024 14:30
@smanna12
Copy link
Contributor Author

Already under fix in #100719, I'm just a lazy bum and haven't fixed the buildbots. I'll try to speed things up!

Thanks for reviews. Closing this JIRA

@smanna12
Copy link
Contributor Author

smanna12 commented Aug 1, 2024

Already under fix in #100719, I'm just a lazy bum and haven't fixed the buildbots. I'll try to speed things up!

@Szelethus, would it possible to speed up the PR#100719? Thanks

@steakhal
Copy link
Contributor

steakhal commented Aug 1, 2024

Already under fix in #100719, I'm just a lazy bum and haven't fixed the buildbots. I'll try to speed things up!

@Szelethus, would it possible to speed up the PR#100719? Thanks

Why?

@smanna12
Copy link
Contributor Author

smanna12 commented Aug 1, 2024

Already under fix in #100719, I'm just a lazy bum and haven't fixed the buildbots. I'll try to speed things up!

@Szelethus, would it possible to speed up the PR#100719? Thanks

Why?

It impacts our scan with static analyzer tool.

@steakhal
Copy link
Contributor

steakhal commented Aug 1, 2024

Already under fix in #100719, I'm just a lazy bum and haven't fixed the buildbots. I'll try to speed things up!

@Szelethus, would it possible to speed up the PR#100719? Thanks

Why?

It impacts our scan with static analyzer tool.

I see. In that case I think it makes sense to mark that report in your tool as a true-positive, and it will be eventually fixed. Probably pretty soon, but I don't want to speak for Husi, as he might be on vacation. If it's urgent, a downstream patch should be always an option, but I don't think this issue would justify one - at least it wouldn't for me.

@Szelethus
Copy link
Contributor

Just landed the patch, sorry for the slack!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
clang:static analyzer clang Clang issues not falling into any other category
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants