Bug 8650 – SLice opOpAssign SLice with overlap does not throw

-------- void main() { int[] b = new int[](10); b[] = 5; b[0..6] += b[4..10]; } -------- Behavior: Runs until end of program. Expected: A error to be thrown: Overlapping operations are illegal.

Also, doesn't check length: -------- void main() { int[ 5] a; int[10] b; a[] += b[]; b[] += a[]; } -------- Behavior: Runs until end of program. Expected: A error to be thrown: arrays have different length. -------- The problem would seem to come from "arrayint.d" from druntime. Apparently, the "in" tests are not executed, because the tests are in there.

(In reply to comment #1) > The problem would seem to come from "arrayint.d" from druntime. > Apparently, the "in" tests are not executed, because the tests are in there. And replacing those asserts with "enforces" inside the function body is not a solution (it's just a way to try to kill D Contract Programming).

(In reply to comment #2) > (In reply to comment #1) > > > The problem would seem to come from "arrayint.d" from druntime. > > Apparently, the "in" tests are not executed, because the tests are in there. > > And replacing those asserts with "enforces" inside the function body is not a > solution (it's just a way to try to kill D Contract Programming). I don't seem to remember suggesting that... I was just stating where I think the problem comes from. I'm compiling in debug, so I expected the assert to be evaluated. As a matter of fact, if anything, given related issue 8651, I'd have placed asserts in the function body. NOT enforces.

(In reply to comment #1) > The problem would seem to come from "arrayint.d" from druntime. > Apparently, the "in" tests are not executed, because the tests are in there. Turns out the problem is that the in/assert cases are removed from the druntime libs, since it is compiled in release when distributed. It would be *nice* for these tests to be run depending on the current program's compilation flags, and no druntimes. Changing to ER.

This is a druntime wrong-code bug as it should throw errors in such cases.

This fix is in pull which adds more utils to druntime: https://github.com/D-Programming-Language/druntime/pull/661

(In reply to comment #4) > (In reply to comment #1) > > The problem would seem to come from "arrayint.d" from druntime. > > Apparently, the "in" tests are not executed, because the tests are in there. > > Turns out the problem is that the in/assert cases are removed from the druntime > libs, since it is compiled in release when distributed. > Right, I think in the long-term we should fix this by providing debug phobos/druntime libraries with additional checks.

IMHO, debug/release builds of druntime (or any library) are the wrong direction for contract enforcement. They pre/post conditions should be visible to call sites and executed based on the call site's compilation settings. For _all_ code, not just druntime or phobos.

*** This issue has been marked as a duplicate of issue 2547 ***

(In reply to comment #8) > IMHO, debug/release builds of druntime (or any library) are the wrong direction > for contract enforcement. They pre/post conditions should be visible to call > sites and executed based on the call site's compilation settings. For _all_ > code, not just druntime or phobos. You're right, any contract that is part of the API needs to be visible (or at least callable) for the caller.

Commit pushed to master at https://github.com/D-Programming-Language/druntime https://github.com/D-Programming-Language/druntime/commit/a6aa6ee66dcbe3f77b4e0c816e02d8f32040dede Fix Issue 8650 - SLice opOpAssign SLice with overlap does not throw Issue URL: http://d.puremagic.com/issues/show_bug.cgi?id=8650

(In reply to comment #8) > IMHO, debug/release builds By "debug" do you mean "debug" or "non-release"? > of druntime (or any library) are the wrong direction for contract > enforcement. Then release a build that has the in contracts but is otherwise a release build. > They pre/post conditions should be visible to call sites and > executed based on the call site's compilation settings. For _all_ > code, not just druntime or phobos. This has been asked for on many occasions. But Walter doesn't seem to like this idea, so I filed issue 9482 and issue 9483 as an alternative way of dealing with the same problem.