curl / Mailing Lists / curl-library / Single Mail


Re: wildcard matching

From: Patrick Monnerat via curl-library <>
Date: Mon, 29 Jan 2018 01:38:20 +0100

On 01/28/2018 11:58 PM, Daniel Stenberg wrote:
> On Sun, 28 Jan 2018, Daniel Stenberg wrote:
>> Yes, I noticed this too and it is highly annoying since it now keeps
>> making our CI builds red. I tried to reproduce it on my Mac but for
>> some reason it doesn't fail when I run it! :-/
> I managed to trigger the bug on macos now. It turns out ISALNUM()
> returns TRUE on macos and FALSE on Linux when given the char 'ÿ'
> (0xc3) as input.
> Further, isalnum() is apparently depending on locale. Both my Linux
> and macos machines use the en_US.UTF-8 locale. However, if I set
> "LANG=C" before I run unit1307, the test case no longer fails!
> I'm afraid there's but one conclusion to draw from this: we need to
> make and use a custom isalnum() function for this. And to be really
> sure I figure we should cover the other is*() macros as well as they
> may very well contain the same sort of weaknesses.
Totally agreed, I think it is the wisest thing we can do, not only for
curl_fnmatch, but for the whole library.

In addition, if isalnum considers its argument as 8-bit only, it is
impossible to determine if the first byte of an arbitrary encoding
multibyte character represents an alphanum, whatever the locale is.
I think our own implementation of ctypes.c equivalent functions should
always return false for values < 0 or >= 0x80.

Your isalnum() explanation made me find the real bug: in a set, it is
not possible to follow an alphanum character with a non-alphanum. Try:

   { "[a@]",                    "a",                      MATCH },

This fails even on Linux.
This occurs identically on mac with the "[!ÿ]" test if ISALNUM(0xBF) is
The setcharset() function has to be changed to be much less "picky"
about what is currently considered as a pattern error.
Received on 2018-01-29