Contracts, Undefined Behavior, and Defensive,Programming

Jesse Phillips Jesse.K.Phillips+D at gmail.com
Sun Jun 14 17:38:34 UTC 2020


On Saturday, 13 June 2020 at 15:38:03 UTC, Johannes Pfau wrote:
> 
> To summarize and rephrase this: the encapsulation unit of @safe 
> is the function boundary. The parameter definitions (including 
> this pointer) and return type and their modifiers are the 
> information the compiler uses to implement it's safety checks. 
> For all possible combinations of these input values, the @safe 
> function may not cause memory corruption.
>
> asserts then narrow the function contract by describing 
> semantic limitations and @safe is not able to enforce this, as 
> this information is not part of the function signature. This is 
> fine, as @safe will still prevent soft UB from escalating to 
> hard UB. But if you now use assert() as assume(), you introduce 
> hard UB for some possible input combinations, subverting @safe 
> guarantees.

Let me try and state the position I think you are taking.

Soft undefined behavior is unacceptable for @safe code because it 
can lead to memory corruption due to the hard undefined behavior 
which may result from the soft undefined behavior.


More information about the Digitalmars-d mailing list