Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Joel Brobecker <brobecker@adacore.com>
Cc: gcc-patches@gcc.gnu.org, gdb-patches@sourceware.org
Subject: Re: [RFA/libiberty] Fix documentation issues in filename_cmp.c
Date: Fri, 06 Apr 2007 09:05:00 -0000	[thread overview]
Message-ID: <u3b3d50ul.fsf@gnu.org> (raw)
In-Reply-To: <20070406061218.GB3471@adacore.com> (message from Joel Brobecker 	on Thu, 5 Apr 2007 23:12:18 -0700)

> Date: Thu, 5 Apr 2007 23:12:18 -0700
> From: Joel Brobecker <brobecker@adacore.com>
> Cc: gcc-patches@gcc.gnu.org, gdb-patches@sourceware.org
> 
> Eli,
> 
> > > 2007-04-05  Joel Brobecker  <brobecker@adacore.com>
> > > 
> > >         * filename_cmp.c (filename_cmp): Improve documentation.
> > 
> > Thanks, I am happy, as far as the documentation goes.
> 
> Am I to understand that you are not happy with the code?

Well, I did have comments about that, and they were left unresolved ;-)

>   1. Fold multiple consecutive slash/backslash characters into
>      single slash/backslash;
> 
>      To do that without modifying the source filenames, we need to
>      allocate some memory locally to manipulate a copy of that filename.

This is a misunderstanding: I didn't mean that we should modify the
source file names.  What I meant is that the comparison should ignore
multiple consecutive slashes, so that, say, "/foo/bar/baz" compares
equal to "/foo//bar////baz" (and to "\foo//bar\/\baz" on Windows).
(However, note that, as Chris pointed out, double slash at the
beginning of a file name, as in "//foo/bar", are significant on
Windows.)

>      My take on this is that the file names we have seen, at least in
>      the debugging information, have been consistent; and thus this
>      enhancement would end up having no actual effect. I would wait
>      until we come across a case where this is a problem before
>      going that way.

I've seen quite a few of such situations, actually.  And in any case,
good engineering doesn't need examples to know what's Right ;-)

>   2. The possible introduction of a bug with certain locales because
>      the function used in place of strcasecmp uses tolower.
> 
>      For this one, as I said, I don't know, and I'm not sure where
>      to start looking for the answer.

How about using your function with LANG set to various values?  That
should at least tell us whether strcasecmp and tolower do the same
thing; if they do, there's no problem here.


  reply	other threads:[~2007-04-06  9:05 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-04-05 17:27 Joel Brobecker
2007-04-05 18:36 ` DJ Delorie
2007-04-06  6:02   ` Joel Brobecker
2007-04-05 18:44 ` Eli Zaretskii
2007-04-06  6:10   ` Joel Brobecker
2007-04-06  9:05     ` Eli Zaretskii [this message]
2007-04-06 10:00       ` Dave Korn
2007-04-07 17:35       ` Daniel Jacobowitz
2007-04-07 17:52         ` Eli Zaretskii
2007-04-11  7:24           ` Joel Brobecker
2007-04-11 18:28             ` Eli Zaretskii
2007-04-11 20:33               ` Ian Lance Taylor
2007-05-03 15:36                 ` [RFA/libiberty] use TOLOWER instead of tolower " Joel Brobecker
2007-05-03 16:31                   ` Ian Lance Taylor
2007-05-03 23:40                     ` Joel Brobecker
2007-05-04  7:18                   ` Eli Zaretskii
2007-04-11  7:27       ` [RFA/libiberty] Fix documentation issues " Joel Brobecker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=u3b3d50ul.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=brobecker@adacore.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=gdb-patches@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox