From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8815 invoked by alias); 9 Mar 2011 12:35:14 -0000 Received: (qmail 8577 invoked by uid 22791); 9 Mar 2011 12:35:12 -0000 X-SWARE-Spam-Status: No, hits=-0.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_SOFTFAIL X-Spam-Check-By: sourceware.org Received: from mtaout22.012.net.il (HELO mtaout22.012.net.il) (80.179.55.172) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 09 Mar 2011 12:35:04 +0000 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0LHS00200IUWNX00@a-mtaout22.012.net.il>; Wed, 09 Mar 2011 14:35:01 +0200 (IST) Received: from HOME-C4E4A596F7 ([77.124.58.59]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LHS001P6IYBSS60@a-mtaout22.012.net.il>; Wed, 09 Mar 2011 14:35:01 +0200 (IST) Date: Wed, 09 Mar 2011 12:35:00 -0000 From: Eli Zaretskii Subject: Re: [patch libiberty include]: Add additional helper functions for directory-separator searching In-reply-to: <201103091146.36746.pedro@codesourcery.com> To: Pedro Alves Cc: gdb-patches@sourceware.org, dj@redhat.com, ktietz70@googlemail.com, binutils@sourceware.org, gcc-patches@gcc.gnu.org Reply-to: Eli Zaretskii Message-id: <83pqq0pj4b.fsf@gnu.org> References: <201103082238.00289.pedro@codesourcery.com> <201103091146.36746.pedro@codesourcery.com> Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org X-SW-Source: 2011-03/txt/msg00177.txt.bz2 > From: Pedro Alves > Date: Wed, 9 Mar 2011 11:46:36 +0000 > Cc: gdb-patches@sourceware.org, > dj@redhat.com, > ktietz70@googlemail.com, > binutils@sourceware.org, > gcc-patches@gcc.gnu.org > > On Wednesday 09 March 2011 05:29:09, Eli Zaretskii wrote: > > > Actually, is there any case where lbasename wouldn't > > > work instead of filename_dirrchr? > > > > Almost: lbasename returns a pointer one character after the last > > slash. It also skips the drive letter on DOS/Windows (which might be > > TRT, actually). > > I meant a valid use case in the code bases. Sorry for my misunderstanding. > Might as well cook up a (gdb) patch. Find it pasted below. Does it > look good to you? Yes, looks fine. Thanks. > The one's left are: 1 in a linux-native only file (never cares > for other filesystem semantics), and a couple in the coff and > mdebug readers. The latter could be rewritten in terms of > lbasename, but I'm not sure whether gcc outputs a literal '/' in > that case even when building on mingw. If so, and we changed them, > we'd be breaking reading these files on Windows Sorry, I don't understand how would that break on Windows. Could you elaborate? And what "couple of coff and mdebug readers" did you have in mind?