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