AaronBallman wrote: > If the implementation is conforming this doesn't do anything. In fact, they > have to be the same function.
That was my understanding as well, thanks! So it sounds like the problem is that there's an underlying `::getenv` that isn't thread safe (which is conforming according to the C standard but not the latest POSIX standard) C23 7.24.4.6p2: ... The getenv function is not required to avoid data races with other threads of execution that modify the environment list. [POSIX](https://pubs.opengroup.org/onlinepubs/9799919799/): ... Some earlier versions of this standard did not require getenv() to be thread-safe because it was allowed to return a value pointing to an internal buffer. However, this behavior allowed by the ISO C standard is no longer allowed by POSIX.1. POSIX.1 requires the environment data to be available through environ[], so there is no reason why getenv() can't return a pointer to the actual data instead of a copy. Therefore getenv() is now required to be thread-safe (except when another thread modifies the environment). ... https://github.com/llvm/llvm-project/pull/108529 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
