On Wednesday, 7 March 2018 at 11:52:05 UTC, Jonathan M Davis wrote:
On Wednesday, March 07, 2018 09:22:40 Paolo Invernizzi via Digitalmars-d wrote:
On Wednesday, 7 March 2018 at 09:11:10 UTC, Jonathan M Davis

>> So, the request is to just leave assert active as a default >> in @safe code, like the bounds checks?
> No. I'm saying that no optimizations should be enabled which > introduce potential memory corruption. Assertions should > have zero impact on whether code is @safe or not unless the > code in the condition or which is generating the message for > the assertion is @system, and it's no more reasonable to > assume that an assertion is going to pass than it is to > assume that bounds checking won't fail. Regardless, the key > thing here is that @safe code should be guaranteed to be > @safe so long as @trusted code is vetted properly. It should > _never_ be possible for the compiler to introduce memory > safety issues into @safe code.
>> So, the reasoning is that UB should not lead to memory >> corruption, right?
> The reasoning is that no @safe code should ever have memory > corruptions in it unless it calls @trusted code that was > incorrectly vetted by the programmer. The compiler is > supposed to guarantee that @safe code is @safe just like > it's supposed to guarantee that a const variable isn't > mutated or that a pure function doesn't access mutable, > global variables. And as such, introducing anything into > @safe code which could be memory unsafe is a violation of > the compiler's responsibility.

Jonathan, I understand your reasoning, but it's not what I'm asking: are we asking for UB that do not lead to memory corruption?

I'm saying that @safe code must not be violated by the compiler. Beyond that I'm not arguing about UB one way or the other.

And that's clear.

If UB must be disallowed to avoid violating @safe, then it must be disallowed.

And how to do this, in practise I mean?

If some form of UB can be allowed, because it's restricted in a manner that it can't violate @safe but may do something else stupid because the assertion would have failed if it weren't compiled out, I don't care.

And that's the original question: are we asking for UB that do not lead to memory corruption?

If an assertion would have failed if it weren't compiled out, then you have a bug regardless, and if the code is buggier because of an optimization, then that's fine with me. You have a bug either way.


What isn't fine is that that result violate @safe, because that would defeat the entire purpose of @safe and make it far, far more difficult to track down @safety problems.

So, see above, the original question, agreed.

Right now, since no optimizations like Walter has been talking about are done by the compiler, if you have memory corruption, you know that you only have to look at @system and @trusted code to find it, whereas with the unsafe optimizations that Walter is talking about, it then becomes possible that you're going to have to look through the entire program to find the problem.

Or you can just turn on assertion, right?

If we have corrupted memory in release, there's a bug, somewhere, in the logic or in the implementation of the logic. As you have told, we must audit @system and @trusted, we can imagine to use static checkers or some strange beast like that. But, while doing that, I think that the most common practise is keep running the code with assertion on, do you agree?

And right now, you can be sure that you don't have @safety problems in @safe code if you use @trusted correctly, whereas with what Walter is talking about, simply adding an assertion could add @safety problems to your code.

Nope, not adding an assertion, but having the process in UB state.
And we are back again to the original question.


Reply via email to