Discussion Thread: DIP 1035-- at system Variables--Final Review

[Stanislav Blinov]

On Tuesday, 22 February 2022 at 16:16:30 UTC, Paul Backus wrote:
> On Tuesday, 22 February 2022 at 15:55:16 UTC, Stanislav Blinov 
> wrote:
>>
>> Yes, the implementation of `File` would need @trusted code. 
>> How would that invalidate the example?
>
> If completing the example required *incorrect* use of 
> `@trusted` (i.e., on a function that does not have a [safe 
> interface][1]), it would not be valid.

It doesn't. The program, as presented, is enough.

> Using `@trusted` in the implementation of `File.write` to call 
> POSIX `write` would not be a problem.

More the reason for me to not understand the objection then.

> [1]: https://dlang.org/spec/function.html#safe-interfaces
>
>> Your process can inherit fds from its parent. Or you may have 
>> pipes, shared memfds, sockets. Plenty of ways of obtaining a 
>> valid fd without requiring any casts OR having to deal with 
>> pointers. The example shows a way to (unintentionally) alias 
>> an existing fd (obtained through whichever means) and write to 
>> it, in @safe context.
>
> The example shows a write to an fd, and then hand-waves about 
> how this could maybe, hypothetically, somehow, cause memory 
> corruption.

I don't follow. It seems pretty clear to me how the example is 
expressed. Where's the handwaving? Compare to this:

```d
void main() @safe {
     char[5]* ptr = void;
     *ptr = "hello";
}
```

The above won't compile, since void-initialization of pointers is 
not allowed in @safe code, with good reason. Is there anything to 
handwave here? The fd example, however, *will* compile in current 
language, despite doing the same thing.

> Aliasing an fd does not, by itself, constitute memory 
> corruption.

I did not say it did. Writing to an fd initialized with 
"implementation-defined" (read: garbage) value may - that's what 
I said, and that's what the example shows.

> Remember, if you can cause memory corruption in `@safe` code, 
> that means you can also cause undefined behavior in `@safe` 
> code. So if you cannot write a program that uses this alleged 
> loophole to cause UB, then what you have found is not actually 
> memory corruption. (Although it may still be "data corruption".)

You *can* write such a program with fds. The example is one such 
program. Do you have any suggestions on how to make it clearer?