[Issue 19916] union member access should be un- at safe

[d-bugmail at puremagic.com]

https://issues.dlang.org/show_bug.cgi?id=19916

--- Comment #19 from ag0aep6g <ag0aep6g at gmail.com> ---
(In reply to Dennis from comment #17)
> If you don't agree with the 'insufficient to corrupt memory' regime, please
> propose a new one! The spec is pretty informal currently. If you have a
> better interpretation, I'm eager to hear it. So far I've only heard 'things
> any sane security engineer is wary of'.

Per the spec (<https://dlang.org/spec/function.html#function-safety>), @safe
functions "are functions that are statically checked to exhibit no possibility
of undefined behavior".

I suppose that's equivalent to "doesn't corrupt memory". Memory corruption is
always a symptom of undefined behavior, and there is no kind of undefined
behavior that doesn't potentially lead to memory corruption (or it wouldn't
really be UB).

I prefer focusing on undefined behavior, though. It feels more more clear cut
to me. When the spec says that something has UB, then it can't be in @safe.
Period.

Otherwise, when the focus is on memory corruption, there's more (perceived)
wiggle room. We're tempted to allow anything that doesn't lead to memory
corruption in practice, even if has undefined behavior. That quickly gets
messy.


(In reply to Manu from comment #18)
> Uninitialised memory is ALREADY CORRUPTED. There is no world where access to
> what can be confirmed to be uninitialised memory is @safe, period.
> 
> Any interaction with uninitialised memory will guarantee unintended
> consequences, which could be anything.
> 
> It's very simple; if you're going to use unions, or uninitialised memory,
> then do so carefully, and @trusted that block of code.

You might want to argue your position in
<https://github.com/dlang/dlang.org/pull/2260>. It's an open PR by Walter where
he does exactly what you oppose here: he wants to explicitly allow accessing
uninitialized memory in @safe code (unless it involves pointers).

--