From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17306 invoked by alias); 15 Jun 2008 03:20:16 -0000 Received: (qmail 17296 invoked by uid 22791); 15 Jun 2008 03:20:15 -0000 X-Spam-Check-By: sourceware.org Received: from mtaout1.012.net.il (HELO mtaout1.012.net.il) (84.95.2.1) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sun, 15 Jun 2008 03:19:55 +0000 Received: from HOME-C4E4A596F7 ([84.228.242.237]) by i-mtaout1.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0K2H004DLJ8DLSH0@i-mtaout1.012.net.il> for gdb-patches@sources.redhat.com; Sun, 15 Jun 2008 06:33:50 +0300 (IDT) Date: Sun, 15 Jun 2008 17:37:00 -0000 From: Eli Zaretskii Subject: Re: Better realpath In-reply-to: X-012-Sender: halo1@inter.net.il To: Vladimir Prus Cc: gdb-patches@sources.redhat.com Reply-to: Eli Zaretskii Message-id: Content-transfer-encoding: 7BIT References: <200806141024.41812.vladimir@codesourcery.com> <200806141614.07742.vladimir@codesourcery.com> 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: 2008-06/txt/msg00274.txt.bz2 > 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. > >> 3. The matter of filename existance is a behaviour issue, and I think > >> I can modify gdb_realpath to perform a check explicitly. OTOH, it's not > >> clear if any code actually expects file existane check to be performed. > > > > I don't think it matters whether the callers expect it or not. As > > long as we use realpath, which always checks the result for existence, > > we should do the same in the other branches, so that the resulting GDB > > function behaves consistently. > > If no caller of that function cares about this aspect of behaviour, why > should we bother about consistency. Because gdb_realpath is an infrastructure function, so we should care about future, as yet non-existent, callers, not only about the existing ones. > > Alternatively, we could refrain from > > using realpath, in which case we should consistently _not_ require > > that the file exists. > > ... as I've said, I can modify gdb_realpath to check for file existance, > on Windows, which will make the behaviour of gdb_realpath the same > everywhere. The question is, what kind of consistent behavior do we want. Personally, I think realpath's behavior is wrong for most GDB usages, that's why I suggested the alternative.