From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 730 invoked by alias); 18 Jun 2008 07:33:30 -0000 Received: (qmail 721 invoked by uid 22791); 18 Jun 2008 07:33:29 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 18 Jun 2008 07:33:12 +0000 Received: (qmail 1988 invoked from network); 18 Jun 2008 07:33:10 -0000 Received: from unknown (HELO localhost) (vladimir@127.0.0.2) by mail.codesourcery.com with ESMTPA; 18 Jun 2008 07:33:10 -0000 From: Vladimir Prus To: Eli Zaretskii Subject: Re: Better realpath Date: Wed, 18 Jun 2008 15:22:00 -0000 User-Agent: KMail/1.9.9 Cc: gdb-patches@sources.redhat.com References: <200806141024.41812.vladimir@codesourcery.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200806181133.11578.vladimir@codesourcery.com> 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: 2008-06/txt/msg00331.txt.bz2 On Sunday 15 June 2008 07:18:45 Eli Zaretskii wrote: > > From: Vladimir Prus > > Date: Sun, 15 Jun 2008 00:03:26 +0400 > > > > > Fixing those is not a big deal, so how about making gdb_realpath > > > correct both cosmetically and behavior-wise? > > > > I'm not sure how big deal that is, but it appears we have a major > > functionality bug for 3 years already, at least. I'm interested in > > fixing that bug, and if somebody (for example you) find those cosmetic > > changes important, I think they can be address by follow-up patches. > > That can be said about every patch submitted here. We still request > that contributors do a clean job, instead of allowing their patches to > go in, and then fixing their job by follow-up patches. I'm saying > let's do a clean job in this case. The problem in this case is that: - you appear to be the only one who cares about this cosmetics, *and* - this issues is unfixed for 3 years, Which leads to me believe that those cosmetic issues are of bikeshed nature, with no concensus likely in next 3 years. And keeping GDB with a major bug does not seem like a good idea. My opinion here is that: - The bug must be fixed, - Having gdb_realpath copy-paste bunch of code from libibery's lrealpath is not acceptable. Note that if we worry that changes we propose will break other libibery's clients, we can add another function, say lrealpath2, that does what we need, refactor guts of current lrealpath into an internal function, and make both lrealpath and lrealpath2 call that internal function. The first question is about checking for file existance. Assuming we don't want this check, we basically get to rewrite gdb_realpath from scratch, making it operate on a purely syntactic basis. Such a rewrite is probably not very hard, and I have open-source code for that from another project -- though license issues can be messy. I'm not sure if lack of symlink resolution will be an issue. Assuming we want file existance checking, we'd just have to make Windows code do the check. Second is down-casing. If we don't want brute down-casing, and we want truly canonic names of paths, then "C:/documents and settings" should become "C:/Documents and Settings", and that requires actually poking at the file system to see what exact spelling is stored. And that requires that all path components exist. My reading of msdn suggests that GetFullPathName does not do that, and I don't know if any other function does that. I have an implementation in terms of FindFirstFile that should compile on Win95 and later and do the right thing, but it's tricky, and again, there are license issues. We can also just skip downcasing, and rely on gdb file comparison macros to handle that. Finally, there's slash direction. I think this is non-issue -- we can either make GDB use "\" everywhere, or normalize to "/", either in lrealpath, or elsewhere. So, the approaches are: 1. Make lrealpath always check for file existance, and: - Either revise window case to get spelling from the filesystem, or - Add a flag "I don't care about case differences, don't downcase" 2. Write another function that does purely syntactic normalization of paths. It will not change case of paths on windows, naturally. Which of those approaches you: - Will be willing to accept? - Will be willing to hack on? Thanks, Volodya