On 2025-01-14 Bruno Haible wrote:
> Maybe we should spread the word about the UTF-8 mode, that you made
> us aware of recently [1].
Yes, UTF-8 compatibility would be good nowadays. If a user has set it
globally in Windows settings (a beta feature), then programs use UTF-8
even when they don't have it set in an application manifest.
(1) While UTF-8 can result in crazy-long file name *components* (over
259 bytes without \0), they aren't common. If Gnulib's readdir and
stat have the limit, it might not matter too much in practice.
"open" doesn't have such a limit.
My patch had 255 * MB_LEN_MAX + 1, and MB_LEN_MAX is 5. Now I think
it's execessive even in a theoretical case. I'm not sure but I
suspect that UTF-8 is the only *locale* code page that has longer
than two-byte characters. So 255 * 3 + 1 should be enough which is
still a big number.
(2) Making programs "long path aware" could matter more. The limit of
259 wide chars (excluding the \0) is enforced on the absolute file
name even if program uses relative file names. The constant MAX_PATH
appears in very few files in Gnulib but opendir.c is one of them.
The \\?\ prefix bypasses the MAX_PATH limit but long path aware
programs don't need that trick.
I don't plan to continue my side quest to Windows issues further. :-)
Thanks for the comments!
--
Lasse Collin
