Hacker News Reader

Comment by Animats | Hacker News Reader

I tended, in my C++ days, to think that if you need "reinterpret_cast", you're doing it wrong. Now that I code in safe Rust, I still think that.

If you really want to abstract this sort of thing, a good abstraction would be a write-only type, "space", representing memory with no content. Then make it possible to destroy an object and convert it to empty "space", or construct an object on empty "space". This creates a clear distinction between reusing memory and abusing the type system.

View on HN

That mindset is what makes C++ and Rust both sometimes so annoying on embedded targets, if not actively harmful.

I've been left a strong impression that either I do it "safely" or I want to do it totally unsafe, there's often like no middle ground. No I don't want to suddenly accidentally double-dereference a pointer or cast away const, I just want to use this memory mapped peripheral. That is very unfortunate and short-sighted, IMO, considering that layer is where all safety and security begins from.

If you’re dealing with pure data, reinterpret_cast/mem::transmute is fine, and for certain types of low-level code, necessary. In Rust, I’ve recently discovered the “bytemuck” crate, which offers ways to do that safely.

"Pure data" has a very specific meaning there. "Bytemuck" uses the trait called "Pod", for "plain old data". What they mean is a structure for which all bit combinations are valid. This includes u8, u16, etc., and the floating point types, but excludes all reference types. "bool" is excluded (because it takes up 8 bits but only 2 of 256 values are valid), as are strings and chars, because they have to follow Unicode rules. And there must be no padding bytes in the structure.

For types with such attributes, coercions are safe. C++ could potentially have something like "reinterpret_cast" which worked only on such types. This would make the risky form of reinterpret_cast less necessary, and some projects might disallow it.

It's always hard to retrofit safety to a code base. You get a lot of pushback.

C++ had the concept of POD type, but it has been superceded by StandardLayout.

Such an object would be std::byte (and char), but it is still complicated when an (array of) this object is a member of another object. Nailing down the exact semantics has been very hard and compilers have been known to miscompile such code.

I think that the whole object model need to be formalized from scratch (similar to what was done for the concurrent MM) but that's still hard to do while preserving all the properties that current programs expect.

reinterpret_cast comes up a lot when handling binary protocols - e.g. reading a message struct off a buffer / packet. How would this be handled in Rust or otherwise without copying the data?

You can always just create a helper type that wraps the byte range and provides getter/setter functions for the individual fields. There is no need to cast the thing to an actual struct.

That's true, but a lot less convenient and I bet you'll be missing out on a bunch of optimizations if you do that.

In the medium term I'd say it's more likely you miss out on optimizations by not clearly expressing what you actually wanted here.

The more clarity is available as to what you meant, the more aggressive the optimiser can be in delivering precisely that. If you don't express exactly what is intended, the optimisers end up getting muzzled because the effect is so confusing.

What specific optimizations would a wrapper type allow that a accessing directly a pointer to a reinterpret casted, property aligned StandardLayout type would not allow?

The concern I have isn't about optimisations that are impossible but optimisations which are judged unwise and so either disabled by default or not implemented at all.

Maybe reinterpret_cast on StandardLayout with the correct alignment really does express exactly what we want here, I'm not sure. If so you're correct there wouldn't be a difference because a valid optimisation will always be exactly what everybody wanted. But if there are any other uses of these techniques the optimiser has to be pessimistic. That's why I prefer to be as explicit as possible.

This is how so many extra types of cast came into existence in C++ in the first place right, the recognition that casting could have different intents.

> StandardLayout with the correct alignment really does express exactly what we want here, I'm not sure

Surely if you are unsure the default position should be to go to the obvious and simple solution instead of overengineering it? But I might be completely misunderstanding your point.

[If the struct is not correctly aligned, I would either memcpy or apply any required compiler pragmas, while cursing the protocol designer]

In current Rust, you'd do it with an unsafe std::mem::transmute - possibly using a crate that wraps this call behind a safe interface that asserts that alignment and size are correct, and that your type doesn't have any padding, etc... See for instance the bytemuck crate.

