On Fri, 27 Nov 2009 23:51:44 +0300, Andrei Alexandrescu
<seewebsiteforem...@erdani.org> wrote:
Walter Bright wrote:
dsimcha wrote:
I think you misunderstood the argument. memcmp() could be @trusted if
functions
only need to be safe when passed valid parameters, though I don't
necessarily
agree that this makes sense. I was thinking memcmp() shouldn't even
be marked
@trusted because it's so easy to invoke undefined behavior by passing
incorrect
parameters. This would mean that, if opCmp() uses it, opCmp()
couldn't be marked
as @safe.
memcmp() could be marked @trusted, but it should not be. This is
because @trusted functions can be called by @safe ones, but there's no
way that an @safe function can guarantee it sends memcmp() arguments
that will work safely with memcmp().
Whoever calls memcmp() can be marked @trusted.
Hm, if we think of it, memcmp can be @safe no problem. This is beacuse
it oly reads stuff. There are three possible outcomes:
a) valid addresses, all's fine
b) incorrect addresses within the application, erroneous result returned
c) incorrect addresses outside the application, segfault
None of the above is unsafe. So memcmp is safe. (In contrast, memcpy is
not). Color me surprised but convinced.
Andrei
Points 2 and 3 introduce undefined behavior, which is not allowed in SafeD
:p
