[msully4321]

Yeah, setenv should probably just not exist, and environment variables should be only set when spawning new processes.

[plorkyeran]

The problem is that applications sometimes need to set environment variables which will be read by libraries in the same process. This is safe to do during startup, but at no later times.

Ideally all libraries which use environment variables should have APIs allowing you to override the env variables without calling setenv(), but that isn't always the case.

[kelnos]

> The problem is that applications sometimes need to set environment variables which will be read by libraries in the same process. This is safe to do during startup, but at no later times.

No, the problem is that libraries try to do this at all. Libraries should just have those APIs you mention, and not touch env vars, period. If you, the library user, really want to use env vars for those settings, you can getenv() them yourself and pass them to the library's APIs.

Obviously we can't change history; there are libraries that do this anyway. But we should encourage library authors to (in the future) pretend that env vars don't exist.

[docandrew]

I’d argue that libraries shouldn’t read environment variables at all. They’re passed on the initial program stack and look just like stack vars, so the issue here is essentially the same as taking the address of a stack variable and misusing it.

Just like a library wouldn’t try to use argv directly, it shouldn’t use envp either (even if done via getenv/setenv)

[msully4321]

Yeah, the cows have certainly gotten out already.

[bashkiddie]

I guess the usecase is

    dlopen()

which passes on your environment. If you want to load libpam-keberos and pass

    DEBUG=verbose

you will need to setenv() your own environment.