The security example shows that `env::current_exe` will return the
path used when the program was started. This is not really surprising
considering how hard links work: after `ln foo bar`, the two files are
_equivalent_. It is _not_ the case that `bar` is a “link” to `foo`,
nor is `foo` a link to `bar`. They are simply two names for the same
underlying data.

The security vulnerability linked to seems to be different: there an
attacker would start a SUID binary from a directory under the control
of the attacker. The binary would respawn itself by executing the
program found at `/proc/self/exe` (which the attacker can control).
This is a real problem. In my opinion, the example given here doesn’t
really show the same problem, it just shows a misunderstanding of what
hard links are.

I looked through the history a bit and found that the example was
introduced in #33526. That PR actually has two commits, and the
first (8478d48d) explains the race
condition at the root of the linked security vulnerability. The second
commit proceeds to replace the explanation with the example we have
today.

This commit reverts most of the second commit from #33526.

This updates the standard library's documentation to use the new syntax. The
documentation is worthwhile to update as it should be more idiomatic
(particularly for features like this, which are nice for users to get acquainted
with). The general codebase is likely more hassle than benefit to update: it'll
hurt git blame, and generally updates can be done by folks updating the code if
(and when) that makes things more readable with the new format.

A few places in the compiler and library code are updated (mostly just due to
already having been done when this commit was first authored).

As a security measure, Windows 11 introduces a new temporary directory API, GetTempPath2.
When the calling process is running as SYSTEM, a separate temporary directory
will be returned inaccessible to non-SYSTEM processes. For non-SYSTEM processes
the behavior will be the same as before.

It might not be obvious that the "path of the current running executable" may (or may not) mean "at the time it was loaded".

The function parameters were renamed, but the documentation wasn't.

Before this, `std`'s env var getter functions would panic on
receiving certain invalid inputs. This commit makes them
return a `None` or `Err` instead.

Searching for `chdir` in the Rust documentation produces no useful
results.

Update the sample code to not create an insecure temporary file.

Also doing fmt inplace as requested.

vars() rather than vars function
Co-authored-by: NJoshua Nelson <joshua@yottadb.com>

Use [xxx()] rather than the [xxx] function
Co-authored-by: NJoshua Nelson <joshua@yottadb.com>

Env text representation of function intra-doc link

Suggested by @jyn514

Link join_paths in env doc for parity

Change xxx to env::xxx for lib env doc

Add link requsted by @jyn514

Fix doc build with same link
Co-authored-by: NJoshua Nelson <joshua@yottadb.com>

Fix missing intra-doc link

Fix added whitespace in doc
Co-authored-by: NJoshua Nelson <joshua@yottadb.com>

Add brackets for `join_paths`
Co-authored-by: NJoshua Nelson <joshua@yottadb.com>

Use unused link join_paths

Removed same link for join_paths
Co-authored-by: NJoshua Nelson <joshua@yottadb.com>

Remove unsed link join_paths

This simplifies the definition for ARCH.

Note that this changes asmjs-unknown-emscripten ARCH to `wasm32`,
which reflects the actual target arch.

It is not possible to compile libstd for AVR anyway.