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

[Stanislav Blinov]

On Tuesday, 22 February 2022 at 18:33:58 UTC, Paul Backus wrote:
> On Tuesday, 22 February 2022 at 17:29:46 UTC, Stanislav Blinov 
> wrote:

>> 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 you're going to go there, then...

> 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;
> }

...that @trusted code is incorrect, at least on some platforms 
(yes, I can nitpick too). Or we can simply agree that 
`File.write` is implemented correctly in terms of `write` (which 
is the important part) and leave it at that, as the rest is 
irrelevant to the example. I am seriously perplexed at this kind 
of nitpicking, not to mention the implied expectation of having 
to spell out full-blown libraries in an example code.

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

I am reasonably certain that the results may be much more varied 
than that, including some that aren't specified:

https://pubs.opengroup.org/onlinepubs/9699919799/functions/write.html

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

Not exhaustive:
It may corrupt a given GC's implementation's heap, which means 
what occurs after the } is anyone's guess.
It may mutate data that's supposed to be immutable (i.e. in a 
parent process, though you could argue that might not be relevant 
to the DIP).
It may block indefinitely, or crash, or complete with no effect.

If you could demonstrate that it cannot possibly exhibit at least 
the above, I'll happily accept being mistaken.

...but seriously. What is it with all the condescending tone on 
the forums lately?