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
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
