Fixing `unsafe_op_in_unsafe_fn` for `std::{os, sys}`

[workingjubilee]

In #127744 we begin to deny(unsafe_op_in_unsafe_fn) in the standard library, but there are... many... platforms which all use unsafe code inside unsafe functions. It is unreasonable to fix them all in one step.

Even if it is technically possible to do this in one push that "fixes" it for all the platforms we run tier 1/2 CI on, that would be extremely rude. That would then immediately nuke all tier 3 platforms that aren't a variation on the tier 2 ones. We should at least try to allow people to respond before we do so. After all, we will eventually update the standard library to edition 2024 anyway.

To fix each platform, one at a time, deny(unsafe_op_in_unsafe_fn) should be moved into that platform's support modules (and even individual functions, if necessary). As we can see from the following test sample, you can have a deny, then an allow, then a deny, and it still works correctly. So we will keep the allows at the top level of std::os and std::sys in place.

For now.

In order to not have one giant table of targets that make my eyes blur, I have split the categories in somewhat arbitrary ways. This is primarily based on the heuristic of "if other examples in this category are fixed, are the rest likely to also be fixed?" except for the "uniques" set, which I expect will almost all require individual attention.

berkeley software descendants

• freebsd
• netbsd
• tier 3
  • dragonfly
  • openbsd

darwinian

• macOS
• iOS
• tier 3
  • tvOS
  • visionOS
  • watchOS

linuxen

• android
• linux-gnu
• linux-musl

unixen

• illumos
• redox
• solaris
• tier 3
  • aix
  • haiku
  • hurd
  • nto
  • vxworks - Forbid unused unsafe in vxworks-specific std modules #128539

embedded unix + newlib

Unix-ish impls mostly intended for embedded-ish usage, all using newlib.

• espidf
• horizon - Clean up warnings + unsafe_op_in_unsafe_fn when building std for armv6k-nintendo-3ds #127996
• vita - Fix vita build of std and forbid unsafe in unsafe in the os/vita module #128315

windows-y

• windows-gnu
• windows-gnullvm
• windows-msvc
• win7
• Make os/windows and pal/windows default to #![deny(unsafe_op_in_unsafe_fn)] #127750
• Make more Windows functions #![deny(unsafe_op_in_unsafe_fn)] #127763
• Import c_void rather than using the full path #128131

uniques

We have a grab bag of others here, some of which are "Unix family" but are... estranged cousins, if so.

• fuchsia
• hermit - fix(hermit): deny(unsafe_op_in_unsafe_fn) #128433
• kmc-solid - kmc-solid: #![forbid(unsafe_op_in_unsafe_fn)] #127873
• l4re
• sgx
• teeos - delete #![allow(unsafe_op_in_unsafe_fn)] in teeos #127789
• uefi - std: Forbid unwrapped unsafe ops in xous and uefi modules #127836
• wasm-emscripten
• wasm-unknown
• wasm-wasi
• wasm-wasi-threads
• xous - std: Forbid unwrapped unsafe ops in xous and uefi modules #127836
• zkvm - zkvm: add #[forbid(unsafe_op_in_unsafe_fn)] in stdlib #127833

[workingjubilee]

My current belief is that, like with every edition update so far, we will eventually fix the lint in all relevant places. By "fixed" I mean actually fixing it. However, it is fine if a platform adds more instances of allow for this lint, but I assume that we will eventually remove such allowances.

Pinging first everyone who has their own std::sys::pal submodule, since those are easiest to add #![deny(unsafe_op_in_unsafe_fn)] into their actual submodule, at the moment. You may have nothing to do! Just confirm that and we can mark it off... but do please actually check. At least one platform has started on using deny(unsafe_op_in_unsafe_fn) in some of its submodules, but has at least one instance of code that should fail that lint, yet is neither specifically denied nor allowed.

• hermit: @stlankes @mkroening
• kmc-solid: @kawadakk (is this also the source of the "itron" submodule)?
• sgx: @jethrogb @raoulstrackx @mzohreva
• teeos: @Sword-Destiny @petrochenkov
• uefi: @dvdhrm @nicholasbishop @Ayush1325
• xous: @xobs
• zkvm: @flaub @jbruestle @SchmErik

Also remember to check std::sys::sync and the other "top level" modules of sys for your platform's code in its submodules.

[xobs]

Xous already has #![deny(unsafe_op_in_unsafe_fn)] in sys/pal/xous/mod.rs, and adding it to os/xous/mod.rs does not cause any failures.

Adding it to the top of sys/mod.rs causes failures in:

• library/std/src/sys/pal/common/alloc.rs - std: Unsafe-wrap actually-universal platform code #128089
• library/std/src/sys/personality/dwarf/eh.rs - std: unsafe-wrap personality::dwarf::eh #128055
• library/std/src/sys/personality/dwarf/mod.rs - std: Use read_unaligned for reads from DWARF #127792
• library/std/src/sys/personality/gcc.rs - std: unsafe-wrap personality::gcc #128158
• library/std/src/sys/backtrace.rs - std: Unsafe-wrap actually-universal platform code #128089

But otherwise there are no issues for Xous.