Fixing unsafe_op_in_unsafe_fn for std::{os, sys} · Issue #127747 · rust-lang/rust (original) (raw)

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

darwinian

linuxen

unixen

embedded unix + newlib

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

windows-y

uniques

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