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

d-bugmail at puremagic.com d-bugmail at puremagic.com
Fri Jun 7 00:59:01 UTC 2019


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

--- Comment #23 from Manu <turkeyman at gmail.com> ---
(In reply to Dennis from comment #22)
> (In reply to Manu from comment #18)
> > There is no world where access to
> > what can be confirmed to be uninitialised memory is @safe, period.
> 
> This is just proof by assertion at this point.
> (https://en.wikipedia.org/wiki/Proof_by_assertion)

Correct, well spotted. And nice deployment of big words, I appreciate the handy
link just in case I'm an idiot.


> > Any interaction with uninitialised memory will guarantee unintended
> > consequences, which could be anything.
> 
> Counterexample: just print an uninitialized integer. I can predict the
> consequence pretty well.
> Also: besides the point. @safe != no bugs and union member access !=
> uninitialized memory. (the discussion got a bit derailed, I suggest
> continuing in issue 18016 about `= void` and keeping this to union member
> access)

Union access is void initialisation. All members other than one are invalid in
precisely the same way as that other thread discusses.
Concerns related to validity and language semantic violations are identical.


> > You shouldn't slap it on functions, you should minimise the surface area as
> > much as possible; 
> 
> I agree. Therefore, we shouldn't suddenly reject @safe code that has no
> chance of corrupting memory, because that invites more use of @trusted
> increasing the surface area.

Huh? I don't think you understood what I said... I said to narrow the surface
area; for instance, don't apply it to functions, apply it within functions.

--


More information about the Digitalmars-d-bugs mailing list