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

[Stanislav Blinov]

On Tuesday, 22 February 2022 at 13:13:43 UTC, Paul Backus wrote:
> On Tuesday, 22 February 2022 at 08:47:55 UTC, Stanislav Blinov 
> wrote:
>> A more pertinent example around file descriptors and memory 
>> safety is void-initialization:
>>
>> ```d
>> struct File
>> {
>>     void write(const(void)[] data) @safe;
>>     // ...
>>     private int fd;
>> }
>>
>> void main() @safe
>> {
>>     File f = void; // this compiles in current language, 
>> because `File` doesn't have pointers
>>     f.write("hello"); // may corrupt memory if 
>> (implementation-defined) value of `f.fd` happens to correspond 
>> to an existing mapping
>> }
>> ```
>
> If you attempt to fill in the missing part of your example, I 
> think you will find that you cannot actually demonstrate memory 
> corruption resulting from `void`-initialization of a file 
> descriptor without the use of `@trusted` code (e.g., to cast 
> the `void*` returned from `mmap` to some other type of pointer 
> whose target type has unsafe values).

Yes, the implementation of `File` would need @trusted code. How 
would that invalidate the example?

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.

An fd is an unsafe quantity encoded in a safe type. We need a way 
to express that in the language.