Re: [RFA] Fix cygwin compilation failure due to nameless LOAD_DLL_DEBUG_EVENT causes ntdll.dll to be missing

[Eli Zaretskii <eliz at gnu dot org>]

> Date: Wed, 18 Dec 2013 21:54:16 +0100
> From: Corinna Vinschen <vinschen@redhat.com>
> 
> > > There's a lot of theory here.  Did you actually *try* it?
> > 
> > No.  Who can afford to try everything, unless they are paying you to
> > do that?
> 
> Well, it might not take much more time than musings in email...
> 
> > > I just did:
> > > 
> > > ===========================================
> > > #include <stdio.h>
> > > #include <errno.h>
> > > 
> > > int main(void)
> > > {
> > >   FILE *fp;
> > > 
> > >   fp = _wfopen (L"\\\\?\\C:\\Windows\\System32\\ntdll.dll", L"r");
> > >   if (!fp)
> > >     printf ("_wfopen w/ long pathname fails, errno = %d\n", errno);
> > >   else
> > >     {
> > >       printf ("_wfopen w/ long pathname works\n");
> > >       fclose(fp);
> > >     }
> > >    return 0;
> > > }
> > > ===========================================
> > 
> > Thanks, that's good to know.  But that's just one CRT function.  There
> > are a gazillion of them, and I'm quite sure some use MAX_PATH of 260
> > internally.  Just grep the sources of the CRT functions.
> 
> Sigh.

Since you were that unhappy, I took some time to test about a dozen of
the more popular CRT functions that deal with file names and accept
wchar_t arguments.  Most of them worked with long file names in the
\\?\ format, but some didn't.

First, _wchdir failed consistently with file names longer than 260.
Which might not be a surprise, since SetCurrentDirectoryW is
documented to be limited to MAX_PATH characters.  But it does mean
that any application which wishes to lift the 260-char limitation will
need to replace chdir and getcwd (and DTRT for each thread).

Next, _wstat fails for any file name in the \\?\ form, even if it
doesn't exceed the 260-character limit.  By contrast, FindFirstFileW,
on which AFAIK the MS implementation of 'stat' is based, has no
problem with such file names, and works with filenames up to 32K
characters.

On Windows XP (but not on Windows 7), _wfullpath also failed for long
file names.

The upshot of all this is that it's not enough to just switch to
wchar_t and \\?\ form of file names, there's some non-trivial support
code that will need to be written to take advantage of that in any
sufficiently large application (such as GDB).

Moreover, even just using Unicode APIs is of questionable value in GDB
(as in any other console program on Windows), because:

  . supporting Unicode on the console will need very serious changes
    in Readline and in ui-*.c modules; without such changes, one can
    never enter or display file names outside of the current ANSI
    codepage

  . the Windows console has very weak support for non-ASCII fonts even
    when Unicode APIs are used to read and write to the console
    (basically, anything outside of Europe cannot be displayed)

  . any external libraries against which GDB is linked are likely not
    to support Unicode file names or UTF-16 text, so you cannot easily
    communicate with them without losing Unicode capabilities

  . suppose you get from a Unicode API, such as GetModuleFileNameW, a
    file name that cannot be expressed in the current ANSI codepage --
    what can you do with such a file name in GDB? probably nothing
    except displaying an error message

So I think the benefits of switching the MinGW GDB to Unicode APIs are
questionable, although if someone steps forward and does a clean job
for that, I'm quite sure the patches will be more than welcome.