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 isn’t this what protobuf and frens are for..?
@beatrix *thinks*
Actually… I think protobuf would be a good fit for our situation. I'm not sure why we didn't go with protobuf. I think maybe it's because I thought our needs were simple and protobuf was complicated, but our needs have grown more complex since this project was started.
I just asked the "client", who says that they've actually surveyed C# implementations of Protobuf and as of last survey they all seem to be very hard to use compared to how easy serialization normally is in C#.
@mcc “C structs don’t have guaranteed layouts”
So how does repr(C) work, then? Does it only work with a specific set of compilers? Is it based on platform conventions?
@bytex64 I may be about to say something horribly wrong, but the thing about repr(C) is that it guarantees you are using the same layout as the platform's standard C layout, but DOES NOT convey any information about what this platform is. This means repr(C) can talk to repr(C) but neither one can totally reliably talk to C# which is using pure pointer manipulation.
P/Invoke *can* talk to repr(C)… unless you fall into the hole with the disaster around boolean sizes.
@dotstdy @bytex64 Okay so on the one hand you are entirely right, but on the other hand: Microsoft, creator of this problem, is both the platform defining body who decides the ABI the C compilers are downstream from, AND the author of the currently most common compiler on the platform, AND the body who both defined and implemented the entire C# language
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"
@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.
@mcc coders, is this what coding is like?