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

d-bugmail at puremagic.com d-bugmail at puremagic.com
Wed Jun 5 18:42:29 UTC 2019


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

--- Comment #18 from Manu <turkeyman at gmail.com> ---
(In reply to Dennis from comment #17)
> (In reply to Simen Kjaeraas from comment #16)
> > There's code that simply cannot be @trusted under Dennis' @safe regime that
> > would be perfectly safe without void initialization and union member access.
> 
> If you don't agree with the 'insufficient to corrupt memory' regime, please
> propose a new one!

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.


> Then store that handle as a void* or make it absolutely inaccessible from
> the outside. Disabling @safe union access of non-pointers is neither
> necessary nor sufficient to prevent invalid handles to be passed to your C
> library. The constraint 'I only want integer members in my struct with
> @trusted memory sensitive data' is completely arbitrary and only exists in
> an attempt to validate this issue.

I don't understand any sentence in this paragraph.


> > Also, unions are really a low-level trick that is very rarely used.
> 
> How do you know? I use them in @safe code. GFM (which is downloaded 31739
> times at the time of writing) uses them for their vectors [1] among other
> things. Any formerly safe game using GFM vectors needlessly breaks! And the
> quick fix will be to slap @trusted labels in every function where vector
> members are accessed. How is that for memory safety?

It's an explicit statement that you considered and correctly handled the issues
of interacting with unsafe low-level machinery.
You shouldn't slap it on functions, you should minimise the surface area as
much as possible; perhaps higher-level functions should access the unsafe shit
through small helpers. Maybe use a tagged-union helper, etc.

--


More information about the Digitalmars-d-bugs mailing list