Program logic bugs vs input/environmental errors

[Timon Gehr via Digitalmars-d]

On 10/08/2014 05:19 AM, Walter Bright wrote:
> On 10/7/2014 6:18 PM, Timon Gehr wrote:
>  > I can report these if present.
>
> Writing a strongly worded letter to the White Star Line isn't going to
> help you when the ship is sinking in the middle of the North Atlantic.
> ...

Maybe it is going to help the next guy whose ship will not be sinking 
due to that report.

> What will help is minimizing the damage that a detected fault may cause.
> You cannot rely on the specification when a fault has been detected.
> "This can't be happening!" are likely the last words of more than a few
> people.
>

Sure, I agree.

Just note that if some programmer is checking for overflow after the 
fact using the following idiom:

int x=y*z;
if(x/y!=z) assert(0);

Then the language can be defined such that e.g.:

0. The overflow will throw on its own.

1. Overflow is undefined, i.e. the optimizer is allowed to remove the 
check and avoid the detection of the bug.

2. Guaranteed wrap-around behaviour makes the code valid and the bug is 
detected by the assert.

3. Arbitrary-precision integers.

4. ...

Code is simply less likely to run as intended or else abort if 
possibility 1 is consciously taken. The language implementation may 
still be buggy, but if it may even sink your ship when it generated code 
according to the specification, it likely sinks in more cases. Of course 
you can say that the programmer is at fault for checking for overflow in 
the wrong fashion, but this does not matter at the point where your ship 
is sinking. One may still see this choice as the right trade-off, but it 
is not the only possibility 'by definition'.