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.
