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

d-bugmail at puremagic.com d-bugmail at puremagic.com
Thu Jun 6 18:22:53 UTC 2019


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

--- Comment #22 from Dennis <dkorpel at live.nl> ---
(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)

> 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)

> I don't understand any sentence in this paragraph.

Simen argued union access must be unsafe or else this doesn't work:
```
struct S
{
  private int myHandle; // no touchy!
  @disable this();
  this(int x) {myHandle = getValidHandle();}
  void doSomethingSafe() @trusted {unsafeCfunction(myHandle);}
}
```
I say:
- it's not necessary, just give S a pointer member
- it's not sufficient, __traits(getMember, S, "myHandle") = 0xFFFF; will break
it anyway.

> 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.

--


More information about the Digitalmars-d-bugs mailing list