From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23123 invoked by alias); 31 Mar 2007 11:57:14 -0000 Received: (qmail 23101 invoked by uid 22791); 31 Mar 2007 11:57:13 -0000 X-Spam-Check-By: sourceware.org Received: from heller.inter.net.il (HELO heller.inter.net.il) (213.8.233.23) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 31 Mar 2007 12:57:12 +0100 Received: from HOME-C4E4A596F7 (IGLD-84-229-214-84.inter.net.il [84.229.214.84]) by heller.inter.net.il (MOS 3.7.3a-GA) with ESMTP id CGB31570 (AUTH halo1); Sat, 31 Mar 2007 14:56:59 +0300 (IDT) Date: Sat, 31 Mar 2007 11:57:00 -0000 Message-Id: From: Eli Zaretskii To: Joel Brobecker CC: dj@redhat.com, gcc-patches@gcc.gnu.org, gdb-patches@sourceware.org In-reply-to: <20070328202443.GD3956@adacore.com> (message from Joel Brobecker on Wed, 28 Mar 2007 13:24:43 -0700) Subject: Re: [RFA/libiberty] Enhance FILENAME_CMP for Windows filesystems Reply-to: Eli Zaretskii References: <20070328191845.GB3956@adacore.com> <200703281930.l2SJUYLW003949@greed.delorie.com> <20070328193743.GC3956@adacore.com> <20070328202443.GD3956@adacore.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: 2007-03/txt/msg00379.txt.bz2 > Date: Wed, 28 Mar 2007 13:24:43 -0700 > From: Joel Brobecker > Cc: gcc-patches@gcc.gnu.org, gdb-patches@sourceware.org > > Here is a revised version of the patch that should address both > comments (copyright notice, and lack of documentation): Sorry for chiming in only now, but I have a few minor comments: > @deftypefn Extension int filename_cmp (const char *@var{s1}, const char *@var{s2}) > > Return zero if the two paths @var{s1} and @var{s2} are equivalent. The GNU project frowns on using `path' to mean a file name. `Path' is reserved to $PATH-like lists of directories. In this context, I suggest to use `file name' instead. (There's one more instance of using `path' in the documentation of this function.) > If not equivalent, the returned value is similar to what strcmp would "strcmp" should be in @code{}, as it is a C symbol. > This function does not normalize path names. As a result, this function ^ Two blanks, please. > int > filename_cmp (const char *s1, const char *s2) > { > #ifndef HAVE_DOS_BASED_FILE_SYSTEM > return strcmp(s1, s2); While I realize that the original FILENAME_CMP macro did the same, as long as we are trying to do better, wouldn't it be nice if this function also collapsed multiple consecutive slashes or backslashes? > for (;;) > { > int c1 = tolower (*s1); > int c2 = tolower (*s2); Are we sure that strncasecmp's behavior wrt to locales is identical to that of tolower's? If not, the above will introduce a bug in non-English locales.