Remove lock guarantee from std::env::{set_var, remove_var}

library/std/src/env.rs

@@ -326,17 +326,16 @@ impl Error for VarError {
 /// In multi-threaded programs on other operating systems, we strongly suggest
 /// not using `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.
+/// *reading*(!) the environment through functions or global variables. 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 some functions
+/// from the Rust standard library read the environment, 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.
 ///
 /// Discussion of this unsafety on Unix may be found in:
 ///
@@ -393,17 +392,16 @@ unsafe fn _set_var(key: &OsStr, value: &OsStr) {
 /// In multi-threaded programs on other operating systems, we strongly suggest
 /// not using `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.
+/// *reading*(!) the environment through functions or global variables. 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 some functions
+/// from the Rust standard library read the environment, 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.
 ///
 /// Discussion of this unsafety on Unix may be found in:
 ///