Pure, Nothrow in Generic Programming

Denis Koroskin 2korden at gmail.com
Fri Nov 27 13:25:42 PST 2009


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



More information about the Digitalmars-d mailing list