Is type punning safe in Odin?

[Robert42]

Do I understand this post correctly, that Odin allows type punning and has (by default^[1]) no strict aliasing rules?

Is it true that Odin can't be as fast as Zig/Rust because all LLVM optimizations aren't possible?

TL;DR the original comment is not true and mostly just out of date. I’ll break down this original Reddit comment to show it doesn’t really make much sense. Bounds checking enabled by default. Yes and that has the possibility of being optimized too. Even when it is disabled, Odin explicitly does not use all of the llvm’s optimizations because they either don’t fit Odin’s model, or rely on some sort of UB. This is has NOTHING to do with bounds checking. It’s a really weird non-sequitur. …

Relevant part of Bill’s post:

[…] My philosophy for Odin was that you want to opt-in to the generally unsafe “optimizations” (when possible) rather than them be opt-out, especially when the language/compiler does not enforce stricter semantic analysis. […]

Do I interpret this correctly that Odin allows^[1:1] type punning via both, pointer casts & #raw_union?

In other words:

• Can I happily cast any pointer type to any another pointer type and rely on the Odin compiler to behave as if I compiled the equivalent C/C++ code with -fno-strict-aliasing?
• Likewise, can I use type punning with #raw_union and happily access any field independent on which field was previously written to it?

I am aware that for many real-world usecases the transmute operator is what I probably want. But I it’s just nice to have straight forward type-punning in my toolbox and treat bytes just as bytes with interpretation, not part of some abstract objects.

---

1. as long as I don’t use #no_alias ↩︎ ↩︎

[gingerBill]

• Odin does effectively have -fno-strict-aliasing.
• Prefer transmute over #raw_union because it is easier in most cases. You can use it, but in Odin, it’s rarely the prefer approach. You can think of transmute as memcpy because it also cares about the alignment too.