Pure, Nothrow in Generic Programming

Denis Koroskin 2korden at gmail.com
Fri Nov 27 13:29:38 PST 2009


On Sat, 28 Nov 2009 00:20:47 +0300, dsimcha <dsimcha at yahoo.com> wrote:

> == Quote from Don (nospam at nospam.com)'s article
>> Andrei Alexandrescu 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
>> Although Walter had previously talked about making @safe a little
>> stronger than just memory safety -- with the goal of eliminating
>> undefined behaviour. So (b) would be a problem. After all, you could you
>> use the same argument to say that array bounds checking isn't required
>> for reads, only for writes.
>
> Quick question about the eliminating undefined behavior thing:  Isn't  
> overflowing
> a signed int undefined behavior?  If so, how would we eliminate  
> undefined behavior
> without very expensive runtime checks?

I don't think integer overflow could be considered an undefined behavior.  
It's pretty much expected that uint.max + 1 == 0.



More information about the Digitalmars-d mailing list