In the future, rust might gain "Safe Transmutes", which would allow you to safely transmute from one type to another under some limited conditions. See https://github.com/rust-lang/lang-team/issues/21

The exact same approach as C is doing is possible in Rust. There are pointer casts and mem::transmute(). It does require unsafe, since you must be aware of gotchas with alignment, padding, and uninitialized memory.

If you want to be fancy, there's https://lib.rs/rkyv deserialization framework that will auto-generate appropriate zero-copy code for you.

There's also serde (de)serialization framework and bincode format, which aren't exactly zero-copy, but are fast 1-copy.

I’ve fixed undefined behavior in large C++ code based caused by misaligned reinterpret casts - the solution is to use memcpy

It's such a good idea that they made a special cast that does just that in C++20: https://en.cppreference.com/w/cpp/numeric/bit_cast

And in most cases (at least in optimized builds) the memcpy will be optimized out.

reinterprate_cast has it's place (mainly in the embdedded/kernel/low level software world) but unless you are in one of the fields where it is actually needed (aforementioned places where type punning is just nature of the beast) then there's really not a better alternative.

Now there is: see bit_cast above.

But in fact memcpy to a local is very often a better alternative, pre-C++20. Compilers optimize it away.

It is different though. Bit cast returns a new object, while reinterpret cast is in place. It doesn't matter for small objects, but it can matter for large ones.

If the compiler’s optimization passes determine that the bitcasted-from and bitcasted-to objects are never simultaneously live, then copying can be easily elided.

Usually, you either care about 0-copy, in which case you don't want to rely on "if the compile can tell", or you don't care about 0-copy, in which case it doesn't matter that the compiler did it.

reinterpret_cast guarantees that it is in-place, so it's the right tool for 0-copy.

Or, you check. Elided copy is very rarely UB, something that cannot be said of uses of reinterpret_cast.

You check today. What if tomorrow something changes? What if your network application starts dropping packets because it can't process them fast enough because an apparently unrelated change suddenly messed with a two year old optimization?

Then you fix it. Correct code is rarely hard to make faster.

What when your compiler starts to take advantage of latitude extended by the Standard, leading your program to produce sporadic, non-reproducible wrong results?

It is best not to code any UB. But it is often hard to be certain, around reinterpret_cast.

> Correct code is rarely hard to make faster.

You rarely want to be spending time fiddling with the optimizer. Your code shouldn't rely on the optimizer to be efficient: don't use constructs whose semantics mean you are making a copy in places where you don't want a copy.

reintrepret_cast is hard to use correctly, but you only have to get it right once, and it has the right semantics, so no compiler changes will suddenly make it wrong or slow. memcpy and bit_cast have the wrong semantics, so they may change for unexpected reasons. In fact, it would be perfectly reasonable for a future version of the compiler to never optimize away the copy implied by memcpy and bit_cast.

Determining local variable lifetimes is a fundamental feature of a compiler. Literally any compiler that does register allocation can and will merge local variables that aren't simultaneously live. Because it turns out that the problem of fitting lots of variables into minimum registers is remarkably similar to the problem of fitting lots of variables into minimum registers + minimum stack space.

So yes, you can confidently rely on gcc or clang to merge local variables, even at -O1. If they suddenly don't do that after an update, it's a serious regression, and their mailing lists should be more than happy to receive that bug report.

For local variables. Once you're passing the data around to other functions, the problem becomes much more complex, and it becomes much less clear when and why the compiler will be able to understand what's happening.

Not to mention, in an example like processing packets, the two views of the data WILL be simultaneously live: you're taking raw bytes on one side, interpreting some part of them as a struct to decide what's happening next, then sending the raw bytes somewhere else.

EDIT: Basically the code would look something like this:

  char* buf = new char[100];
  read(buf, sizeof(header));
  header h;
  memcpy(&h, buf, sizeof(header))
  get_destination(h).write(buf);

Will this copy the header or not? How about this?

  char* buf = new char[100];
  read(buf, sizeof(header));
  header *h = reinterpret_cast<header*>(buf); //assume we are compiling with "-fno-strict-alias", and that we know there are no alignment/packing concerns
  get_destination(h).write(buf);

