all OS functions should be "nothrow @trusted @nogc"

[Steven Schveighoffer via Digitalmars-d]

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