Skip to content

Fixed issue #128882: don't warn if 1st argument to 'getcwd' is NULL #135720

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.

Sign up for GitHub

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

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Fixed issue #128882: don't warn if 1st argument to 'getcwd' is NULL #135720

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 0 additions & 1 deletion clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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(
Expand Down
3 changes: 0 additions & 3 deletions clang/test/Analysis/errno-stdlibraryfunctions.c
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -105,9 +105,6 @@ void errno_getcwd(char *Buf, size_t Sz) {
clang_analyzer_eval(errno != 0); // expected-warning{{TRUE}}
clang_analyzer_eval(Path == NULL); // expected-warning{{TRUE}}
if (errno) {} // no warning
} else if (Path == NULL) {
clang_analyzer_eval(errno != 0); // expected-warning{{TRUE}}
if (errno) {} // no warning
Comment on lines -108 to -110
Copy link
Contributor

Choose a reason for hiding this comment

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

Why did you drop this branch?

Copy link
Author

@seanm seanm Apr 17, 2025 •
edited
Loading

Choose a reason for hiding this comment

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

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...

Copy link
Contributor

Choose a reason for hiding this comment

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

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?

Copy link
Author

Choose a reason for hiding this comment

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

Does the github CI delete previous results after I updated the PR? I can't find it here anymore...

Copy link
Contributor

Choose a reason for hiding this comment

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

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

--

Copy link
Contributor

Choose a reason for hiding this comment

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

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.

Copy link
Author

Choose a reason for hiding this comment

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

Hmm, frankly, I do not follow. Seems this is a case where fixing the tests is harder than fixing the actual bug.

Copy link
Contributor

Choose a reason for hiding this comment

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

Ping @balazske

Copy link
Collaborator

Choose a reason for hiding this comment

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

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.

Copy link
Author

Choose a reason for hiding this comment

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

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.

} else {
clang_analyzer_eval(Path == Buf); // expected-warning{{TRUE}}
if (errno) {} // expected-warning{{An undefined value may be read from 'errno'}}
Expand Down
Loading