checkedint call removal

[Timon Gehr via Digitalmars-d]

On 08/03/2014 05:00 PM, Paolo Invernizzi wrote:
> 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 will from now on be in -release, this is what this is all about.

> 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.
> ...

Most bugs do not lead to undefined behaviour. E.g. you can write buggy 
code in a language that does not have the concept.


> 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.
> ...

And what do you think a wrong assertion is the manifestation of? (Hint: 
The assertion talks about the program state.)

> 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,

But that is not the scenario. You don't turn on -release in order to 
disable assertions that you _know_ are failing.

> 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,

Why do you assume they had noticed that the assertion was wrong?

> That was a stereotypical example;

You were not in the position to introduce a stereotypical example. If 
Johannes says that some code will break, and you say "I don't buy this", 
then you cannot introduce an example to argue against, where the 
additional circumstances are such that you have an easy point. This is a 
straw man. You need to argue against the existence of the broken code. 
I.e. you need to argue for an (approximate) universal. If you introduce 
an example, you need to argue that the 'example' is actually the only 
(likely) way that code could be broken by this change. I.e. you'd need 
to argue that wrong assertions are always caught before they are part of 
a build where they are disabled. (You might also pursue the alternative 
direction of admitting that this is a possibility, but saying that it is 
very unlikely to happen, and then justify that opinion. ("That's true, 
this might happen, but I don't think this change will lead to many 
catastrophes, because..."))

> what I was trying to argue it's that also if we do some dirty tricks to keep the train on the rails,

(That's still part of the made up scenario.)

> if the program logic is flowed  [sic]

Maybe it hasn't been flawed in the -release build before because the 
faulty assertion was the only thing that was faulty, but nobody knew 
that it was faulty before the released system went down.

> you can have an avalanche effect in some cases:

Note again, 'some cases'. Those are again different cases than Johannes 
had in mind.

> everything seems to work fine for a good amount of time until the snowball comes down,
> violates catastrophically the program logic and boom.

Again, in other cases, the -release program will operate as expected.

An analogy, to be taken with a grain of salt: Planes crash sometimes, 
even though this is not part of their intended design. It would still be 
a bad idea to install bombs in some planes that explode when they seem 
about to crash according to _some_ of many simple tests of measured 
parameters proposed by one of (possibly) _many_ designers of the plane, 
especially if those tests were proposed without knowledge that this was 
going to be their purpose.