From 37db1b7e0ef48abaccc08ac8090c119b8c5453f8 Mon Sep 17 00:00:00 2001 From: Ralf Jung Date: Wed, 13 Apr 2022 11:28:50 -0400 Subject: [PATCH] fix a typo --- ralf/_posts/2022-04-11-provenance-exposed.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ralf/_posts/2022-04-11-provenance-exposed.md b/ralf/_posts/2022-04-11-provenance-exposed.md index 901b706..e5560e2 100644 --- a/ralf/_posts/2022-04-11-provenance-exposed.md +++ b/ralf/_posts/2022-04-11-provenance-exposed.md @@ -261,7 +261,7 @@ So what are the alternatives? Well, I would argue that the alternative is to treat the original program (after translation to Rust) as having Undefined Behavior. There are, to my knowledge, generally two reasons why people might want to transmute a pointer to an integer: - Chaining many `as` casts is annoying, so calling `mem::transmute` might be shorter. -- The code doesn't actually care about the *integer* per se, it just needs *some way* to hold arbitrary data in a container of a given time. +- The code doesn't actually care about the *integer* per se, it just needs *some way* to hold arbitrary data in a container of a given type. The first kind of code should just use `as` casts, and we should do what we can (via lints, for example) to identify such code and get it to use casts instead.[^compat] Maybe we can adjust the cast rules to remove the need for chaining, or add some [helper methods](https://doc.rust-lang.org/nightly/std/primitive.pointer.html#method.expose_addr) that can be used instead. -- 2.30.2