all OS functions should be "nothrow @trusted @nogc"

Andrei Alexandrescu via Digitalmars-d digitalmars-d at puremagic.com
Tue Jul 25 08:26:35 PDT 2017


On 07/25/2017 10:43 AM, ag0aep6g wrote:
> On 07/25/2017 04:32 PM, Shachar Shemesh wrote:
>> And, indeed, the code calling "read" shouldn't be able to do that as 
>> @safe. Read itself, however, is trusted (because, let's face it, if 
>> you cannot trust the kernel, you're screwed anyways).
> 
> That's not how `@trusted` works. The point of `@trusted` is to allow 
> unsafe features in the implementation. The interface must be just as 
> safe as with `@safe`.
> 
> `read` doesn't have a safe interface. `read` is safe as long as long as 
> you pass good arguments. When you pass bad arguments, `read` will break 
> your stuff. A `@trusted` function must always be safe, no matter the 
> arguments.

About http://man7.org/linux/man-pages/man2/read.2.html, there's just a 
bit of wrapping necessary:

nothrow @trusted @nogc
ssize_t read(int fd, ubyte[] buf)
{
     return read(fd, buf.ptr, buf.length);
}

(btw void[] doesn't work)

The point being that a safe D program needs to guarantee memory will not 
be corrupted, and there's no way for the type system to ensure that in 
the Posix read() call the buffer and the length are coordinated.

Certain systems (such as the static checker used at Microsoft - it's 
fairly well known, there are a couple of papers on it, forgot the name) 
require annotations in the function signature to indicate the 
coordination, e.g.:

ssize_t read(int fd, void *buf, @islengthof(buf) size_t count);

Then the type checker can verify upon each call that indeed count is the 
right size of buf.

A suite of safe wrappers on OS primitives might be useful.


Andrei


More information about the Digitalmars-d mailing list