Discussion Thread: DIP 1035-- at system Variables--Community Review Round 1

[Andrei Alexandrescu]

On 6/17/20 12:39 PM, jmh530 wrote:
> On Wednesday, 17 June 2020 at 15:58:01 UTC, Dennis wrote:
>> [snip]
>> This DIP *is* a fix for those bugs, for which there is no obvious 
>> solution. The idea is to have a consistent design, instead of having a 
>> list of small enhancements and hole plugs that are half-baked. Notice 
>> the trend here:
>> - https://issues.dlang.org/show_bug.cgi?id=18554 (does not solve 
>> union/array casts, undone by 15371, spawns your issue)
>> - https://issues.dlang.org/show_bug.cgi?id=19646 (incomplete solution, 
>> spawns 20347)
>> - https://issues.dlang.org/show_bug.cgi?id=19968 (incomplete solution, 
>> spawns 20148)
>>
>> So let's say we fix those second round bugs like you suggest, which I 
>> will call 'bug fix':
>> [snip]
> 
> I think it can't hurt to emphasize in the DIP that even if issue 20347 
> is fixed, then it would only mean that the global variable would still 
> be @system. For instance, the DIP example for getPtr could be changed to 
> below and still not generate an error. Fixing 20347 would just mean that 
> you cannot make the initialization of x @safe.
> 
> auto getPtr() @system {return cast(int*) 0x7FFE_E800_0000;}
> 
> @system int* x = getPtr();
> 
> void main() @safe {
>      int y = *x; // = 3; // memory corruption
> }

Simply and powerfully put, a piece of data with indirections that 
originated in @system code could force @safe code to do unsafe things. 
It took me a while to figure this may be the main argument for the 
feature. A comparison with tainted would be very helpful.