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
