From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24935 invoked by alias); 18 Dec 2013 17:03:32 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 24922 invoked by uid 89); 18 Dec 2013 17:03:31 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_SOFTFAIL autolearn=no version=3.3.2 X-HELO: mtaout22.012.net.il Received: from mtaout22.012.net.il (HELO mtaout22.012.net.il) (80.179.55.172) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 18 Dec 2013 17:03:29 +0000 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0MY000E00HZ3HU00@a-mtaout22.012.net.il> for gdb-patches@sourceware.org; Wed, 18 Dec 2013 19:02:47 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MY000EGYI0M6S80@a-mtaout22.012.net.il> for gdb-patches@sourceware.org; Wed, 18 Dec 2013 19:02:47 +0200 (IST) Date: Wed, 18 Dec 2013 17:03:00 -0000 From: Eli Zaretskii Subject: Re: [RFA] Fix cygwin compilation failure due to nameless LOAD_DLL_DEBUG_EVENT causes ntdll.dll to be missing In-reply-to: <20131218160707.GV30010@calimero.vinschen.de> To: gdb-patches@sourceware.org Reply-to: Eli Zaretskii Message-id: <834n66ccs9.fsf@gnu.org> References: <52ab8d0e.8aa2420a.30ff.ffffd8f1SMTPIN_ADDED_BROKEN@mx.google.com> <52AF3493.9090708@redhat.com> <20131218112045.GQ30010@calimero.vinschen.de> <83bo0ecgdw.fsf@gnu.org> <20131218160707.GV30010@calimero.vinschen.de> X-IsSubscribed: yes X-SW-Source: 2013-12/txt/msg00710.txt.bz2 > Date: Wed, 18 Dec 2013 17:07:07 +0100 > From: Corinna Vinschen > > > [1:text/plain Hide] > > On Dec 18 17:45, Eli Zaretskii wrote: > > > Date: Wed, 18 Dec 2013 12:20:45 +0100 > > > From: Corinna Vinschen > > > > > > In theory, you should never use the ANSI API on Windows, unless you're > > > still building GDB for Windows 9x, which should be really, really dead > > > by now, hopefully. > > > > Did we decide to drop Windows 9X support? Unicode APIs will not work > > on Windows 9X (in fact, I think Windows will refuse to run such a > > gdb.exe), unless we link against unicows.dll. > > I didn't say that. I said I *hoped* that 9x is dead by now. It's still widely used in some parts of the world, I'm told. > > > - The ANSI API only supports a single- or doublebyte codeset in almost > > > all language versions of Windows. There are only a handful languages > > > which are using UTF-8 as ANSI codeset on Windows, most use something > > > like CP1252 or some other codeset which is not capable of handling all > > > UNICODE characters. > > > > > > - The ANSI API restricts filenames to MAX_PATH (260) characters, while > > > the UNICODE API and the underlying OS allow paths of up to 32K. > > > > But the MinGW build of GDB is still in the ANSI codepage world, and > > will probably remain there for the observable future, because Windows > > runtime and file APIs don't understand UTF-8 encoding, > > They do understand UNICODE if you use the wide char functions. That requires conversion back and forth, something best done in wrapper functions, because otherwise we will need ugly ifdef's all over the place. > Implementing wrappers for the msvcrt functions used elsewhere in the > code at one point shouldn't be that hard, just a bit of boring work. Well, I just came up from such boring work (in Emacs), and I can tell you it's nowhere near "a bit". Maybe someone who can work on this full-time could do this quickly, but there's no such person on board for MinGW GDB at this time, AFAIK. > > Are you sure that 32K capability cannot be had with ANSI file names > > using the \\?\ notation? > > Yes. The \\?\ notation only works in the UNICODE API[*]. The reason > is that the ANSI API is just a thin layer over the actual UNICODE > functionality, and the conversion from ANSI to UNICODE is done using a > per-thread fixed-size buffer of 520 bytes. Does this mean that using \\?\ with ANSI-encoded file names buys us 520-byte file names? > The ANSI API is really something which should be avoided these > days. Unfortunately, given the way most Unix packages are written (using 'char *' for file names), this is easier said than done. E.g., I'm not aware of any other GNU package except Emacs that supports Unicode APIs, and I don't think that's an accident.