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