On 02.09.2017 18:26, Branko Čibej wrote:
> On 02.09.2017 18:06, Stefan Fuhrmann wrote:
>>
>>
>> On 02.09.2017 17:17, Branko Čibej wrote:
>>> On 02.09.2017 17:12, stefan2_at_apache.org wrote:
>>>> +svn_boolean_t
>>>> +svn_utf__fuzzy_glob_match(const char *str,
>>>> + const apr_array_header_t *patterns,
>>>> + svn_membuf_t *buf)
>>>> +{
>>>> + const char *normalized;
>>>> + svn_error_t *err;
>>>> + int i;
>>>> +
>>>> + /* Try to normalize case and accents in STR.
>>>> + *
>>>> + * If that should fail for some reason, continue with the
>>>> original STR.
>>>> + * There is still a fair chance that it matches "*.ext" pattern
>>>> despite
>>>> + * being "broken" UTF8. */
>>>
>>>
>>> What evidence do you have for this statement? It is, quite frankly,
>>> completely bonkers.
>>>
>>> "Broken," as you put in quotes, means it's not UTF-8. What kind of UTF-8
>>> do you think there's a fair chance it'll match then?
>>
>> I've encountered old repositories where some path names
>> were apparently not converted properly into UTF8 but
>> contained whatever locale-based strings the client sent.
>
> And such repositories were used without problems with current clients? I
> can hardly believe that.
>
>> Those would still match "*.someExtension" and similar
>> patterns despite having non-UTF8. I would like to cover
>> those as well.
>
> But not *.ك
>
> I think you're trying to solve an edge case in an API function by means
> of an undocumented implementation detail. My advice is to throw it out.
On second thought, I agree. Removed in r1807155.
-- Stefan^2.
Received on 2017-09-03 17:16:28 CEST