[PATCH] D97699: [analyzer] Add InvalidPtrChecker

[Csaba Dabis via Phabricator via cfe-commits]

Charusso added a comment.

In D97699#2601804 <https://reviews.llvm.org/D97699#2601804>, @NoQ wrote:

> Why are you even tracking `reg_$0<envp>`? It's obvious from the structure of the symbol that it's an environment pointer, there's no need to keep it in maps.

`envp` is confusable with `argv`: `int main(int argc, char *argv[], char *envp[])` so we obtain `envp`'s region from `main()` to match it later.



================
Comment at: clang/docs/analyzer/checkers.rst:2103-2104
+        puts(envp[i]);
+        // envp may no longer point to the current environment
+        // this program has unanticipated behavior.
+      }
----------------
NoQ wrote:
> It's very important to explain whether the "unanticipated behavior" is an entirely psychological concept ("most people don't understand how this works but this can occasionally also be a valid solution if you know what you're doing") or a 100% clear indication of a bug ("such code can never be correct", eg. it instantly causes undefined behavior, or the written value can never be read later so there's absolutely no point in writing it, or something like that).
The standard terminology is very vague, like that:
```
The getenv function returns a pointer to a string associated with the matched list member. The string pointed to shall not be modified by the program but may be overwritten by a subsequent call to the getenv function.
```
What the hell. 😕  I think it is about table-doubling and reallocating the entire environment pointer table at some point which makes sense in case of the non-getter function calls. For the getters I think another processes could overwrite the `environ` pointer between two getter calls and problem could occur because of such table-doubling. To resolve the issue we need to call `strdup()` and create a copy of the current environment entry instead of having a pointer to it as I see.

@zukatsinadze it would be great to see a real reference with real issues in real world software. Is the true evil the multiple chained getter calls?



Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D97699/new/

https://reviews.llvm.org/D97699