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
