5 ms·
Mutable global state is evil. Friends don’t let friends use mutable global state. I hate envvars. It’s “the Linux way”. I avoid them like the plague. A++ stron
by forrestthewoods 2y ago
Mutable global state is evil. Friends don’t let friends use mutable global state.
I hate envvars. It’s “the Linux way”. I avoid them like the plague. A++ strong recommend.
libc is terrible. The world needs to move on.
- 01HNNWZ0MV43FF 2y agoEnv vars are good if you treat them as read-only within the process
- msully4321 2y agoYeah, setenv should probably just not exist, and environment variables should be only set when spawning new processes.
- plorkyeran 2y agoThe problem is that applications sometimes need to set environment variables which will be read by libraries in the same process. This is safe to do during startup, but at no later times. Ideally all libraries which use environment variables should have APIs allowing you to override the env variables without calling setenv(), but that isn't always the case.
- msully4321 2y agoYeah, the cows have certainly gotten out already.
- docandrew 2y agoI’d argue that libraries shouldn’t read environment variables at all. They’re passed on the initial program stack and look just like stack vars, so the issue here is essentially the same as taking the address of a stack variable and misusing it. Just like a library wouldn’t try to use argv directly, it shouldn’t use envp either (even if done via getenv/setenv)
- kelnos 2y ago> The problem is that applications sometimes need to set environment variables which will be read by libraries in the same process. This is safe to do during startup, but at no later times. No, the problem is that libraries try to do this at all. Libraries should just have those APIs you mention, and not touch env vars, period. If you, the library user, really want to use env vars for those settings, you can getenv() them yourself and pass them to the library's APIs. Obviously we can't change history; there are libraries that do this anyway. But we should encourage library authors to (in the future) pretend that env vars don't exist.
- PaulDavisThe1st 2y agoIf env vars don't exist, that makes it much harder (and more likely impossible) for users to modify library/application behavior at run time. I agree with you that it would be much better if, when libA needs to set behavio Foo in libB, it called libB:setBehavior (Foo) rather than setenv ("LibBehavior", "Foo") But let's not throw the baby out with the bathwater.
- plorkyeran 2y agoThe place where it makes sense for a library to read environment variables is where the program is not written to use that specific library. For example, I can link a program whose author has never heard of TCMalloc against TCMalloc rather than the system malloc, and then configure TCMalloc via environment variables. This does not require modifying a single line of code, while manually forwarding configuration onto the allocator would. Another common example is configuring sanitizers. Not having to do anything other than pass another command-line switch to the compiler is one of the things that makes them really painless to use. I do think you'd be hard-pressed to find a situation where a program calling setenv() to configure a library actually makes sense. It's a pretty strong sign that someone made a bad decision. People will, however, make mistakes in API design.
- bashkiddie 2y agoI guess the usecase is dlopen() which passes on your environment. If you want to load libpam-keberos and pass DEBUG=verbose you will need to setenv() your own environment.
- forrestthewoods 2y agoI’ll take a config file over an envvar 100% of the time.
- jimbob45 2y agoWhat's your preferred alternative?
- glouwbug 2y agolibc moved the world into the Information Age
- maep 2y ago> Mutable global state is evil. Friends don’t let friends use mutable global state. Throw away your CPU and RAM then.
- titzer 2y agoAnd disks. And the cloud. Or basically, you know, computers.
- layer8 2y agoThe universe, you mean.
- kibwen 2y agoDon't threaten me with a good time.
- incrudible 2y agoAh yes, the cloud where we all happily share compute resources without any restrictions to avoid stomping on each others toes.
- forrestthewoods 2y agoI can not possibly roll my eyes hard enough. Go ahead and write lots of mutable global statics. But when your program crashes randomly and you need my help to debug and it is, once again, a global mutable then you have to perform a walk of shame.
- incrudible 2y agoYour CPU has an MMU in order to (among other things) let the OS prevent mutable global state.
- snowfarthing 2y agoThere are certainly levels of the abstraction pyramid where mutable global state is unavoidable; however, it shouldn't be too difficult to get to a point where we have enough abstraction so that we don't need to worry about mutable global state for what we do. And even if those abstractions can't be 100% effective, we'd go a long way to achieving the desirable results of getting rid of it, if we just develop the mindset of avoiding it if at all possible, excepting for very rare instances where it's needed as a last resort.
- andrewmcwatters 2y agoDon’t use a mouse or a monitor then.
- snowfarthing 2y agoOne of the reasons X is being fazed out in favor of Wayland is because X is far more global than it needs to be -- and this is one of the reasons it has security risk that can't be completely removed without API-breaking effects.
- sim7c00 2y agowhat do you suggest as alternative? the problem is not linux, not mutable global state or resources and not libc. the problem is not getting time at work to do things properly. like spotting this in GDB before the issue hit, because your boss gave you time to tirelessly debug and reverse your code and anything it touches.... there is too much money in halfbaked code. sad but true.
- viraptor 2y agoIt definitely is the current libc. That one's proven by systems which do not have the same problem. Then the next layer problem is trying to pretend we can get everyone to pay attention and avoid bugs in code instead of forcing interfaces and implementations where those bugs are not possible.
- sim7c00 2y agojust because someone makes a window doesn't mean you gotta jump out of it. there are good and bad uses for things, and the bad ones should be avoided lest one hurt themselves?
- viraptor 2y agohttps://en.wikipedia.org/wiki/Death_of_Garry_Hoy https://en.wikipedia.org/wiki/Death_of_Garry_Hoy people will assume more safety than necessary. You don't have to jump, but someone will try. We can accept that fact or watch people fail over and over on the same issue. It's better to help everyone avoid the problem in the first place. For some reason lots of programmers will behave like the comment section on an accident video. "I would notice that earlier", "I'd avoid that", "I can react faster".
- sim7c00 2y agodoesn't make it less true. all sorts of 'dangerous' things are used by people daily all around the world. There are issues sure, but that doesn't mean it's neccesarily a bad thing. for example cars, stairs, kitchen knives... These things are perhaps more commonly known to be bad, and the dangers are perhaps more obvious. There will always be people who use things in the wrong way too, which doesn't make the thing bad, but how it's used. There are buildings in my country with nets around them because people keep jumping off them (suicidal). The buildings are safe. The nets are not a solution, they just shift the problem and don't tackle the root cause. There are many car crashes with fatal victims. Sure care manufacturers try to make cars safer, but there's no hordes of people hating on cars calling for them to be abolished in favor of safer technology because people rely on them heavily. Same for libc. People try to improve its safety, and try to advice and write about its dangers. Just because bugs exist and unsafe conditions can occur doesn't mean something should be dropped all together... a lot of the world relies heavily on libc, safe and unsafe uses of it even. What's more is that libc and linux etc. are open-source. If someone knows a sound solution to these issues which does not break the entire world, they are free to submit pull requests.... simply stating something is 'rubbish' and needs to be put down is an unproductive and shortsighted sentiment.
- deleted 2y ago[deleted]