From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2118 invoked by alias); 28 Feb 2010 17:18:36 -0000 Received: (qmail 2101 invoked by uid 22791); 28 Feb 2010 17:18:35 -0000 X-Spam-Check-By: sourceware.org Received: from aquarius.hirmke.de (HELO calimero.vinschen.de) (217.91.18.234) by sourceware.org (qpsmtpd/0.83/v0.83-20-g38e4449) with ESMTP; Sun, 28 Feb 2010 17:18:31 +0000 Received: by calimero.vinschen.de (Postfix, from userid 500) id F03E46D42F5; Sun, 28 Feb 2010 18:18:28 +0100 (CET) Date: Sun, 28 Feb 2010 17:18:00 -0000 From: Corinna Vinschen To: gdb-patches@sourceware.org Subject: Re: [RFA] windows-nat.c: Cygwin: Port to Cygwin 1.7 Message-ID: <20100228171828.GK5683@calimero.vinschen.de> Reply-To: gdb-patches@sourceware.org Mail-Followup-To: gdb-patches@sourceware.org References: <20100228150844.GH5683@calimero.vinschen.de> <837hpxcmp0.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <837hpxcmp0.fsf@gnu.org> User-Agent: Mutt/1.5.20 (2009-06-14) X-IsSubscribed: yes 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 X-SW-Source: 2010-02/txt/msg00685.txt.bz2 On Feb 28 19:08, Eli Zaretskii wrote: > > Date: Sun, 28 Feb 2010 16:08:44 +0100 > > From: Corinna Vinschen > > > > - The maximum path length in Cygwin is no longer MAX_PATH. Rather it > > is PATH_MAX, which is now 4096. Actually, even paths up to 32K are > > supported, which is the maximum path length of the underlying Windows, > > but usually 4K is more than enough. > > I'd suggest not to introduce arbitrary limits. If we are going to use > the Unicode APIs, let's support the full 32K length they give us. Some buffers are on the stack and would have an unnecessary big size. PATH_MAX, 4K, is more than enough especially since the names of DLLs are stored in a buffer which is restricted to SO_NAME_MAX_PATH_SIZE, which is 512 bytes ATM. > > - The Windows ANSI functions have two drawbacks. > > > > - They return paths always in the default ANSI codepage, which is > > typically not the default codeset used in Cygwin 1.7 anymore. UTF-8 > > is now the default codeset in Cygwin. > > > > - They are restricted to a path length of MAX_PATH bytes. > > > > Since UTF-8 support and support for long paths are key changes in > > Cygwin 1.7, Cygwin now uses only Unicode Windows or native NT > > functions internally. To overcome the restrictions of the Win32 ANSI > > functions in GDB as well, the patch changes the affected calls to use > > the Unicode variation instead, too. > > But I see that you left the ANSI APIs in place for the non-Cygwin > build. Isn't it better to switch that to Unicode as well? I guess so, but that's not my domain. I changed only the code which affects Cygwin. Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat