================
@@ -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
----------------
steakhal wrote:
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 `ReturnValueCondition`s for a summary? I have something
like `ReturnValueCondition(BO_NE, SingleValue(0))` in mind to add there.
https://github.com/llvm/llvm-project/pull/135720
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
