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.
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.
There was a problem hiding this comment.
The correct fix would be probably to add ArgumentConditions for the parameter 0 to be non-null in the existing "Case"-s, and add extra cases for the buf == NULL condition (where size is ignored but the return value can be still NULL on error or non-NULL on success).
No description provided.