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.
