Getting action on your favorite D issues
Steven Schveighoffer
schveiguy at gmail.com
Sat Jun 6 21:01:05 UTC 2020
On 6/6/20 12:54 PM, Joseph Rushton Wakeling wrote:
> On Saturday, 6 June 2020 at 16:48:56 UTC, Steven Schveighoffer wrote:
>> int x = void;
>>
>> Does not and cannot corrupt memory (assuming everything that uses it
>> is @safe).
>
> Yes, which is presumably why the other example above -- using the wrong
> accessor of a union -- is also allowed in @safe code ... ?
There are two things here:
1. using the value of a union that was not set in @safe code can lead to
corruption *easily*. Consider a union with perfectly overlapping fields,
that are not pointers. The individual fields could have (possibly UFCS)
trusted semantics that are invalid when you arbitrarily set the data.
2. The compiler cannot be made to detect when this happens (halting
problem).
So we have two options I can see:
1. declare that unions are not accessible in @safe, period. This would
be a huge breaking change, but would be a correct distinction. You would
have to mark all such code @trusted.
2. Somehow mark that unions with further semantic @safe guarantees are
not allowed in @safe code. This could be a possible compromise that
allows using unions still in @safe code.
The talk proposal I was going to submit this year was going to be very
much about this problem.
> That said, the definition of a safe interface is, according to spec,
> that it exhibits no undefined behaviour:
> https://dlang.org/spec/function.html#safe-interfaces
>
> Don't using void-initialized variables or the wrong accessors of a union
> both count as undefined behaviour, even if they are memory-safe?
Yes, either the spec or the behavior definition needs to be adjusted.
-Steve
More information about the Digitalmars-d
mailing list