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