On 01/31/2017 04:49 PM, Ben Hutchings wrote: > On Tue, 2017-01-31 at 14:23 +0100, Christian Seiler wrote: >> On 01/31/2017 11:15 AM, Mathieu Malaterre wrote: >>> I'd like to discuss addition of a new lintian checks for >>> getenv/setenv/putenv used in shared libraries. >> >> Why getenv() though? It just reads the environment. >>> From what you link yourself: >>> The getenv and secure_getenv functions can be safely used in >>> multi-threaded programs. > [...] > > But it returns a pointer to the value, which might be freed by another > thread before it is used. If there were a reader function that copied > the value to a caller-provided buffer, it could be properly thread- > safe.
But that's only a problem if you call setenv() or similar in a different thread, which you shouldn't do. getenv() is only unsafe if the environment is modified, a library using getenv() in a program that follows libc's guidelines to not call setenv() in an MT-context is perfectly fine. (Any program that calls setenv() will call getenv() as well at some point, otherwise you could simply drop the setenv() completely; so any program that does that in an MT context is broken anyway, regardless of whether it uses a library that does an additional getenv().) So regardless of whether a check for setenv() etc. in libraries is introduced into lintian: getenv() shouldn't be checked for IMHO. That said: I do agree that the way the entire API around environment variables is defined is quite horrible. Regards, Christian
