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

[Paul Backus]

On Tuesday, 22 February 2022 at 17:29:46 UTC, Stanislav Blinov 
wrote:
> On Tuesday, 22 February 2022 at 16:16:30 UTC, Paul Backus wrote:
>> 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?

The example, as written, does not link, because `File.write` is 
missing a function body. If I fill in the obvious implementation, 
I get the following program:

```d
struct File
{
     void write(const(void)[] data) @safe
     {
         import core.sys.posix.unistd: write;
         () @trusted { write(fd, data.ptr, data.length); }();
     }
     private int fd;
}

void main() @safe
{
     File f = void;
     f.write("hello");
}
```

The above program does not have undefined behavior. The call to 
`write` will either fail with `EBADF`, or attempt to write the 
string `"hello"` to some unspecified open file.

If you believe there is some way to get the above program to 
produce undefined behavior, or to complete your original example 
in such a way that it produces undefined behavior without the use 
of incorrect `@trusted` code, I'm afraid you will have to spell 
it out for me.