From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29787 invoked by alias); 22 Dec 2011 17:59:44 -0000 Received: (qmail 29774 invoked by uid 22791); 22 Dec 2011 17:59:42 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 22 Dec 2011 17:59:29 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id D1B5E2BADAB; Thu, 22 Dec 2011 12:59:28 -0500 (EST) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id iqqgDFDhi2l1; Thu, 22 Dec 2011 12:59:28 -0500 (EST) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 60D402BADB2; Thu, 22 Dec 2011 12:59:28 -0500 (EST) Received: by joel.gnat.com (Postfix, from userid 1000) id D14F3145615; Thu, 22 Dec 2011 09:59:18 -0800 (PST) Date: Thu, 22 Dec 2011 18:16:00 -0000 From: Joel Brobecker To: Eli Zaretskii Cc: gdb-patches@sourceware.org Subject: Re: [RFA/commit] Improve gdb_realpath for Windows hosts Message-ID: <20111222175918.GU23376@adacore.com> References: <1324574084-7971-1-git-send-email-brobecker@adacore.com> <837h1ozf6p.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <837h1ozf6p.fsf@gnu.org> User-Agent: Mutt/1.5.20 (2009-06-14) 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: 2011-12/txt/msg00788.txt.bz2 > > gdb/ChangeLog: > > > > * utils.c (gdb_realpath): Add better support for Windows hosts. > > > > Tested on x86-windows. Any objection to this? > > Looks good to me. Although there's a subtle semantic difference > between `realpath' on Posix platforms and GetFullPathName: the former > requires the file to exist, while the latter does not. But I reckon > we handle this somewhere... Thanks for taking a look! I was not aware of its behavior when the file does not exist. It's strange, because MSN says: This function does not verify that the resulting path and file name are valid, or that they see an existing file on the associated volume. It's ambiguous, and you're probably right. But it explains my surprise. That being said, it's treated as a normalization error, and we fallback to xstrdup in that case, hoping that the user then uses the a filename that matches according to filename_cmp (it deals with casing and directory separators, but not the case of consecutive directory separators). In other words, if the file does not exist, we're back to where we were before this patch. > Did you test this with UNC file names? I did not test with UNC file names, no. Mostly because it never entered my mind. I'm not a Windows person I'm afraid, never used it unless asked to fix a bug that reproduces on this system only. And I don't know if this is something I could do with our machines at work. That being said, MSDN does confirm that it should work (I think!): Share and volume names are valid input for lpFileName. For example, the following list identities the returned path and file names if test-2 is a remote computer [...]: # If you specify "\\test-2\q$\lh" the path returned is "\\test-2\q$\lh" # If you specify "\\?\UNC\test-2\q$\lh" the path returned is "\\?\UNC\test-2\q$\lh" -- Joel