checkedint call removal

[Paolo Invernizzi via Digitalmars-d]

On Sunday, 3 August 2014 at 14:10:29 UTC, Timon Gehr wrote:
> On 08/03/2014 03:01 PM, Paolo Invernizzi wrote:
>> On Sunday, 3 August 2014 at 10:49:39 UTC, Timon Gehr wrote:
>>> On 08/03/2014 11:15 AM, Paolo Invernizzi wrote:
>>>> because every few milliseconds an assert is triggered
>>>
>>> Right, and software does not have security holes because 
>>> otherwise
>>> they would obviously be exploited every few milliseconds 
>>> during
>>> in-house testing.
>>
>> That is a totally different matter:
>
> Well, no.
>
>> security holes are about things that
>> the programmer is _totally missing_,
>
> The programmer(s!) may be _totally missing_ the conditions that 
> lead to an assertion failure. In fact, unless assertions are 
> intentionally misused, this is always the case.
>
>> and someone is seeing and exploiting that.
>
> (Undefined behaviour introduced in this way may be exploitable.)

If the assertion triggers, that's not undefined behaviour: it's a 
bug, already implanted in the code, that the assertion is 
surfacing _avoiding_ undefined behaviour occurring from the 
really next line of code.

Security holes are not related to assertions at all, they are 
related in unpredictable state that the program has reached, 
outside of the view of the programmers.

Assertions are only checks that the reasoning about the flow and 
the conditions is going in the way that was originally intended. 
If you have failures, and you want to cope with them, you MUST 
remove the failing assertions from the code, and turn them in 
specific code to cope with the faulty condition.

Something like 'warning mate! the commented assertion is 
triggered from time to time, so there's definitely something 
somewhere in the code that we not fully understand, so here below 
is a dirty trick to turn the program logic back on the rails 
because we are in a hurry'.

I've never seen a live assertion in the code without the intended 
behaviour of the expression being true: what would be a mess 
otherwise!

>> ...  can you rephrase please?
>
> If wrong assertions would indeed fail every few milliseconds, 
> then a way to show an assertion to be correct beyond reasonable 
> doubt is to add the test of the condition to the program and 
> then run it for a few milliseconds.

That was a stereotypical example; what I was trying to argue it's 
that also if we do some dirty tricks to keep the train on the 
rails, if the program logic is flowed you can have an avalanche 
effect in some cases: everything seems to work fine for a good 
amount of time until the snowball comes down,  violates 
catastrophically the program logic and boom.

In that cases, also going with '-release' keeping the fingers 
crossed it's not a good solutions at all.

---
Paolo