It’s neither in the headline or in the article. The question was about setenv, not getenv.

It is best to avoid calling setenv in a threaded program. Some programs do it to make space for rewriting argv with large strings (freeing space from *environ which tends to be right after the tail of argv). Some programs or libraries use *environ directly to stage variables for exec before forking. Some want to pass variable changes to forks. There are alternatives possible, but in the context of something like go calling libc setenv, it’s to make interop easier- sadly it may make other interop harder, such as this case.

? setenv not getenv. You'd rarely use setenv, and even then you'd do it at startup.

Right. That's been my experience so far, hence my question.

It's not. OP was asking about setenv, not getenv...