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

[Steven Schveighoffer via Digitalmars-d]

On 7/26/17 12:08 PM, Patrick Schluter wrote:
> 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).

I'm guessing though that it's an implementation detail (like Walter's 
DMC example). A segfault is fine, and returning an error is fine. Both 
will properly be handled, and do not cause UB.

So I guess I should restate that we can assume no implementations exist 
that intentionally cause UB when stream is NULL (as in Timon's example). 
Either they check for null, and handle gracefully, or don't check and 
segfault.

What I was talking about is platforms that don't segfault on 
reading/writing from the zero page. Those we couldn't support with @safe 
D anyway.

-Steve