From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-patches-return-86901-listarch-gdb-patches=sources.redhat.com@sourceware.org>
Received: (qmail 10840 invoked by alias); 10 Jan 2012 17:25:55 -0000
Received: (qmail 10820 invoked by uid 22791); 10 Jan 2012 17:25:55 -0000
X-SWARE-Spam-Status: No, hits=-1.3 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; Tue, 10 Jan 2012 17:25:41 +0000
Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0LXL00800EZRJD00@a-mtaout22.012.net.il> for gdb-patches@sourceware.org; Tue, 10 Jan 2012 19:25:30 +0200 (IST)
Received: from HOME-C4E4A596F7 ([77.124.148.90]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LXL008SIF2HD530@a-mtaout22.012.net.il>; Tue, 10 Jan 2012 19:25:30 +0200 (IST)
Date: Tue, 10 Jan 2012 17:40:00 -0000
From: Eli Zaretskii <eliz@gnu.org>
Subject: Re: RFC: add relative file name handling for linespecs
In-reply-to: <m3d3arlez3.fsf@fleche.redhat.com>
To: Tom Tromey <tromey@redhat.com>
Cc: gdb-patches@sourceware.org
Reply-to: Eli Zaretskii <eliz@gnu.org>
Message-id: <83ipkjeagi.fsf@gnu.org>
References: <m3d3arlez3.fsf@fleche.redhat.com>
X-IsSubscribed: yes
Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <gdb-patches.sourceware.org>
List-Subscribe: <mailto:gdb-patches-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/gdb-patches/>
List-Post: <mailto:gdb-patches@sourceware.org>
List-Help: <mailto:gdb-patches-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: gdb-patches-owner@sourceware.org
X-SW-Source: 2012-01/txt/msg00298.txt.bz2

> From: Tom Tromey <tromey@redhat.com>
> Date: Tue, 10 Jan 2012 09:06:08 -0700
> 
> This needs at least a doc review.

Thanks, the documentation parts are okay.

> +/* See whether FILENAME matches SEARCH_NAME using the rule that we
> +   advertise to the user.

Why not say explicitly how the names are matched?  "The rule we
advertise" doesn't give any hint where to look for that rule, so the
issue remains a mystery and requires to read the source to glean what
this does.

> +  /* Either the names must completely match, or the character
> +     preceding the trailing SEARCH_NAME segment of FILENAME must be a
> +     directory separator.  */
> +  return (len == search_len
> +	  || IS_DIR_SEPARATOR (filename[len - search_len - 1]));

What about the (somewhat perverse) case of "d:foo/bar" and "foo/bar"
on Windows?