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

[Moritz Maxeiner via Digitalmars-d]

On Tuesday, 25 July 2017 at 14:32:18 UTC, Shachar Shemesh wrote:
> On 25/07/17 17:11, ag0aep6g wrote:
>> On 07/25/2017 03:50 PM, Shachar Shemesh wrote:
>>> The title really does says it all. I keep copying OS function 
>>> declarations into my code, just so I can add those attributes 
>>> to them. Otherwise I simply cannot call "signalfd" and 
>>> "sigemptyset" (to name a couple from my most recent history) 
>>> from @safe code.
>> 
>> Not all OS functions can be `@trusted`.
>> 
>> I don't about `signalfd` and `sigemptyset`, but `read` [1] 
>> can't be `@trusted`, for example. It takes pointer and length 
>> separately, and the pointer is a `void*`. That's not safe at 
>> all.
>
> And, indeed, the code calling "read" shouldn't be able to do 
> that as @safe. Read itself, however, is trusted

No, it is not, because it does not fulfill the definition of 
@trusted (callable from *any* @safe context without allowing 
memory corruption).

> (because, let's face it, if you cannot trust the kernel, you're 
> screwed anyways).

This has nothing to do with trusting the kernel:
---
char[1] buf;
int dontCorruptMePlease;
read(fd, &buf[0], 10);
---
The read implementation can't verify the buffer size, it must 
assume it to be correct. If it's too large  for the actual buffer 
-> memory corruption.
No function taking pointer+size of pointed to (that accesses 
them) can be @trusted.

> Having said that, I have no objection to excluding the 
> "pointer+length" system calls from the above rule. They are, by 
> far, the minority of system calls.

And also happen to be the most used ones.
But I digress, the point is *every single functionust be verified 
for every single Attribute* (other than nothrow).
PRs are welcome :)