bug-gnulib
[Top][All Lists]
Advanced

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

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


From: Adhemerval Zanella
Subject: Re: [PATCH 1/2] posix: User scratch_buffer on fnmatch
Date: Thu, 14 Jan 2021 08:44:30 -0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0


On 13/01/2021 16:25, Paul Eggert wrote:
> 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.

I think we still should fix BZ#14185 with the suggested with the strategy of
falling back to non wide mode in case of encoding error.  

The full fix will take some time, since it is pretty much a rewrite of the
fnmatch_loop.c.

> 
> 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. :-)



reply via email to

[Prev in Thread] Current Thread [Next in Thread]