[clang] [analyzer][clangsa] Add new option to alpha.security.cert.InvalidPtrChecker (PR #67663)

[via cfe-commits]

Endre =?utf-8?q?Fülöp?= <endre.fulop at sigmatechnology.se>,
Endre =?utf-8?q?Fülöp?= <endre.fulop at sigmatechnology.se>,
Endre =?utf-8?q?Fülöp?= <endre.fulop at sigmatechnology.se>,
Endre =?utf-8?q?Fülöp?= <endre.fulop at sigmatechnology.se>,
Endre =?utf-8?q?Fülöp?= <endre.fulop at sigmatechnology.se>,
Endre =?utf-8?q?Fülöp?= <endre.fulop at sigmatechnology.se>
Message-ID:
In-Reply-To: <llvm/llvm-project/pull/67663/clang at github.com>


================
@@ -2399,13 +2399,34 @@ pointer. These functions include: getenv, localeconv, asctime, setlocale, strerr
     char *p, *pp;
 
     p = getenv("VAR");
-    pp = getenv("VAR2");
-    // subsequent call to 'getenv' invalidated previous one
+    setenv("SOMEVAR", "VALUE", /*overwrite*/1);
+    // call to 'setenv' may invalidate p
 
     *p;
     // dereferencing invalid pointer
   }
 
+
+The ``InvalidatingGetEnv`` option is available for treating getenv calls as
+invalidating. When enabled, the checker issues a warning if getenv is called
+multiple times and their results are used without first creating a copy.
+This level of strictness might be considered overly pedantic for a standard
+getenv implementation.
----------------
DonatNagyE wrote:

```suggestion
This level of strictness might be considered overly pedantic for the commonly
used getenv implementations.
```
The adjective "standard" sounds like you're talking about standard-compliant implementations; which is a misleading association in this context. (It _is_ standard-compliant to have an invalidating `getenv`; you only want to claim that it's unusual in current environments.)

https://github.com/llvm/llvm-project/pull/67663