On Thursday, 1 March 2018 at 21:01:08 UTC, Steven Schveighoffer
wrote:
Yeah, it seems like -noboundscheck should never be used.
Agreed.
It's undefined behavior if the check is disabled. How you get
the check disabled may be affected by @safe, but whether it's
UB or not has nothing to do with @safe. It has to do with "I
turned off the checks". Basically, in D, if your program *would
have* thrown an Error, but didn't because you turned it off,
the compiler is free to assume UB.
You're looking at the behavior of the compiled executable. Then
it makes sense to say that a program compiled with the checks has
defined behavior (throwing Errors) and a program without the
checks does something undefined (because the compiler manual
doesn't say that anything in particular is supposed to happen).
That's not how I understand/use "undefined behavior". To me, it's
the D source code that can have "undefined behavior". When it
does, the program (as given in source code) is invalid and the
compiler can do whatever it wants with it. It may:
1) reject the program statically, or it may
2) generate code that throws an Error at run time, or it may
3) generate code that does something arbitrary.
With that meaning of UB, out-of-bounds accesses and overlapping
copies have undefined behavior in @system code, but they have
defined behavior in @safe code.
For @system code, DMD chooses option #2 or option #3 depending on
whether you give -release or not. DMD is free to do this, because
the source code has UB.
For @safe code, DMD goes with option #2 either way, because the
spec demands it.
If it were capable, DMD could also go with option #1 for both
@system and @safe code. The spec allows/encourages that.
In this interpetation, -noboundscheck switches DMD to a different
dialect of D. In that dialect, out-of-bounds accesses (and
overlapping copies, apparently) always have UB, in both @system
and @safe code. That defeats the purpose of @safe. Which is why I
don't really care for that dialect.
