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

2021-01-04 Thread Adhemerval Zanella
It removes the alloca usage on the string convertion to wide characters before calling the internal function. Checked on x86_64-linux-gnu. --- posix/fnmatch.c | 152 +--- 1 file changed, 53 insertions(+), 99 deletions(-) diff --git a/posix/fnmatch.c b/

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

2021-01-04 Thread Florian Weimer
* Adhemerval Zanella via Libc-alpha: > It removes the alloca usage on the string convertion to wide characters > before calling the internal function. We have a downstream-only patch to fall back the single byte handling in case of multibyte decoding failure. Basically it's a quick hack to fix t

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

2021-01-05 Thread Adhemerval Zanella
On 04/01/2021 17:35, Florian Weimer wrote: > * Adhemerval Zanella via Libc-alpha: > >> It removes the alloca usage on the string convertion to wide characters >> before calling the internal function. > > We have a downstream-only patch to fall back the single byte handling in > case of multiby

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

2021-01-13 Thread Paul Eggert
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

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

2021-01-13 Thread Florian Weimer
* Paul Eggert: > 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. :-) There is a Shift-JIS variant which is ASCII-transparent

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

2021-01-13 Thread Bruno Haible
Paul Eggert asked: > > 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. Here we are talking about locale encodings, and Shift_JIS (as well as SHIF

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

2021-01-14 Thread Florian Weimer
* Bruno Haible: > Paul Eggert asked: >> > 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. > > Here we are talking about locale encodings, and S

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

2021-01-14 Thread Adhemerval Zanella
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

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

2021-01-14 Thread Paul Eggert
On 1/14/21 3:44 AM, Adhemerval Zanella wrote: 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. For glibc 2.33 that's likely the best we can do. The full fix will take some time, since it is pretty much a rewr

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

2021-03-06 Thread Paul Eggert
On 1/14/21 2:00 AM, Florian Weimer wrote: We saw commercial demand for Shift-JIS much later than that. Yes, I see Red Hat has a product enhancement for that, for coreutils, dated 2019.[1] Shift-JIS is still very much alive and kicking in Japan in its own circles. Even DBCS EBCDIC is still u