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

d-bugmail at puremagic.com d-bugmail at puremagic.com
Wed Jun 5 13:32:43 UTC 2019


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

--- Comment #17 from Dennis <dkorpel at live.nl> ---
(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! 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'.

> For instance, there's C libraries that return opaque handles that may or may
> not be actual pointers, and that offer no way to determine if such a handle
> is valid or not, and may summon nasal demons if invalid handles are used.

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.

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

[1]
https://github.com/d-gamedev-team/gfm/blob/5b86c52582de04b8b2277a3b257507083ed31cbf/math/gfm/math/vector.d#L26

--


More information about the Digitalmars-d-bugs mailing list