Georg Sauthoff writes:
> I ended up tweaking my code to avoid the assertions, rather than
disabling
> them. For this particular situation, my original change was to try
>
> std::copy(&foo[0], &foo[0]+foo.size(), std::back_insert_iterator{bar});
>
> But that still tripped the assertion when the foo vector was empty, so I
had
> wrap this inside an if().
But why don't you use the idiomatic
copy(foo.begin(), foo.end(), back_inserter(bar));
?
No need to wrap it into an extra if statement.
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.