How to proceed with set_var & remove_var becoming `unsafe` in edition 2024?

[fabian-braun]

In Rust edition 2024 the functions env::set_var and env::remove_var are marked as unsafe.
However, they have been unsafe practically since the start of Rust, it's only now, that they're marked as such.

In principle, our test-helpers are unsafe in a similar way and if we follow the reasoning of the Rust maintainers we would have to make our functions unsafe too. But that would make this crate very ugly to use.

Therefore, I would propose to add a section to our Readme in order to make clear:

• This crate is just as unsafe as env::set_var and env::remove_var
• We choose to hide that unsafety for ease-of-use in tests
• This crate is supposed to be used in tests, where it does a good job and causes not harm.

What do you think about it?

We don't have to do anything right now, because we don't want to move to edition 2024 yet (it would increase our MSRV to 1.85). But, we could already mention this problem in the Readme

Accompanying info & further reading

https://doc.rust-lang.org/std/env/fn.set_var.html

In multi-threaded programs on other operating systems, the only safe option is to not use set_var or remove_var at all.
The exact requirement is: you must ensure that there are no other threads concurrently writing or reading(!) the environment through functions or global variables other than the ones in this module. The problem is that these operating systems do not provide a thread-safe way to read the environment, and most C libraries, including libc itself, do not advertise which functions read from the environment. Even functions from the Rust standard library may read the environment without going through this module, e.g. for DNS lookups from std::net::ToSocketAddrs. No stable guarantee is made about which functions may read from the environment in future versions of a library. All this makes it not practically possible for you to guarantee that no other thread will read the environment, so the only safe option is to not use set_var or remove_var in multi-threaded programs at all.

In this PR I bumped the edition to 2024, just to see how it would look.

[vmx]

Wouldn't our SERIAL_TEST make our use single-threaded, hence not have the unsafety issue? Though I might miss something here.

[fabian-braun]

Wouldn't our SERIAL_TEST make our use single-threaded, hence not have the unsafety issue? Though I might miss something here.

No, it's not prevented... A user of our library could start a thread and use env::set_var directly. This could then race with our test-helper functions and cause undefined behaviour. I cannot come up with a reasonable case why someone might do this, but it's certainly possible.