Fixed issue #128882: don't warn if 1st argument to 'getcwd' is NULL #135720
Conversation
|
Thank you for submitting a Pull Request (PR) to the LLVM Project! This PR will be automatically labeled and the relevant teams will be notified. If you wish to, you can add reviewers by using the "Reviewers" section on this page. If this is not working for you, it is probably because you do not have write permissions for the repository. In which case you can instead tag reviewers by name in a comment by using If you have received no comments on your PR for a week, you can request a review by "ping"ing the PR by adding a comment “Ping”. The common courtesy "ping" rate is once a week. Please remember that you are asking for valuable time from other developers. If you have further questions, they may be answered by the LLVM GitHub User Guide. You can also ask questions in a comment on this PR, on the LLVM Discord or on the forums. |
|
@llvm/pr-subscribers-clang Author: Sean McBride (seanm) ChangesFull diff: https://github.com/llvm/llvm-project/pull/135720.diff 1 Files Affected:
diff --git a/clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp b/clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp
index 9c0b79ab58618..34bab80307a04 100644
--- a/clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp
+++ b/clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp
@@ -2663,7 +2663,6 @@ void StdLibraryFunctionsChecker::initFunctionSummaries(
.Case({ArgumentCondition(1, WithinRange, Range(1, SizeMax)),
IsNull(Ret)},
ErrnoNEZeroIrrelevant, GenericFailureMsg)
- .ArgConstraint(NotNull(ArgNo(0)))
.ArgConstraint(
BufferSize(/*Buffer*/ ArgNo(0), /*BufSize*/ ArgNo(1)))
.ArgConstraint(
|
|
@llvm/pr-subscribers-clang-static-analyzer-1 Author: Sean McBride (seanm) ChangesFull diff: https://github.com/llvm/llvm-project/pull/135720.diff 1 Files Affected:
diff --git a/clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp b/clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp
index 9c0b79ab58618..34bab80307a04 100644
--- a/clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp
+++ b/clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp
@@ -2663,7 +2663,6 @@ void StdLibraryFunctionsChecker::initFunctionSummaries(
.Case({ArgumentCondition(1, WithinRange, Range(1, SizeMax)),
IsNull(Ret)},
ErrnoNEZeroIrrelevant, GenericFailureMsg)
- .ArgConstraint(NotNull(ArgNo(0)))
.ArgConstraint(
BufferSize(/*Buffer*/ ArgNo(0), /*BufSize*/ ArgNo(1)))
.ArgConstraint(
|
| } else if (Path == NULL) { | ||
| clang_analyzer_eval(errno != 0); // expected-warning{{TRUE}} | ||
| if (errno) {} // no warning |
There was a problem hiding this comment.
Why did you drop this branch?
There was a problem hiding this comment.
It caused a build/test warning/error here on github, I was hoping this was the correct fix. But I don't know the llvm codebase at all...
There was a problem hiding this comment.
Alright. I think I understand this now.
Because of ReturnValueCondition(BO_EQ, ArgNo(0)) on the success path we assume that the returned pointer is the same (aka. equal to) the first argument, which means that Path holds the same pointer as Buf.
Because of this, dropping the ArgConstraint(NotNull(ArgNo(0))) means that no longer affects the return value Path. This is actually a good thing.
Could you please help me how does the test failure look like for you if you would keep this hunk?
There was a problem hiding this comment.
Does the github CI delete previous results after I updated the PR? I can't find it here anymore...
There was a problem hiding this comment.
Oh, indeed it was there:
Exit Code: 1
Command Output (stdout):
--
# RUN: at line 1
c:\ws\src\build\bin\clang.exe -cc1 -internal-isystem C:\ws\src\build\lib\clang\21\include -nostdsysteminc -analyze -analyzer-constraints=range -setup-static-analyzer -verify C:\ws\src\clang\test\Analysis\errno-stdlibraryfunctions.c -analyzer-checker=core -analyzer-checker=debug.ExprInspection -analyzer-checker=unix.StdCLibraryFunctions -analyzer-checker=apiModeling.Errno -analyzer-checker=unix.Errno -analyzer-config unix.StdCLibraryFunctions:ModelPOSIX=true
# executed command: 'c:\ws\src\build\bin\clang.exe' -cc1 -internal-isystem 'C:\ws\src\build\lib\clang\21\include' -nostdsysteminc -analyze -analyzer-constraints=range -setup-static-analyzer -verify 'C:\ws\src\clang\test\Analysis\errno-stdlibraryfunctions.c' -analyzer-checker=core -analyzer-checker=debug.ExprInspection -analyzer-checker=unix.StdCLibraryFunctions -analyzer-checker=apiModeling.Errno -analyzer-checker=unix.Errno -analyzer-config unix.StdCLibraryFunctions:ModelPOSIX=true
# .---command stderr------------
# | error: 'expected-warning' diagnostics seen but not expected:
# | File C:\ws\src\clang\test\Analysis\errno-stdlibraryfunctions.c Line 109: FALSE [debug.ExprInspection]
# | 1 error generated.
# `-----------------------------
# error: command failed with exit status: 1
--
There was a problem hiding this comment.
How to interpret this:
So after your patch, now we reach the print statement at line 109 with 2 paths, one in which errno is known to be zero, and also a different path where we know it's not zero. This is why the true expectation is met, but complains about that it also prints false for the same line. I know it's hard to wrap your head around.
Let's step back. What does this test? We are in a branch when Path aka. the result of getcwd is NULL, aka. we had an error. In this case errno should indicate the specific error that happened, which means we should know here that errno is not zero. This is exactly what is enforced by the line 109.
What if on the success path Path is equal to Buf, which is a top-level symbol, thus when compared Path against NULL, we will have a state-split, so we enter this Path == NULL branch even on the success path. This is why errno is known there to be non-zero, hence the new diagnostic.
What is missing I think is a new ReturnValueCondition for the success path constraining the return value NOT being null. @balazske WDYT of this reasoning?
Can we have multiple ReturnValueConditions for a summary? I have something like ReturnValueCondition(BO_NE, SingleValue(0)) in mind to add there.
There was a problem hiding this comment.
Hmm, frankly, I do not follow. Seems this is a case where fixing the tests is harder than fixing the actual bug.
There was a problem hiding this comment.
I checked the issue 128882, it references to the macOS man page for getcwd where a NULL buf argument is allowed. This is different from the original POSIX documentation where "the behavior of getcwd() is unspecified" if buf is NULL. This is why the condition is there. But "unspecified" does not mean invalid, so it may be correct to drop this requirement. But we must check how this affects the BufferSizeConstraint.
There was a problem hiding this comment.
It's not just macOS.
linux's glibc's "allocates the buffer dynamically using malloc if buf is NULL."
And FreeBSD: If buf is NULL, space is allocated as necessary to store the pathname. This space may later be free'd.
No description provided.