On Thursday, 27 July 2017 at 13:56:00 UTC, Steven Schveighoffer
wrote:
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.
Which aren't in the official D spec (or at the very least I can't
seem to find them there).
You don't need C functions to trigger such problems.
Sure, but it was relevant to the previous discussion.
I'm fine with saying libraries or platforms that do not
segfault when accessing zero page are incompatible with @safe
code.
So we can't have @safe in shared libraries on Linux? Because
there's no way for the shared lib author to know what programs
using it are going to do.
And it's on you not to do this, the compiler will assume the
segfault will occur.
It's not a promise the author of the D code can (always) make.
In any case, the @trusted and @safe spec need to be explicit
about the assumptions made.
