Re: How do I remove GLIBCXX_ASSERTIONS?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sun, 4 Aug 2019 at 16:21, Sam Varshavchik <mrsam@xxxxxxxxxxxxxxx> 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
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux