Re:Don't setenv in multi-threaded code on glibc
by mzs on Tuesday January 31, 2017 @02:29PM
(#13534320)
more importantly go never calls getenv()
Re:Don't setenv in multi-threaded code on glibc
by bonzini on Tuesday January 31, 2017 @04:51PM
(#13535579)
Not "more importantly". It would have exactly the same behavior if it called getenv (and copied the result) under a mutex.
And likewise it would be subject to use-after-free races if it didn't call getenv but also didn't use a mutex to protect its accesses.
So the important bit is the mutex.
Re:Don't setenv in multi-threaded code on glibc
by mzs on Tuesday January 31, 2017 @05:32PM
(#13535967)
https://blog.golang.org/c-go-cgo
Say you call foo() in foo.c and foo() calls getenv() and setenv() with your mutex in the safeenv.go approach you described, all those calls from foo.c don't have the mutex around them that your foo.go uses. Worse yet it might not be your foo.c but part of libfoo in your OS.
Re:Don't setenv in multi-threaded code on glibc
by bonzini on Wednesday February 01, 2017 @03:15AM
(#13539213)
But Go's Setenv calls setenv_c, so a rogue C getenv would still be able to provoke races in Go code. Yes, a rogue C setenv would not provoke races in Go code calling getenv, but C interoperability is busted anyway---that's why I said that the mutex is the important part. It would work just as well (excluding cgo) if Go getenv called C getenv.
They don't use getenv because it does a slow linear search, while Go can use a more efficient string->string map.
https://golang.org/src/syscall/env_unix.go