Am 24.01.2023 um 17:52 schrieb Eli Zaretskii:
From: Ian Lance Taylor <i...@golang.org>
Date: Tue, 24 Jan 2023 06:35:21 -0800
Cc: g...@hazardy.de, gcc-patc...@gcc.gnu.org, gcc@gcc.gnu.org
On Windows it seems that MAX_PATH is not
a true limit, as an extended length path may be up to 32767 bytes.
The limit of 32767 characters (not bytes, AFAIK) is only applicable
when using the Unicode (a.k.a. "wide") versions of the Windows Win32
APIs, see
https://learn.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation
Since the above code uses GetModuleFileNameA, which is an "ANSI"
single-byte API, it is still subject to the MAX_PATH limitation, and
MAX_PATH is defined as 260 on Windows headers.
Thanks. Should this code be using GetModuleFileNameW? Or would that
mean that the later call to open will fail?
We'd need to use _wopen or somesuch, and the file name will have to be
a wchar_t array, not a char array, yes. So this is not very practical
when file names need to be passed between functions, unless they are
converted to UTF-8 (and back again before using them in Windows APIs).
And note that even then, the 260-byte limit could be lifted only if
the user has a new enough Windows version _and_ has opted in to the
long-name feature by turning it on in the Registry. Otherwise, file
names used in "wide" APIs can only break the 260-byte limit if they
use the special format "\\?\D:\foo\bar", which means file names
specified by user outside of the program or file names that come from
other programs will need to be reformatted to this special format.
260 bytes does not seem like very much for a path name these days.
That's true. But complications with using longer file names are still
a PITA on Windows, even though they are a step closer to practically
possible.
That was basically also my reasoning for choosing the A variant instead of W.
