[Issue 19916] union member access should be un-@safe (page 3)

https://issues.dlang.org/show_bug.cgi?id=19916 --- Comment #21 from ag0aep6g <ag0aep6g@gmail.com> --- (In reply to Manu from comment #20) > T x = void; // <- DOES lead to memory corruption; it's effectively an explicit statement to do memory corruption. How could a more explicit violation of @safe exist, no matter how you squint and interpret it? > I don't care strongly either way. You'll have to convince Walter. [...] > > 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). > > That PR doesn't appear to have anything to do with @safe? But it clearly does. It resolves issue 18016 which is about accessing void initialized memory in @safe code. With the PR, the spec will allow that. DMD already allows it (in conflict with the current spec). --

https://issues.dlang.org/show_bug.cgi?id=19916 --- Comment #22 from Dennis <dkorpel@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. --

June 07, 2019

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

Posted by Manu

Permalink

Manu

Permalink

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

--- Comment #23 from Manu <turkeyman@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.

--

https://issues.dlang.org/show_bug.cgi?id=19916 anonymous4 <dfj1esp02@sneakemail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also|https://issues.dlang.org/sh | |ow_bug.cgi?id=20655, | |https://issues.dlang.org/sh | |ow_bug.cgi?id=21561, | |https://issues.dlang.org/sh | |ow_bug.cgi?id=21565 | Depends on| |20655, 21561, 21565 Referenced Issues: https://issues.dlang.org/show_bug.cgi?id=20655 [Issue 20655] [REG: 2.072] attribute inference accepts unsafe union access as @safe https://issues.dlang.org/show_bug.cgi?id=21561 [Issue 21561] Unsafe aliasing of immutable union member allowed in @safe code https://issues.dlang.org/show_bug.cgi?id=21565 [Issue 21565] @safe code allows modification of a scalar that overlaps with a pointer --

https://issues.dlang.org/show_bug.cgi?id=19916 Iain Buclaw <ibuclaw@gdcproject.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Priority|P1 |P4 --

Forums