Pure, Nothrow in Generic Programming
Andrei Alexandrescu
SeeWebsiteForEmail at erdani.org
Fri Nov 27 14:55:59 PST 2009
Denis Koroskin wrote:
> On Fri, 27 Nov 2009 23:51:44 +0300, Andrei Alexandrescu
> <SeeWebsiteForEmail at 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
s/undefined/implementation-defined/
Andrei
More information about the Digitalmars-d
mailing list