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