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: Paul Eggert
Subject: Re: [PATCH 1/2] posix: User scratch_buffer on fnmatch
Date: Wed, 13 Jan 2021 11:25:19 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0

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



reply via email to

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