From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17466 invoked by alias); 18 Jun 2008 15:22:12 -0000 Received: (qmail 17457 invoked by uid 22791); 18 Jun 2008 15:22:12 -0000 X-Spam-Check-By: sourceware.org Received: from elasmtp-mealy.atl.sa.earthlink.net (HELO elasmtp-mealy.atl.sa.earthlink.net) (209.86.89.69) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 18 Jun 2008 15:21:52 +0000 Received: from [137.122.72.120] (helo=macbook-2.local) by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1K8zTn-00074w-Gz; Wed, 18 Jun 2008 11:21:47 -0400 Message-ID: <4859280A.8000006@earthlink.net> Date: Wed, 18 Jun 2008 18:39:00 -0000 From: Stan Shebs User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Eli Zaretskii CC: Daniel Jacobowitz , vladimir@codesourcery.com, gdb-patches@sources.redhat.com Subject: Re: Better realpath References: <200806141024.41812.vladimir@codesourcery.com> <200806141614.07742.vladimir@codesourcery.com> <20080615032653.GA5214@caradoc.them.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: ae6f8838ff913eba0cc1426638a40ef67e972de0d01da940086ab30fc0b2c8b5299e84ee0fa93a8d350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c 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/msg00333.txt.bz2 Eli Zaretskii wrote: >> Date: Sat, 14 Jun 2008 23:26:54 -0400 >> From: Daniel Jacobowitz >> Cc: Vladimir Prus , >> gdb-patches@sources.redhat.com >> >> It seems to me that the thing to do is eliminate gdb_realpath in favor >> of lrealpath. That's supposed to be a portable version of realpath, >> so realpath semantics seem like the way to go. >> > > I don't mind doing so, although libiberty has other customers, which > could make it harder for us to do what we think is right (if it > happens to be different from what lrealpath does now). Note that > right now, lrealpath does not behave consistently with realpath (if > the latter is unavailable), so it cannot be regarded as a portable > version of realpath, at least not entirely so. > Most likely libiberty's other customers (read: other GNU components :-) ) want consistent behavior, and I'm inclined to think they would prefer consistency with each other over consistency with "real" realpath. There is nothing preventing us from adding additional functions to libiberty also, if we want to split functionality in a better way. One maintenance bonus of libiberty usage that it forestalls the introduction of subtle dependencies on GDB internals, always a hazard with our tangle of headers. Stan