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

[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 multibyte decoding failure.  Basically it's a quick hack to fix
> this bug:
> 
>   <https://sourceware.org/bugzilla/show_bug.cgi?id=14185>
> 
> Is this something we should upstream?  Or rework fnmatch so that * is
> matched properly against arbitrary bytes?

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. But I am slight
worried about the issues raised by Rich in comment #4, where fnmatch would
match wrong patterns that happen to have invalid multibyte sequence.  Maybe
gnulib guys can gives us some insight here about the realword and if the
67306f600fe6a3 was intentional or not.

I have started to check the feasibility or making the Rich suggestions at
comment #7, to make fnmatch not go in the temporary buffer and call
mbrtowc.  It should be feasible, however it would require more extensive
change in the algorithm and some work to optimize for MB_CUR_MAX == 1
(where mbrtowc should not be necessary).