undefined | Better HN

0 pointseinpoklum1y ago0 comments

It really does not look like a good idea to setenv() . The very notion is quite terrifying. Messing with a bunch of globals, that other code knows about as well? Nuh-uh.

The thing is, the OP people weren't doing that at all, it was some irresponsible library maintainers. If your code does that, you have to include something like the "surgeon general's warning" everywhere: "CAREFUL: USING THIS LIBRARY MAY CAUSE TERMINAL CRASHES".

0 comments

Animats1y ago

Agreed.

History: V7 research UNIX had "getenv()", but not "setenv()".[1] BSD Unix 4.x had "getenv()" and "setenv()"[2] Google's "AI Overview" says "The setenv() and unsetenv() functions were included in Version 7 of AT&T UNIX.", but that does not seem to be correct.

This misfeature seems to be what was once called a "Berkeleyism", a Berkeley mod to UNIX.

"setenv()" predates UNIX/Linux getting threads.

[1] http://web.cuzuco.com/~cuzuco/v7/v7vol1.pdf

[2] https://archive.org/details/44bsdprogrammers0000ucbe/page/n3...

SAI_Peregrinus1y ago

It's OpenSSL. It's basically a sea urchin turned into code in terms of safe handling.

rcxdude1y ago

Sadly, it's often the only way to adjust certain behaviors of certain libraries.

einpoklumOP1y ago

I think you're confusing setting the environment before running a process, with setting the environment _within_ the process. If you're running a shell session, or even a compiled process which is just a "runner" for some other process - then certainly, we all do "export SOME_SETTING=value" and run things. But if you're writing a C library, which could well be used in a multi-threaded environment - you don't need to "adjust" anything, and should not invoke setenv. If your library is not pleased with the settings of another library, then it should start returning errors, or even exit() if you're a violent kind of a guy - but not setenv().

j / k navigate · click thread line to collapse