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.


T

-- 
People say I'm indecisive, but I'm not sure about that. -- YHL, CONLANG

Am Tue, 1 Aug 2017 10:50:59 -0700
schrieb "H. S. Teoh via Digitalmars-d"
<digitalmars-d@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)

-- 
Marco

On Tue, Aug 01, 2017 at 10:39:35PM +0200, Marco Leise via Digitalmars-d wrote:
> Am Tue, 1 Aug 2017 10:50:59 -0700
> schrieb "H. S. Teoh via Digitalmars-d"
> <digitalmars-d@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)
[...]

LOL, that's laughably inefficient.  Instead of calling strlen, you might as well have just looped with an index and returned the index. :-P

	foreach (i, c; str)
		if (!c) return i;

Oh wait, so we didn't need the wrapper after all. :-P


T

-- 
It's amazing how careful choice of punctuation can leave you hanging:

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@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.

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@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.

-Steve

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@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);
}
---

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');
}
---

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@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

On Tue, Aug 01, 2017 at 06:46:17PM -0400, Steven Schveighoffer via Digitalmars-d wrote:
> On 8/1/17 6:17 PM, Moritz Maxeiner wrote:
[...]
> > 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.
[...]

Welcome to the wonderful world of autodecoding. :-D

OTOH, we could just use byCodeUnit and we wouldn't need the cast, I think.


T

-- 
Don't get stuck in a closet---wear yourself out.

On Tuesday, 1 August 2017 at 22:52:26 UTC, H. S. Teoh wrote:
> On Tue, Aug 01, 2017 at 06:46:17PM -0400, Steven Schveighoffer via Digitalmars-d wrote:
>> On 8/1/17 6:17 PM, Moritz Maxeiner wrote:
> [...]
>> > 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.
> [...]
>
> Welcome to the wonderful world of autodecoding. :-D
>
> OTOH, we could just use byCodeUnit and we wouldn't need the cast, I think.

I was lazy, okay (I nearly forgot putting the auto decoding prevention in there, because I always forget that D has auto decoding; it irks me as well) :p

>> 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

return str.representation.countUntil('\0');

Andrei