https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113159
--- Comment #22 from Jonathan Wakely ---
(In reply to Yury Gribov from comment #19)
> (In reply to Jonathan Wakely from comment #17)
> > That's what _GLIBCXX_DEBUG and/or _GLIBCXX_ASSERTIONS are for.
>
> I'm not sure they solve the issue
I'm n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113159
--- Comment #21 from Yury Gribov ---
(In reply to Gabriel Ravier from comment #20)
> I hope you would agree memory corruption is bad - and that's what will
> happen a lot of the time instead of a simple crash.
Ok, got it. So basically memory co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113159
--- Comment #20 from Gabriel Ravier ---
> In general, why avoiding std::sort crashes is considered a good thing?
> Wouldn't we just hide the error and produce invalid results causing harder to
> debug errors later in user's program?
The issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113159
--- Comment #19 from Yury Gribov ---
(In reply to Jonathan Wakely from comment #17)
> (In reply to Yury Gribov from comment #10)
> > As a compiler user I would actually love my STL to crash fast on invalid
> > comparators rather than produce unp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113159
--- Comment #18 from Jan Engelhardt ---
_GLIBCXX_DEBUG sounds good. Though, it can only be switched per TU so one would
have to get even more creative to do something like
void f(std::vector &a, std::vector &b)
{
// "I know I got this"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113159
--- Comment #17 from Jonathan Wakely ---
(In reply to Yury Gribov from comment #10)
> As a compiler user I would actually love my STL to crash fast on invalid
> comparators rather than produce unpredictable and meaningless results which
> will c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113159
--- Comment #16 from Yury Gribov ---
(In reply to Xi Ruoyao from comment #15)
> (In reply to Yury Gribov from comment #14)
> > (In reply to Xi Ruoyao from comment #12)
> > > Also note even
> > >
> > > bool cmp(Element a, Element b) { return fal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113159
--- Comment #15 from Xi Ruoyao ---
(In reply to Yury Gribov from comment #14)
> (In reply to Xi Ruoyao from comment #12)
> > Also note even
> >
> > bool cmp(Element a, Element b) { return false; }
> >
> > is a *valid* comparator, per the stand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113159
--- Comment #14 from Yury Gribov ---
(In reply to Xi Ruoyao from comment #12)
> Also note even
>
> bool cmp(Element a, Element b) { return false; }
>
> is a *valid* comparator, per the standard.
Hm, doesn't it violate the asymmetry axiom (cmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113159
--- Comment #13 from Yury Gribov ---
(In reply to Xi Ruoyao from comment #11)
> (In reply to Yury Gribov from comment #10)
> > As a compiler user I would actually love my STL to crash fast on invalid
> > comparators rather than produce unpredict
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113159
--- Comment #12 from Xi Ruoyao ---
Also note even
bool cmp(Element a, Element b) { return false; }
is a *valid* comparator, per the standard. Though it'll likely produce
completely meaningless result, it's just your own logical error as it vi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113159
--- Comment #11 from Xi Ruoyao ---
(In reply to Yury Gribov from comment #10)
> As a compiler user I would actually love my STL to crash fast on invalid
> comparators rather than produce unpredictable and meaningless results which
> will cause m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113159
Yury Gribov changed:
What|Removed |Added
CC||ygribov at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113159
Xi Ruoyao changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113159
--- Comment #8 from Jonathan Wakely ---
I haven't seen a proof that libstdc++'s std::sort can't be made more robust
without losing performance. Maybe cheap range checks can be done conditionally
when _GLIBCXX_ASSERTIONS is defined, or maybe they
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113159
--- Comment #7 from Xi Ruoyao ---
Generally I hate the idea to punish innocent programs (making them slower) just
to satisfy buggy programs. If it's due to Hyrum's rule then fine, but here
Hyrum rule does not apply.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113159
Florian Weimer changed:
What|Removed |Added
CC||fw at gcc dot gnu.org
--- Comment #6 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113159
--- Comment #5 from Andrew Pinski ---
(In reply to Jan Engelhardt from comment #4)
> >And in upcoming Glibc-2.39 there will be a major reimplementation of qsort
>
> Even so, a recent commit strongly suggests that sticking to array bounds
> rema
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113159
Jan Engelhardt changed:
What|Removed |Added
CC||fweimer at redhat dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113159
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113159
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2023-12-28
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113159
Xi Ruoyao changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113159
Jonathan Wakely changed:
What|Removed |Added
Severity|normal |enhancement
23 matches
Mail list logo
