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. This is par for
the course in @safe land -- dereferencing null pointers is OK.
What is not defined is to fclose a file, and then use that FILE * in any
way afterwards without reassigning.
Note that @safe functions don't make any guarantees once you pass in an
invalid (except for null) or dangling pointer. However, if you are using
only @safe code, you shouldn't be able to make one of these either.
Hence fclose is not @safe or @trusted.
The one case where this fails is for a null pointer to a very very large
struct that has a way to reference data outside the protected page. I
have proposed in the past a way to protect against this, but it didn't
gain any traction.
-Steve