Also note that in C we have a somewhat cleaner solution:

  union buf_header {
    header h;
    char buf[100];
  } buffer;
  read(buffer.buf, sizeof(header));
  get_destination(buffer.h).write(buffer.buf);

This would of course be UB in C++ (reading from a union member that is not the last one written to).

It is perhaps worth noting that G++ specifically provides a C-compatible definition for the final example. As they are allowed to do.

But, assuming header is a standard layout type, the following:

  header h;
  read((char*)&h, sizeof(h));
  get_destination(h).write((const char*)&h, sizeof(h));

Is well defined even under strict aliasing.

(agree about the two views being live at the same time and memcpy being suboptimal here).

The problem is that if you are bitcasting, say, from a memory buffer coming from a read() call it is very hard for the compiler to prove that bitcasted copy is the only live one, especially across function calls.

For small objects bitcast works just fine because the result end up in registers were you would have loaded the original objects anyway.

I think bit_cast may finally solve the last major use case of reinterpret_cast (building type safe memory mapped device objects) but I haven't sat down and tried to verify this yet.

Unfortunately there are also still a lot of platforms that have yet to get C++20 support and memcpy is not a viable alternative. Hopefully this is less of an issue in the future as major MCU orgs like TI have started switching to LLVM/Clang based compilers which can follow upstream with little to no changes needed.

Edit: I just did some digging and bit_cast does not work for the aforementioned use case since it can copy the data to a new location in memory. This prevents us from being able to reliably use it to write to memory registers.

Do you find any issues with Rust that bothers you, as a former C++ developer? I'm still in my C++ days, but I avoid reinterpret_cast, as well as RTTI and C++ exceptions. Looking forward trying out Rust.

The biggest headache I've hit is that you can't have back references. When A owns B, it's really hard to get from B to A. You have to reference count everything, even if B is a field of A.

A key concept in Rust is that no code can have access to two mutable references to the same object at the same time. That's the issue with std::launder, of course. The Rust mechanism for doing it enforces stronger restrictions than absolutely necessary. Not that enforcing the minimal set of restrictions is easy.

The general argument of Rust enthusiasts is that you don't need that. But many of them are writing web back-end stuff, which does not have much state. I'm writing a client for a virtual world, which has an entire visible scene of constantly changing state. Representations for that sort of thing have extensive cross-links. Hammering that into the Rust model tends to result in things such as having to look up things in hashes where you'd use a direct link in C++.

What's desirable is safe single ownership with backlinks. That's hard. You need something like a weak reference to a singly owned object, along with the compile time checking needed to prevent its misuse. Right now, you can do that with reference counted weak links, which are checked at run time. But you're often calling ".borrow()" to follow a link, and that will fail if the mutable borrow count becomes > 1. If that check could be replaced with static analysis by the borrow checker, more safe data structures would be possible. Trees with backlinks, doubly linked lists, etc.

Not having this means you can reach the point where your program is one error away from compiling, and days of rewrite are needed to fix the problem. This is where unsafe code tends to sneak in, as an escape hatch.

I try to avoid circular references in C++ as well, at all cost, in my physics engines and game engines. For example, there is a unidirectional access from World -> Object -> Contact Point -> Vector3 and never the other way around (Vector3 doesn't know about Point, Object or World).

Would Rust allow to have all data in 'structs' (no private data), and make all logic pure functional (functions without side effects, data in, data out)? That way, you won't need circular references or stateful objects and it simplifies memory management.

Some parts of the system map well to a purely functional model, and some don't. The part that decodes incoming messages is almost entirely functional. The part that maintains the scene graph isn't. There's a continual stream of update messages coming in, requests for assets go out, and assets come back. One asset reply may update many objects that use the same mesh or texture, so there's not the one-to-one relationship that an "async" model wants.

Admittedly this is a somewhat unusual application. It's somewhere between writing an MMO client and a web browser. I once wrote a RSS feed reader in Rust, and that didn't have any of these hard problems.

Reply on news.ycombinator.com