[PATCH 1/2] posix: User scratch_buffer on fnmatch

Paul Eggert eggert@cs.ucla.edu
Wed Jan 13 19:25:19 GMT 2021


On 1/5/21 5:07 AM, Adhemerval Zanella wrote:
> It seems that gnulib has added the proposed fix with
> aed23714d60d91b2abc74be33635c32ddc5132b5 (done in 2005) and just recently
> with a glibc merge with 67306f600fe6a3bcf3fbb6d8bf4b8953b74a8fb7 (done in
> 2020 to sync back glibc changes) it has fallback to old semantic to return
> -1 on in case of failure.
> 
> I am not sure if gnulib was intentional or an overlook.

It was an oversight. I simply missed the issue when I did the merge.

> I have started to check the feasibility or making the Rich suggestions at
> comment #7,

That's the right way to go. I would not spend much time trying to fix 
the bugs in the existing code. We should rip out all the wide-char 
stuff, treat encoding errors as if they were just another "character" 
(that's what Emacs does), and stay in the multibyte world. We could 
steal some ideas from Emacs here.

By the way, how important is it to support awful encodings like 
shift-JIS that contain bytes that look like '\'? If we don't have to 
support these encodings any more, things get a bit easier. (Asking for a 
friend. :-)


More information about the Libc-alpha mailing list