> 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.
