This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug libc/15607] Add threadsafe version of getenv()

Rich Felker <bugdal at aerifal dot cx> changed:

           What    |Removed                     |Added
                 CC|                            |bugdal at aerifal dot cx

--- Comment #4 from Rich Felker <bugdal at aerifal dot cx> ---
I agree with Jakub. Programs that are or may be (due to libraries that may use
threads) multi-threaded cannot modify their own environments. There's little
point in modifying your own environment anyway; for executing external
programs, the exec-family functions and posix_spawn both provide interfaces by
which you can specify your own environment for the new process image in a fully
safe manner.

Note that getenv_r could not protect against modifications to the environment
through extern char **environ, nor could setenv_r protect against reads via
environ. Thus, they could only have limited success in making environment
modification "thread-safe".

As far as I'm concerned, this bug report should be filed against
gnome-settings-daemon, not glibc, and it should be fixed by (preferably)
avoiding modification to the environment in the process itself and using the
appropriate exec-type functions, or by generating a completely new environment
and replacing extern char **environ atomically with a pointer to the new

Note that, if others do end up deeming it desirable to change glibc, the
appropriate change would be having setenv do the above-described atomic
replacement and simply leak the old environment. This would be fully safe with
no locking.

You are receiving this mail because:
You are on the CC list for the bug.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]