On Sun, 4 Aug 2019 at 16:21, Sam Varshavchik <mrsam(a)courier-mta.com> wrote:
I'm well aware of the alternatives. That's not the point.
The point is that there's nothing wrong with this specific form of existing
code that now throws exceptions when the hardened build gets turned on.
There is no buffer overruns, and nothing to exploit.
IIRC, the hardened build did find one real bug in the upstream package that
was the original subject matter here, but all of the rest were these kinds
of false positives. Now you have a situation when the existing code is known
to be working, but needs changing in order to use a hardened build. There's
some level of risk of regression in any change, and that gets weighed
against the benefits of having a hardened build.
The above was just a basic example of this. It is not true that exceptions
from hardened code are always evidence of potentially exploitable problem.
Sometimes/most of the time, but sometimes they are false positives.
Georg's point (please, correct me if I'm wrong) is: how many false
positives are there (I'd say, very few) and how many of them leave us
with no reasonable (and even more idiomatic, as in your basic example)
options (I'd say, very very few to none) compared to the protection
these assertions provide with a very small performance cost?
I do think that there's something wrong with unnecessarily complex and
non-idiomatic constructs when there are reasonable, fast, idiomatic
alternatives, even if the code throws no exceptions and is technically
correct. I do think there's something wrong if you need to navigate
various C++ standards to understand the container implementation at a
low level to be sure that memory is contiguous and the code is doing
the correct thing.
But anyway, this turned into an off-topic. This flag is not an issue
for KiCad, and it wasn't a false positive. The issue was a critical
bug uncovered thanks to this flag.
Iñaki