4 ms·

Rust structs have non-C layouts. You can optionally specifiy that a struct should be laid out in the same way that C does it.

by nynx 4y ago

ncmncm 4y ago
People arguing against changing struct layout rules are probably mainly interested, then, in maintaining backward compatibility with older Rust, itself. Anyway, same policy applies: annotate your structs "packed" anywhere performance matters and bitwise compatibility with other stuff doesn't.
- deleted 4y ago
  [deleted]
- zozbot234 4y ago
  Rust does not keep backward compatibility like that. In the absence of any statement forcing a specific ABI, the only guaranteed compatibility is with code that's part of the same build, or else part of the current Rust runtime and being linked into said build.
  - ncmncm 4y ago
    Even in Rust, mapping memory between processes, or via files between past and future processes, happens. Although structure-blasting is frowned upon in some circles, it is very fast where allowed. But... when you are structure-blasting, you are probably also already paying generous attention to layout issues.
notriddle 4y ago
Structs aren’t the problem here. It’s the primitives. You can take a pointer to an i32 and pass that pointer to C code as int32_t. This means it has to have the same alignment in Rust that it has in C.
- ncmncm 4y ago
  The topic at hand is, specifically, that nobody makes cores that enforce alignment restrictions anymore. So, it doesn't matter where the pointer goes. All that matters is if your compiler lays out its structs the same way as whoever compiled the code a pointer to one ends up in. There are embedded targets that still enforce alignment restrictions, but you are even less likely to pass pointers between code compiled with different compilers, there.
  - notriddle 4y ago
    > The topic at hand is, specifically, that nobody makes cores that enforce alignment restrictions anymore. So, it doesn't matter where the pointer goes. Compilers can rely on alignment even if the CPU doesn't. LLVM does, which is why older versions of rustc had segfaults when repr(packed) used to allow taking references. While it would be pretty easy to get rustc to stop emitting aligned loads, getting Clang and GCC to stop emitting aligned loads might be trickier. https://github.com/rust-lang/rust/issues/27060 https://github.com/rust-lang/rust/issues/27060

Rust structs have non-C layouts. You can optionally specifiy that a struct should be laid out in the same way that C does it.

by nynx 4y ago

Rust structs have non-C layouts. You can optionally specifiy that a struct should be laid out in the same way that C does it.

ncmncm 4y ago

People arguing against changing struct layout rules are probably mainly interested, then, in maintaining backward compatibility with older Rust, itself. Anyway, same policy applies: annotate your structs "packed" anywhere performance matters and bitwise compatibility with other stuff doesn't.

deleted 4y ago
[deleted]
zozbot234 4y ago
Rust does not keep backward compatibility like that. In the absence of any statement forcing a specific ABI, the only guaranteed compatibility is with code that's part of the same build, or else part of the current Rust runtime and being linked into said build.
- ncmncm 4y ago
  Even in Rust, mapping memory between processes, or via files between past and future processes, happens. Although structure-blasting is frowned upon in some circles, it is very fast where allowed. But... when you are structure-blasting, you are probably also already paying generous attention to layout issues.

notriddle 4y ago

Structs aren’t the problem here. It’s the primitives. You can take a pointer to an i32 and pass that pointer to C code as int32_t. This means it has to have the same alignment in Rust that it has in C.

ncmncm 4y ago
The topic at hand is, specifically, that nobody makes cores that enforce alignment restrictions anymore. So, it doesn't matter where the pointer goes. All that matters is if your compiler lays out its structs the same way as whoever compiled the code a pointer to one ends up in. There are embedded targets that still enforce alignment restrictions, but you are even less likely to pass pointers between code compiled with different compilers, there.
- notriddle 4y ago
  > The topic at hand is, specifically, that nobody makes cores that enforce alignment restrictions anymore. So, it doesn't matter where the pointer goes. Compilers can rely on alignment even if the CPU doesn't. LLVM does, which is why older versions of rustc had segfaults when repr(packed) used to allow taking references. While it would be pretty easy to get rustc to stop emitting aligned loads, getting Clang and GCC to stop emitting aligned loads might be trickier. https://github.com/rust-lang/rust/issues/27060 https://github.com/rust-lang/rust/issues/27060