library: Compute Rust exception class from its string repr #130381
Conversation
rustbot
added
S-waiting-on-review
|
@bors r+ rollup |
bors
added
S-waiting-on-bors
…iaskrgr Rollup of 5 pull requests Successful merges: - rust-lang#129195 (Stabilize `&mut` (and `*mut`) as well as `&Cell` (and `*const Cell`) in const) - rust-lang#130118 (move Option::unwrap_unchecked into const_option feature gate) - rust-lang#130295 (Fix target-cpu fpu features on Armv8-R.) - rust-lang#130371 (Correctly account for niche-optimized tags in rustc_transmute) - rust-lang#130381 (library: Compute Rust exception class from its string repr) r? `@ghost` `@rustbot` modify labels: rollup
| // M O Z \0 R U S T -- vendor, language | ||
| 0x4d4f5a_00_52555354 | ||
| } | ||
| const RUST_EXCEPTION_CLASS: uw::_Unwind_Exception_Class = u64::from_be_bytes(*b"MOZ\0RUST"); |
There was a problem hiding this comment.
Pre-existing, but should we really reverse the stored order between little-endian and big-endian systems? We currently show MOZ\0RUST on big-endian systems and TSUR\0ZOM on little-endian systems when interpreted as string/doing a hexdump.
There was a problem hiding this comment.
I noticed that when I poked at it. 👀 It is funny to me. All the other runtimes make the same mistake, so I initially decided not to change it. I think I wanted to actually look at the data through a hex dump before doing so.
There was a problem hiding this comment.
Maybe a relevant datapoint: windows-drivers-rs' wdk-alloc specifically chose u32::from_ne_bytes(*b"rust") for their allocator tag: https://github.com/microsoft/windows-drivers-rs/blob/c3b7c4aa06e43e928f27eb704f76932688802921/crates/wdk-alloc/src/lib.rs#L50
There was a problem hiding this comment.
Maybe it's not a mistake, maybe the type of this should be thought of as [u8; 8] rather than u64 -- with bytes always being interpreted left-to-right no matter the endianess.
There was a problem hiding this comment.
The current impl is a mistake if it should be interpreted as [u8; 8] as currently little endian systems put the string in reverse order, while big endian systems put it in the correct order.
There was a problem hiding this comment.
Oh right, that would have to use from_ne_bytes... then transmuting back to a u8 array would always give the same results.
There was a problem hiding this comment.
i assume it was just someone filling out the u64 literal in left to right order, as the previous comment described.
There was a problem hiding this comment.
cool, I checked the hexdump emitted and yeah, it is indeed backwards on x86-64. silly Rust.
Rollup merge of rust-lang#130381 - workingjubilee:sometimes-code-really-is-self-descriptive, r=Noratrieb library: Compute Rust exception class from its string repr Noticed this awkwardness while scanning through the code. I think we can do better than that.
workingjubilee
deleted the
sometimes-code-really-is-self-descriptive
branch
Noticed this awkwardness while scanning through the code. I think we can do better than that.