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

[Moritz Maxeiner via Digitalmars-d]

On Thursday, 27 July 2017 at 13:45:21 UTC, ag0aep6g wrote:
> On 07/27/2017 03:24 PM, Moritz Maxeiner wrote:
>> --- null.d ---
>> version (linux):
>> 
>> import core.stdc.stdio : FILE;
>> import core.sys.linux.sys.mman;
>> 
>> extern (C) @safe int fgetc(FILE* stream);
>> 
>> void mmapNull()
>> {
>>      void* mmapNull = mmap(null, 4096, PROT_READ | PROT_WRITE, 
>> MAP_PRIVATE | MAP_ANONYMOUS | MAP_FIXED | MAP_POPULATE, -1, 0);
>>      assert (mmapNull == null, "Do `echo 0 > 
>> /proc/sys/vm/mmap_min_addr` as root");
>>      *(cast (char*) null) = 'D';
>> }
>> 
>> void nullDeref() @safe
>> {
>>      fgetc(null);
>> }
>> 
>> void main(string[] args)
>> {
>>      mmapNull();
>>      nullDeref();
>> }
>> ---
>> 
>> For some fun on Linux, try out
>> # echo 0 > /proc/sys/vm/mmap_min_addr
>> $ rdmd null.d
>
> The gist of this is that Linux can be configured so that null 
> can be a valid pointer. Right?

In summation, yes. To be technical about it:
- Linux can be configured so that the bottom page of a process' 
virtual address space is not protected from being mapped to valid 
memory (by default, `mmap_min_addr` is 4096, i.e. the bottom page 
can't be mapped)
- C's `NULL` is in pretty much all implementations (not the C 
spec) defined as the value `0`, which corresponds to the virtual 
address `0` in a process, i.e. lies in the bottom page of the 
process' virtual address space
- The null dereference segmentation fault on Linux stems from the 
fact that the bottom page (which `NULL` maps to) isn't mapped to 
valid memory
- If you map the bottom page of a process' virtual address space 
to valid memory, than accessing it doesn't create a segmentation 
fault

>
> That seems pretty bad for @safe at large, not only when C 
> functions are involved.

Yes:
- In C land, since derefencing `NULL` is UB by definition, this 
is perfectly valid behaviour
- In D lang, because we require `null` dereferences to crash, we 
break @safe with it