== Quote from Denis Koroskin (2kor...@gmail.com)'s article > On Sat, 28 Nov 2009 00:20:47 +0300, dsimcha <dsim...@yahoo.com> wrote: > > == Quote from Don (nos...@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.