3 ms·

The value of `setenv(3)` has always been pretty murky to me -- the only time I've ever really needed it is when performing a fork-exec, and even then it's been

The value of `setenv(3)` has always been pretty murky to me -- the only time I've ever really needed it is when performing a fork-exec, and even then it's been the wrong tool for the job (the dedicated exec*e variants are the right way). Would there be any significant downsides (besides breakage) to mapping `environ(7)` as read-only? That seems like the kind of thing that a Linux distribution (or more realistically OpenBSD) could do as a way to kill off a persistent family of bugs.

fsociety 3y ago
If they did it, it would break userspace for a probably surprising amount of processes.
- Brian_K_White 3y ago
  Why not find those? Especially in a dedicated arena whose stated goals are things just like that like openbsd.
j16sdiz 3y ago
It is quite common a pattern setting the timezones with setenv("TZ",...) There are alternatives, but rewriting every program is not always an option. These kind of rewriting sounds exactly like what OpenBSD would do ..
- woodruffw 3y ago
  This is perhaps just my ignorance, but when do you find yourself needing to set the timezone like that? Not in 10+ years of C programming have I ever had to do that.
  - masklinn 3y ago
    I assume doing something on behalf of a remote user and still convinced locales can do a thing other than hurt you.
  - fanf2 3y ago
    I might do that if I am writing a quick-and-dirty program that works with times in multiple time zones and I can’t be bothered to find a library with a better API.
  - j16sdiz 3y ago
    In most of the time, you just set it on program start and never change. This is quite common for programs that expects UTC. Searching in github, other example are: 1) `jq` parsing datetime 2) systemd , timectl printing status 3) Unit tests 4) Some RDP client update its own timezone with server timezone
gpderetta 3y ago
The best part is that you can't use setenv after fork and before execve as it is not async signal safe. As you mention, the envp-taking variant of execve is the only sane option.

fsociety 3y ago

If they did it, it would break userspace for a probably surprising amount of processes.

Brian_K_White 3y ago
Why not find those? Especially in a dedicated arena whose stated goals are things just like that like openbsd.

j16sdiz 3y ago

It is quite common a pattern setting the timezones with setenv("TZ",...) There are alternatives, but rewriting every program is not always an option. These kind of rewriting sounds exactly like what OpenBSD would do ..

woodruffw 3y ago
This is perhaps just my ignorance, but when do you find yourself needing to set the timezone like that? Not in 10+ years of C programming have I ever had to do that.
- masklinn 3y ago
  I assume doing something on behalf of a remote user and still convinced locales can do a thing other than hurt you.
- fanf2 3y ago
  I might do that if I am writing a quick-and-dirty program that works with times in multiple time zones and I can’t be bothered to find a library with a better API.
- j16sdiz 3y ago
  In most of the time, you just set it on program start and never change. This is quite common for programs that expects UTC. Searching in github, other example are: 1) `jq` parsing datetime 2) systemd , timectl printing status 3) Unit tests 4) Some RDP client update its own timezone with server timezone

gpderetta 3y ago

The best part is that you can't use setenv after fork and before execve as it is not async signal safe. As you mention, the envp-taking variant of execve is the only sane option.