4 ms·
I agree with your general point, but for this specific functionality, I’ll point out that setting environment variables of the current process is unsafe. It too
by shepmaster 1y ago
I agree with your general point, but for this specific functionality, I’ll point out that setting environment variables of the current process is unsafe. It took us a long time to realize it so the function wasn’t actually marked as unsafe until the Rust 2024 edition.
What this means in practice is that the call to invoke dotenv should also be marked as unsafe so that the invoker can ensure safety by placing it at the right place.
If no one is maintaining the crate, that won’t happen and someone might try to load environment variables at a bad time.
- andy_xor_andrew 1y agook, I'm hooked - how is setting an env var in the current process unsafe? My gut says it's not unsafe in a memory-ownership sense, but rather in a race condition sense? whatever the issue is, "setting an env var is unsafe" is so interesting to me that I'm now craving a blog post explaining this
- Orangeair 1y agoIt's a long standing bug, setenv and unsetenv are not thread-safe https://www.evanjones.ca/setenv-is-not-thread-safe.html https://www.evanjones.ca/setenv-is-not-thread-safe.html
- robertlagrant 1y agoI honestly think using setenv is just a terrible idea.
- ak_111 1y agocan you elaborate what is the simpelist alternative?
- darthwalsh 1y agoSimple, you don't set any env vars after starting new threads
- estebank 1y agohttps://doc.rust-lang.org/std/env/fn.set_var.html#safety https://doc.rust-lang.org/std/env/fn.set_var.html#safety