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.
next prev 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