Repository navigation
Fixing unsafe_op_in_unsafe_fn for std::{os, sys} #127747
Description
Activity
- added and removed
on Jul 15, 2024 - added a commit that references this issue
on Jul 15, 2024 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
allowfor this lint, but I assume that we will eventually remove such allowances.Pinging first everyone who has their own
std::sys::palsubmodule, 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 usingdeny(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::syncand the other "top level" modules ofsysfor your platform's code in its submodules.Reacted by Martin KröningXous already has
#![deny(unsafe_op_in_unsafe_fn)]insys/pal/xous/mod.rs, and adding it toos/xous/mod.rsdoes not cause any failures.Adding it to the top of
sys/mod.rscauses 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_unalignedfor 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.
Reacted by JubileeReacted by JubileeI think we should add
#[forbid]s to leaf modules instead and slowly move them up the module tree until we reach the root. Just#[deny]ing the lint stills allows adding new cases of this to modules that have already been fixed.Reacted by GrigorenkoPVAdding
#![deny(unsafe_op_in_unsafe_fn)]insys/pal/uefi/mod.rsandos/uefi/mod.rscause no failures.Reacted by Jubilee57 remaining items
- added 5 commits that reference this issue
on Feb 21, 2025 - added 10 commits that reference this issue
on Mar 3, 2025
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 theallows at the top level ofstd::osandstd::sysin 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.
unsafe_op_in_unsafe_fnwhen building std for armv6k-nintendo-3ds #127996windows-y
#![deny(unsafe_op_in_unsafe_fn)]#127750#![deny(unsafe_op_in_unsafe_fn)]#127763c_voidrather than using the full path #128131uniques
We have a grab bag of others here, some of which are "Unix family" but are... estranged cousins, if so.
deny(unsafe_op_in_unsafe_fn)#128433#![forbid(unsafe_op_in_unsafe_fn)]#127873#[forbid(unsafe_op_in_unsafe_fn)]instdlib#127833