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
