getenv() is weirdly enough not async signal safe. Most will considerthat unimportant, which is true until suddenly it is extremely important. It would be really great if C++'s implementation gained async signal safety.
Agreed, though I think it is unsurprising that getenv() is not async-signal-safe. POSIX states:
Applications can change the entire environment in a single operation by assigning the environ variable to point to an array of character pointers to the new environment strings. After assigning a new value to environ, applications should not rely on the new environment strings remaining part of the environment, as a call to getenv(), [XSI] putenv(), setenv(), unsetenv(), or any function that is dependent on an environment variable may, on noticing that environ has changed, copy the environment strings to a new array and assign environ to point to it.
Any application that directly modifies the pointers to which the environ variable points has undefined behavior.
Conforming multi-threaded applications shall not use the environ variable to access or modify any environment variable while any other thread is concurrently modifying any environment variable. A call to any function dependent on any environment variable shall be considered a use of the environ variable to access that environment variable.
Peter Brett and I chatted earlier today about how the situation could potentially be improved via changes to POSIX. The approach we discussed is:
Any concurrent use of environ or the envp pointer passed to main() with the RCU-based interface would remain undefined behavior.
Obviously, this would be a lot of work and would take a long