Awhile back, I wrote some C# code that interacts with C/C++ code by reading struct layouts directly. This is unsafe because C structs don't have guaranteed layouts unless you use nonstandard pragmas. So I had the C code bypass regular struct {} and lay out data manually by pointer arithmetic, making it consistent and safe. This worked great, until I discovered that booleans are a different size in C and C++. I fixed this too, but only by doing horrible things I'm only 95% certain actually worked
0 Boosts
0 Likes
@mcc one day someone will invent a C compiler that lets you write C and native Rust together and they will call it Crust
And then... no one will be laughing anymore
@brandonscript this would make me sad
@mcc to be fair if you want layout to be predictable in rust you also need to use C rules...
@mcc The problem is your code won't work on a PDP-10 or a DEC Alpha.
@TomF I DO NOT CARE ABOUT THIS! However I am somewhat concerned that my Rust code cannot practically speaking be run on various Motorola 680X0 systems I care about
@mcc Interesting! Why is that? I know 68k, but clearly there's a Fun Fact about Rust I'm missing.
@TomF 1. Rust is… not very good… at handling 16-bit pointers. I'm not saying it can't do it, just that Rust is mostly made up of mechanisms to make sure The Assumptions Are Never Broken and "pointers are at least 32 bits" is an assumption that is not checked.
2. Rust is *heavily* dependent on LLVM. There are non-LLVM backends but they're experimental at best. LLVM does not see why it should put effort into supporting build products for Macintoshes older than the year 2000.
I'm thinking about this because I'm having to add to that code right now and it's miserable. I'm not sure why I'm telling you this. I guess I want to stress there are reasons I'm now on team "Nothing but Rust. Nothing but Rust forever. No more C/C++. Rust. What? Okay, Go or Zig are probably fine. Just no C"