On Tuesday, 25 July 2017 at 20:16:41 UTC, Steven Schveighoffer
wrote:
On 7/25/17 2:36 PM, Moritz Maxeiner wrote:
On Tuesday, 25 July 2017 at 18:07:06 UTC, Steven Schveighoffer
wrote:
On 7/25/17 12:14 PM, Kagamin wrote:
While we're at it, check this:
https://github.com/dlang/druntime/blob/master/src/core/stdc/stdio.d#L1047
Looks fine to me. That's not an array of FILE, it's a single
pointer.
fgetc cannot be @trusted the same way fclose cannot be
@trusted.
If you pass either of them `null` - which constitutes a legal
@safe context - the behaviour is undefined, which contradicts
@trusted definition:
<Trusted functions are guaranteed by the programmer to not
exhibit any undefined behavior if called by a safe function.>
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).
This is par for the course in @safe land -- dereferencing null
pointers is OK.
In D land we require null dereferences to crash.
That means - from a strict, pedantic standpoint - that while it's
OK to attribute D functions with null dereferences as @trusted,
the same can't be said for C functions with null dereferences.
