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

[Paul Backus]

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.

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

[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. Aliasing an fd does not, by itself, constitute memory 
corruption.

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".)