> Date: Mon, 23 Jan 2023 15:00:56 -0800
> Cc: gcc-patches@gcc.gnu.org, g...@gcc.gnu.org
> From: Ian Lance Taylor via Gcc <g...@gcc.gnu.org>
>
> > +#ifdef HAVE_WINDOWS_H
> > +
> > +static char *
> > +windows_get_executable_path (char *buf, backtrace_error_callback
> > error_callback,
> > + void *data)
> > +{
> > + if (GetModuleFileNameA (NULL, buf, MAX_PATH - 1) == 0)
> > + {
> > + error_callback (data,
> > + "could not get the filename of the current
> > executable",
> > + (int) GetLastError ());
> > + return NULL;
> > + }
> > + return buf;
> > +}
>
> Thanks, but this seems incomplete. The docs for GetModuleFileNameA
> say that if the pathname is too long to fit into the buffer it returns
> the size of the buffer and sets the error to
> ERROR_INSUFFICIENT_BUFFER. It seems to me that in that case we should
> allocate a larger buffer and try again.
This is correct in general, but not in this particular case.
> 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.
