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

Moritz Maxeiner via Digitalmars-d digitalmars-d at puremagic.com
Tue Jul 25 14:23:52 PDT 2017


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.


More information about the Digitalmars-d mailing list