Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.



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.


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


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


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 ..


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.


I assume doing something on behalf of a remote user and still convinced locales can do a thing other than hurt you.


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


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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: