maybe a bug of Windows API PathMatchSpecW() ?

[WhoCares]

Consider the following code. PathMatchSpecW() is expected to do case-insensitive match(It seems that MS never documents this but it's true), so variable "matched" should be TRUE.

static const WCHAR pattern[] = L"的f";
const auto matched = PathMatchSpecW(L"的F", pattern);

But actually it is FALSE. Why?

I stepped into its asm code, it uses IsDBCSLeadByte(0x84) to check the first Chinese UTF-16 WCHAR '的'(0x7684), and IsDBCSLeadByte(0x84) returns TRUE for Chinese code page. Then it does case-sensitive comparison of 'f' and 'F', and finally returns FALSE.

I think it's WRONG to use IsDBCSLeadByte() for any byte of a UTF-16 string.
Perhaps MS guys add this logic to provide some compatibility with old weird strings?

[sendersu]

how about dig under the WinAPI hood?
using your lovely debugger!

[WhoCares]

I already debugged it

It's unexpected to use IsDBCSLeadByte() for a UTF-16 string.

Originally Posted by sendersu

how about dig under the WinAPI hood?
using your lovely debugger!

[WhoCares]

IsDBCSLeadByte() should be used for GBK/GB2312/GB18030 encoding etc.(CJK encodings)

Here is a good replacement for PatchMatchSpecW():
https://github.com/kirkjkrauss/MatchingWildcards

This article is also interesting:
https://www.codeproject.com/Articles/5163931/Fast-String-Matching-with-Wildcards-Globs-and-Giti