Re: How do I remove GLIBCXX_ASSERTIONS?

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

 



On Mon, 5 Aug 2019 at 18:23, Andrew Lutomirski <luto@xxxxxxx> wrote:
>
> On Sun, Aug 4, 2019 at 6:16 AM Sam Varshavchik <mrsam@xxxxxxxxxxxxxxx> wrote:
> >
> > 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.
> >
> >
>
> I filed an upstream bug:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91357
>
> Depending on the resolution of that bug, I suggest that Fedora
> consider dropping _GLIBCXX_ASSERTIONS from the default hardened build
> options.  IMO Fedora's default RPM build options should not cause
> crashes on valid, if less-than-stylistically-great, code.  I don't
> think that package maintainers should need to update package source to
> use C++ in a more polite way.

Upstream response has been quick:

"It's UB, no question. The table of "Optional sequence container
operations" says a[n] is equivalent to *(a.begin() + n) so when
n==a.size() you dereference the past-the-end iterator, which is UB."

"The assertion is entirely correct. Calling operator[] with an invalid
value is UB, it doesn't matter what you do (or don't do) with the
result."

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