Open RalfJung opened 6 days ago
@scottmcm wrote
Note that lang and libs both want a lint for ptr-to-int via
as
(https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/Adding.20methods.20as.20more.20specific.20versions.20of.20.60as.60/near/238391074) so if anyone wants to pick that up it should hopefully be uncontroversial.
However, that discussion was about ptr-to-u8
casts (and in general, non-usize
). I am not sure what the libs and lang stance is on linting against the usize
version of these casts.
Nominating for t-lang to get a "temperature".
I am also not sure if this shouldn't maybe be a clippy lint instead of a rustc lint?
Would hosting this in rustc
allow for making the breaking change to the usize
definition in the future by making this lint forbid
? I realise that usize
proposal is only a pre-RFC at the moment.
Code that wants to be portable for CHERI likely has to set these lints to forbid
(or at least the int-to-ptr one -- but without int-to-ptr casts, there's no point in having any ptr-to-int casts). That doesn't mean the lint has to be in rustc, though.
We discussed this in (excessive, as is our wont) length at the @rust-lang/lang meeting. The conclusions were:
cargo fix
, a stable alternative, and we should consider other avenues to mitigate impact. We'd like to review that plan/PR before we "go live".We think it should have a
cargo fix
Did anyone explain why? Suggesting people automatically migrate to the strict provenance conversions will type-check but probably add UB that is highly non-theoretical since https://github.com/rust-lang/rust/pull/121282. Suggesting expose
/from_exposed
will work, but I generally recognize those names as indicating that the author thought about their code and decided they need expose semantics.
but I generally recognize those names as indicating that the author thought about their code and decided they need expose semantics.
I'm afraid that signal will anyway diminish fairly quickly, as we have seen e.g. with assume_init
-- initially it was a signal, but then people just blindly replaced mem::uninitialized()
with MaybeUninit::uninit().assume_init()
.
This issue is tracking the factors that will cause the signal to diminish. If we care about the signal, we should be mindful to preserve it instead of creating more problems like was done with MaybeUninit. uninit().assume_init()
should have been banned from the start via lint, but instead the documentation suggested using it for arrays.
The documentation suggested it for arrays of MaybeUninit<_>
. (IIRC we tried having a macro for this but t-libs-api wasn't convinced of that approach.)
But anyway, that was just an example, we don't have to litigate its details. The point is, I am not convinced we are fully in control of how that signal will diminish. Also, not having any as
casts any more is an intended end state (IMO), so at some point there will definitely be no signal any more -- at best, we can get "one pass" over the current ecosystem, but it's not a long-term thing.
This tracks the two lints associated with the strict provenance feature:
as
cast from an integer to a pointer. It is better to usewith_exposed_provenance
instead to make explicit what happens.as
cast from a pointer to an integer. It is better to useexpose_provenance
instead to make explicit what happens.I am not sure if having two lints here is really justified, IMO they could be merged into one -- not sure what that one should be called, though. Other than that, this seems like a useful lint to ensure the codebase follows strict provenance (or opts-out explicitly, via the methods mentioned above).
I am also not sure if this shouldn't maybe be a clippy lint instead of a rustc lint?
Cc @rust-lang/opsem