checkedint call removal

[Paolo Invernizzi via Digitalmars-d]

On Sunday, 3 August 2014 at 16:29:18 UTC, Timon Gehr wrote:
> 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:
>>>
>>>> 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.

If an assert triggers, and you want go anyway with '-release', 
you should remove it from the code, that's my point. No problem 
at all with inferring optimisations from it.

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

But most yes: to me, an undefined behaviour is the situation 
where I've developed the code for having 'a' in one place, and I 
have 'b'. If this is not, literally undefined behaviour, I donno 
how I should name it.

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

Again, the assertion will trigger on that, so I'm not entering 
the 'donno what happened here' state: the program will halt. No 
security risk at all, also if the assert expression is crappy 
code.

If you want to keep the safety net also in '-release' just stop 
using asserts and use enforce, at least you are clearly 
signalling the developer intention. Or, simply, don't use 
'-release', but that to me it's a little abuse of the use of 
assert...

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

I don't understand now: I notice it because the program terminate 
with a stack trace telling me an assertion was triggered. What 
are you meaning? I guess it's a pretty common practise to have 
testers stress the application with asserts on, prior to put it 
in production with assertion disabled once you are confident that 
the program is not buggy.

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

I don't think it's a straw man, because I've not changed anything 
that Johannes has said.

> You need to argue against the existence of the broken code. 
> I.e. you need to argue for an (approximate) universal.

I'm arguing, like others, that to me the code was already broken, 
but it seems that we can't agree on what broken means.

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

That's what usually happens, if you have a good test coverage, 
and a good testing period.

> (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..."))

The point was simply that I don't think that such a change will 
summon voices claiming that the language has broken again some 
codebase.

That is an easy rebuttal, because it's caused by a, IMHO, bad 
practical usage of the assert statement.

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

Ok, now I've understood: are you arguing, (correct me if I'm 
wrong, I'm not searching a strawman, really!) that probably there 
are bugs, and that bugs are wrong assert expressions, that are 
wrongly modelling the intended state of the program in an assert 
expression?

And in that case, are you arguing that the utility of the 
'-release' flags is that, obliterating the assert code, it raises 
the quality of the code because it's some sort of "dead code 
elimination?".

It's that?

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

If I've grasped your point in the previous reply, yes, maybe.

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

I think that something similar is happening: the avionic system 
is disabled if the results coming out from two different 
implementation of "how the plane should fly" diverge. It's the 
same as they are running without '-release', and checking 
mutually the state of the flight devices and parameters.

The are 'aborting', and leaving all the control to man instead of 
going on: it's like they are not using '-release' at all, and 
it's like they are using 'enforce' all over the place, no assume 
or assert at all.

---
Paolo