Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: gdb-patches@sourceware.org
Cc: Christopher Faylor <me@cgf.cx>
Subject: Re: RFA: Use lrealpath instead of gdb_realpath
Date: Sun, 29 May 2005 14:21:00 -0000	[thread overview]
Message-ID: <uwtpi8m44.fsf@gnu.org> (raw)
In-Reply-To: <20050528234233.GA3440@nevyn.them.org> (message from Daniel Jacobowitz on Sat, 28 May 2005 19:42:34 -0400)

> Date: Sat, 28 May 2005 19:42:34 -0400
> From: Daniel Jacobowitz <drow@false.org>
> Cc: Christopher Faylor <me@cgf.cx>
> 
> Eli, I understand that you think this is a bad choice.  However, the mingw32
> maintainers disagree.  My only motivation here is to get rid of the
> duplicated function

As your patch clearly shows, gdb_realpath is _not_ identical to
lrealpath.  For example, it doesn't have the Windows code that calls
GetFullPathName.  So we are not replacing a duplicated function, not
really.

Let me explain my concerns about using lrealpath in its current shape:

 . The Windows code in lrealpath converts all forward slashes to
   backslashes, which I think is a bad idea.  By contrast, the current
   gdb_realpath would leave existing forward slashes alone.  That is
   an incompatible change, and my gut feeling is that we should not
   risk it.  On top of that, I think we always use '/' to generate
   file names, so with this change we will produce ugly file names
   like D:\foo\bar/baz.c.

 . The Windows code in lrealpath downcases the file name returned by
   GetFullPathName.  That might be okay for when we need a canonical
   file name suitable for comparison by strcmp, but in the case of GDB
   it is IMHO a misservice to the user, since (a) we correctly use
   FILENAME_CMP to compare file names, and (b) presenting downcased
   file names to the user is a gratuitous ugliness that we should try
   to avoid.

 . GetFullPathName is documented to work even if the path and/or the
   file name do not exist.  By contrast, both realpath and
   canonicalize_file_name are documented to fail if some or all of the
   components of the resulting file name do not exist.  Thus, I submit
   that the Windows code is not a faithful emulation of the Posix
   code, and thus could cause subtle bugs/misfeatures.

 . lrealpath uses strdup while gdb_realpath uses xstrdup.  Thus, if we
   use lrealpath, we will behave differently when we run out of
   memory.

For these reasons, I believe we should not switch to lrealpath until
we address these issues.  We could resolve them either by suitable
modifications to lrealpath (but then we would need to verify that
other users of lrealpath don't suffer; e.g., I suspect that the
downcasing part is there because some program uses strcmp to compare
file names), or by retaining gdb_realpath with suitable changes to
support the MinGW build.

> --- symtab.c	8 Mar 2005 04:34:44 -0000	1.145
> +++ symtab.c	28 May 2005 23:13:40 -0000
> @@ -163,7 +163,7 @@ lookup_symtab (const char *name)
>      {
>        full_path = xfullpath (name);
>        make_cleanup (xfree, full_path);
> -      real_path = gdb_realpath (name);
> +      real_path = lrealpath (name);
>        make_cleanup (xfree, real_path);
>      }

Can we please talk about this snippet?  I don't understand the need
for calling both xfullpath and lrealpath here.  If that's because
lrealpath might fail if the basename does not exist, I think we should
call lrealpath first and fall back on xfullpath only after that.


  parent reply	other threads:[~2005-05-29  8:37 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-05-28 23:59 Daniel Jacobowitz
2005-05-29  1:59 ` Christopher Faylor
2005-05-29 14:21 ` Eli Zaretskii [this message]
2005-05-29 14:23   ` Daniel Jacobowitz
2005-05-29 17:49     ` Christopher Faylor
2005-05-29 18:22     ` Eli Zaretskii
2005-05-29 18:27       ` Christopher Faylor
2005-05-30 16:54         ` Eli Zaretskii
2005-05-29 19:28       ` Daniel Jacobowitz
2005-05-29 20:16         ` Christopher Faylor
2005-05-30 15:14           ` Christopher Faylor
2005-05-30 18:32           ` Eli Zaretskii

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=uwtpi8m44.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=gdb-patches@sourceware.org \
    --cc=me@cgf.cx \
    /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