On 7/27/17 9:24 AM, Moritz Maxeiner wrote:
On Wednesday, 26 July 2017 at 01:09:50 UTC, Steven Schveighoffer wrote:
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.
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.
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.
--- 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
Consider `mmapNull` being run in some third party shared lib you don't
control.
Again, all these hacks are just messing with the assumptions D is
making. You don't need C functions to trigger such problems. I'm fine
with saying libraries or platforms that do not segfault when accessing
zero page are incompatible with @safe code. And it's on you not to do
this, the compiler will assume the segfault will occur.
-Steve
