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

[Patrick Schluter via Digitalmars-d]

On Wednesday, 26 July 2017 at 01:09:50 UTC, Steven Schveighoffer 
wrote:
> On 7/25/17 8:45 PM, Timon Gehr wrote:
>> On 26.07.2017 02:35, Steven Schveighoffer wrote:
>>> On 7/25/17 5:23 PM, Moritz Maxeiner wrote:
>>>> On Tuesday, 25 July 2017 at 20:16:41 UTC, Steven 
>>>> Schveighoffer wrote:
>>>>> The behavior is defined. It will crash with a segfault.
>>>>
>>>> In C land that behaviour is a platform (hardware/OS/libc) 
>>>> specific implementation detail (it's what you generally 
>>>> expect to happen, but AFAIK it isn't defined in official 
>>>> ISO/IEC C).
>>>
>>> In cases where C does not crash when dereferencing null, then 
>>> D would not crash when dereferencing null. D depends on the 
>>> hardware doing this (Walter has said so many times), so if C 
>>> doesn't do it, then D won't. So those systems would have to 
>>> be treated specially, and you'd have to work out your own 
>>> home-grown mechanism for memory safety.
>> 
>> What Moritz is saying is that the following implementation of 
>> fclose is correct according to the C standard:
>> 
>> int fclose(FILE *stream){
>>      if(stream == NULL){
>>          go_wild_and_corrupt_all_the_memory();
>>      }else{
>>          actually_close_the_file(stream);
>>      }
>> }
>
> I think we can correctly assume no fclose implementations exist 
> that do anything but access data pointed at by stream. Which 
> means a segfault on every platform we support.

What a luck that Solaris/SPARC is not supported as on that 
platform fclose(NULL) and even close(-1) do not segfault. Had to 
learn it the hard way when we ported our project from 
Solaris/SPARC to Linux/x86_64. It was surprizing how often that 
(wrong) behavior happenned in our code base (100K line of C).

>
> On platforms that may not segfault, you'd be on your own.
>
> In other words, I think we can assume for any C functions that 
> are passed pointers that dereference those pointers, passing 
> null is safely going to segfault.
Dereferencing NULL pointer on Solaris/SPARC segfaults but 
fclose() does apparently not dereference blindly the passed 
pointer. I suspect that SUN intentionnally reduced the 
opportunities to segfault on a lot of system calls and libs. The 
port to Linux revealed several violations (stale pointer usage, 
double frees, buffer overflows) that never triggered on Solaris 
and the project is more than 20 year old.

>
> Likewise, because D depends on hardware flagging of 
> dereferencing null as a segfault, any platforms that *don't* 
> have that for C also won't have it for D. And then @safe 
> doesn't even work in D code either.
>
> As we have good support for different prototypes for different 
> platforms, we could potentially unmark those as @trusted in 
> those cases.
>