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

[Steven Schveighoffer via Digitalmars-d]

On 8/1/17 6:17 PM, Moritz Maxeiner wrote:
> On Tuesday, 1 August 2017 at 21:59:46 UTC, Steven Schveighoffer wrote:
>> On 8/1/17 5:54 PM, Moritz Maxeiner wrote:
>>> On Tuesday, 1 August 2017 at 20:39:35 UTC, Marco Leise wrote:
>>>> Am Tue, 1 Aug 2017 10:50:59 -0700
>>>> schrieb "H. S. Teoh via Digitalmars-d"
>>>> <digitalmars-d at puremagic.com>:
>>>>
>>>>> On Tue, Aug 01, 2017 at 05:12:38PM +0000, w0rp via Digitalmars-d 
>>>>> wrote:
>>>>> > Direct OS function calls should probably all be treated as
>>>>> > >
>>>>> unsafe, except for rare cases where the behaviour is very > well 
>>>>> defined in standards and in actual implementations to > be safe. 
>>>>> The way to get safe functions for OS functionality
>>>>> > is to write wrapper functions in D which prohibit unsafe >
>>>>> calls.
>>>>>
>>>>> +1.
>>>>
>>>> I think I got it now!
>>>>
>>>>     size_t strlen_safe(in char[] str) @trusted
>>>>     {
>>>>         foreach (c; str)
>>>>             if (!c)
>>>>                 return strlen(str.ptr);
>>>>         return str.length;
>>>>     }
>>>>
>>>>   :o)
>>>
>>> I know this is in jest, but since `strlen`'s interface is inherently 
>>> unsafe, yes, the only way to make calling it @safe happens to also 
>>> solve what `strlen` is supposed to solve.
>>> To me the consequence of this would be to not use `strlen` (or any 
>>> other C function where checking the arguments for @safety solves a 
>>> superset of what the C function solves) from D.
>>> I don't think this applies to most OS functions, though, just to (OS 
>>> independent) libc functions.
>>
>> I think it goes without saying that some functions just shouldn't be 
>> marked @safe or @trusted. strlen is one of those.
>>
> 
> Of course, though I think this (sub) context was more about writing 
> @safe D wrappers for @system C functions than about which C functions to 
> mark as @trusted/@safe. `strnlen` shouldn't be marked @safe/@trusted, 
> either, but writing a @safe D wrapper for it doesn't involve doing in D 
> what `strnlen` is supposed to do:
> 
> ---
> size_t strnlen_safe(in char[] str)
> {
>      return strnlen(&str[0], str.length);
> }
> ---

Most definitely. It would be nice to have a fully @safe interface that 
is as low-level as you can possibly get. Then any library implemented on 
top of it could be marked @safe as well.

> Not that there's much of a reason to do so, anyway, when the D idiomatic 
> way is just a Phobos away:
> 
> ---
> import std.algorithm;
> // I probably wouldn't even define this but use the body as is
> auto strnlen_safe(in char[] str)
> {
>      return countUntil(cast(ubyte[]) str, '\0');
> }

Oh that cast.... it irks me so.

-Steve