Pure, Nothrow in Generic Programming

dsimcha dsimcha at yahoo.com
Fri Nov 27 13:55:51 PST 2009


== Quote from Denis Koroskin (2korden at gmail.com)'s article
> 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.

What about int.max + 1?  I specifically mentioned **signed** integers because,
IIRC overflowing these is undefined in C, but overflowing unsigned is defined.



More information about the Digitalmars-d mailing list