From: Doug Evans <dje@google.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: tromey@redhat.com, gdb-patches@sourceware.org
Subject: Re: [RFA] Add -s option to source command.
Date: Mon, 12 Apr 2010 17:31:00 -0000 [thread overview]
Message-ID: <o2he394668d1004121031gee9183c8g3aa53b249827c121@mail.gmail.com> (raw)
In-Reply-To: <j2ye394668d1004091249m78149f10ge00ed6470c3526cd@mail.gmail.com>
On Fri, Apr 9, 2010 at 12:49 PM, Doug Evans <dje@google.com> wrote:
> On Fri, Apr 9, 2010 at 12:31 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>>> Date: Fri, 9 Apr 2010 11:12:27 -0700
>>> From: Doug Evans <dje@google.com>
>>> Cc: tromey@redhat.com, gdb-patches@sourceware.org
>>>
>>> > This is fine, but what if @var{filename} is @file{d:/foo/myscript} (on
>>> > Windows)?
>>>
>>> source.c:openp() doesn't handle that case, it just blindly concatenates.
>>> [presumably because it hasn't needed to]
>>>
>>> I don't have an opinion on what *should* happen here.
>>> Possibilities are to either not try or remove the drive spec.
>>
>> My vote is for removing the drive letter. The other alternative means
>> that absolute file names are handled inconsistently across platforms
>> (I assume that not trying to look for absolute file name on Posix
>> platforms will not be a useful behavior).
[note: filenames.h uses the term "semi-absolute" for d:foo]
I don't have an opinion on whether to treat d:/foo vs d:foo
differently in this context.
> I can make a case for either choice on Posix platforms: ie. whether to
> search or to not search. I don't know which is better, but openp()
> already does the search for absolute path names (if
> OPF_SEARCH_IN_PATH is specified), so I lean towards not introducing
> something new.
>
> Does anyone know if there's existing code to strip a drive letter if present?
> [It's trivial to do - but I fear the discussion involved in getting a
> patch in that does it The Right Way.]
>
I'm all for stripping the drive letter if it's agreeable to everyone else.
I will send this to the binutils list for approval tomorrow, unless
someone has a better suggestion.
openp would then check HAVE_DRIVE_SPEC (path) and if true call
STRIP_DRIVE_SPEC (path)
before concatenating the search path with the user-provided path.
I put these macros in filenames.h because that's where
IS_ABSOLUTE_PATH and IS_DIR_SEPARATOR live.
2010-04-12 Doug Evans <dje@google.com>
* filenames.h (HAVE_DRIVE_SPEC, STRIP_DRIVE_SPEC): New macros.
Index: filenames.h
===================================================================
RCS file: /cvs/src/src/include/filenames.h,v
retrieving revision 1.5
diff -u -p -r1.5 filenames.h
--- filenames.h 21 Mar 2008 23:40:18 -0000 1.5
+++ filenames.h 12 Apr 2010 17:19:32 -0000
@@ -5,7 +5,7 @@
use forward- and back-slash in path names interchangeably, and
some of them have case-insensitive file names.
- Copyright 2000, 2001, 2007 Free Software Foundation, Inc.
+ Copyright 2000, 2001, 2007, 2010 Free Software Foundation, Inc.
This file is part of BFD, the Binary File Descriptor library.
@@ -37,17 +37,27 @@ extern "C" {
#endif
#define IS_DIR_SEPARATOR(c) ((c) == '/' || (c) == '\\')
+
+#define HAVE_DRIVE_SPEC(f) (((f)[0]) && ((f)[1] == ':'))
+
+/* Remove the drive spec from F, assuming HAVE_DRIVE_SPEC (f).
+ The result is a pointer to the remainder of F. */
+#define STRIP_DRIVE_SPEC(f) ((f) + 2)
+
/* Note that IS_ABSOLUTE_PATH accepts d:foo as well, although it is
only semi-absolute. This is because the users of IS_ABSOLUTE_PATH
want to know whether to prepend the current working directory to
a file name, which should not be done with a name like d:foo. */
-#define IS_ABSOLUTE_PATH(f) (IS_DIR_SEPARATOR((f)[0]) || (((f)[0])
&& ((f)[1] == ':')))
+#define IS_ABSOLUTE_PATH(f) (IS_DIR_SEPARATOR((f)[0]) || HAVE_DRIVE_SPEC(f))
#else /* not DOSish */
#define IS_DIR_SEPARATOR(c) ((c) == '/')
#define IS_ABSOLUTE_PATH(f) (IS_DIR_SEPARATOR((f)[0]))
+#define HAVE_DRIVE_SPEC(f) (0)
+#define STRIP_DRIVE_SPEC(f) (f)
+
#endif /* not DOSish */
extern int filename_cmp (const char *s1, const char *s2);
next prev parent reply other threads:[~2010-04-12 17:31 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-06 21:58 Doug Evans
2010-04-06 23:17 ` Doug Evans
2010-04-07 20:14 ` Tom Tromey
2010-04-08 22:49 ` Doug Evans
2010-04-08 23:09 ` Sergio Durigan Junior
2010-04-09 0:13 ` Doug Evans
2010-04-09 17:15 ` Tom Tromey
2010-04-09 17:48 ` Eli Zaretskii
2010-04-10 1:29 ` Joel Brobecker
2010-04-09 7:49 ` Eli Zaretskii
2010-04-09 17:23 ` Doug Evans
2010-04-09 17:46 ` Eli Zaretskii
2010-04-09 18:12 ` Doug Evans
2010-04-09 19:31 ` Eli Zaretskii
2010-04-09 19:49 ` Doug Evans
2010-04-12 17:31 ` Doug Evans [this message]
2010-04-12 17:33 ` Doug Evans
2010-04-12 17:47 ` Tom Tromey
2010-04-12 17:54 ` Eli Zaretskii
2010-04-14 22:01 ` Doug Evans
2010-04-15 3:10 ` Eli Zaretskii
2010-04-09 17:13 ` Tom Tromey
2010-04-09 17:15 ` Doug Evans
2010-04-09 17:19 ` Tom Tromey
2010-04-17 15:20 ` H.J. Lu
2010-04-20 5:38 ` Doug Evans
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=o2he394668d1004121031gee9183c8g3aa53b249827c121@mail.gmail.com \
--to=dje@google.com \
--cc=eliz@gnu.org \
--cc=gdb-patches@sourceware.org \
--cc=tromey@redhat.com \
/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