bug#23234: unexpected results with charset handling in GNU grep 2.23

[Zev Weiss]

On Sun, Apr 10, 2016 at 02:10:08PM -0700, Jim Meyering wrote:
> On Sun, Apr 10, 2016 at 1:43 AM, Paul Eggert <address@hidden> wrote:
> > Paul Eggert wrote:
> > > I plan to change GNU grep to use this new facility, and to add some grep
> > > test
> > > cases for this issue.
> >
> >
> > I did that by installing the attached patches into the grep master. This
> > fixes the bug for me, so I'm closing the bug report.
> >
> > These patches mostly just report the fix and add test cases. The actual fix
> > was in gnulib, here:
> >
> > http://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=b7bc3c1a4e78add4cbad39ae1a0c4fb0747b483f
> >
> > This gnulib fix works around the underyling glibc facility which caused the
> > problem, for which I've filed a bug report here:
> >
> > https://sourceware.org/bugzilla/show_bug.cgi?id=19932
> >
> > It's not clear when the glibc bug will be fixed. Until it is, one should
> > expect similar problems to crop up in applications other than 'grep'.
>
> Thanks for the fine work, Paul.
> With this fix, I would like to make yet another grep release.
> Does anyone have any pending changes we should consider?
>
> Incidentally, looking at mbrtowc uses, I found an unused
> function and removed it with this patch:

Well, I still have my multithreading patch series 
(https://github.com/zevweiss/grep/) awaiting review, which I'd hope to 
get applied at some point, though I'd guess it's enough of a review task 
that delaying an impending release for it isn't likely (the 
mbtoupper()-removal patch made that series one patch shorter though, 
since one was to deal with that function's thread-unsafety).  I've been 
rebasing it periodically and running it on my own system in /usr/local 
without any problems for a while now, for what that's worth.

With current HEAD from savannah though, all check-very-expensive tests 
pass for me on Debian stretch with gcc 5.3, glibc 2.22, and Linux kernel 
4.3.


Zev Weiss