This is a simple use after free on the stack. Is that UB?
2. Odin 0s out memory when declaring a variable unless you explicitly state so with ---. This defines the state of memory when allocated.
Odin's decision to zero initialize local variables isn't relevant here.
I didn't fully flesh out the initializing local variables: What part of your code is undefined? You deleted the memory, and the compiler reused it. Then you re-accessed that same memory. That's just part of working with computers. The initialization comment was supposed to be from creating data to releasing it is defined. To be compliant with the Odin compiler spec, it's defined from start to end.
> What part of your code is undefined?
Using a variable (`some_map` in this case) after `delete`ing it doesn't seem something languages usually define in their specification. Does Odin define that?
This Odin feature flag just allows me to write what I meant in Odin, I can write it all out by hand using make and so on without the feature flag, but it's more annoying to spell that all out which presumably was the impetus for this feature flag in the first place. The flag didn't somehow "cause" the unsafety, that's an insane take.
Odin isn't very well documented, so as somebody who was writing Odin just to explain the problem here, the easier option avoids trying to guess which of a dozen undocumented functions with names that may be related to hash maps is the "right" function to do what I meant, I can just write what I meant and turn on the feature flag to acknowledge that it involved allocation.
This is a deliberate HN behaviour to discourage frantic conversations, like you might have if this was a Zoom call for example, or we'd had this disagreement in a bar (presumably a bar where there's a Compiler Explorer built in, or maybe literally Matt Godbolt is sat there with a laptop?)
Maybe it works? I have had some positive experiences.
If you know unsafe Rust the comparison to this Odin feature feels odd, but OK. Surely the Odin feature is more like when let-chains was unstable but you could tell the Rust nightly compiler you want that feature anyway ? Or... explicit_tail_calls which gives you a way to write explicit tail calls† in nightly Rust ?
† This is a very cool feature if you're a functional programmer using the "become" keyword, you get tail call optimisation but it's mandatory, if what you've written can't work as a tail call then it won't compile, if it could work it does.