Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Joel Brobecker <brobecker@ACT-Europe.FR>
To: Eli Zaretskii <eliz@is.elta.co.il>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [RFC] xfullpath and new regression test xfullpath.exp
Date: Tue, 02 Apr 2002 07:22:00 -0000	[thread overview]
Message-ID: <20020402172232.C25687@act-europe.fr> (raw)
In-Reply-To: <Pine.SUN.3.91.1020401122551.22923D-100000@is>; from eliz@is.elta.co.il on Mon, Apr 01, 2002 at 12:42:13PM +0200

> Thanks.  However, this patch will not DTRT on DOS and Windows systems, 
> I'm afraid.  Details below.

I'm quite ignorant of the DOS and Windows platforms, so I'm not too
surprised, somehow. I thought that since only cygwin-gdb was supported,
I did not have to deal with DOS-like formats. Thanks for correcting me.

> This kind of detailed description should go into the source, IMHO.  It's 
> okay to have it in the ChangeLog as well, but having it _only_ in the 
> ChangeLog is not a good idea: people who read the code don't expect to 
> find the associated comments in the logs.

Right, I will put this in the code as well.

> 
> + /*
> +  * xfullpath
> +  *
> +  * Return a copy of FILENAME, with its directory prefix canonicalized
> +  * by gdb_realpath.
> +  */
> 
> I believe this is not the comment style the GNU project uses.

Is the following style more in line with the GNU project style?

  /* Return a copy of FILENAME, with its directory prefix canonicalized
     by gdb_realpath.  */

> This doesn't work correctly when the input name is something like 
> "d:foo".  lbasename returns a pointer to `f', so you end up with the 
> directory being "d:", and the rest of the code will generate "d:/foo", 
> which is something very different in semantics.  The Right Thing to do
> in this case is to return either the unmodified "d:foo" or "d:./foo".

Ah, Ok, I did not know this, I thought that d:foo and d:/foo were
equivalent. Shouldn't xfullpath return d:<cwd>/foo instead? What do you
think of the following pseudo-code?

   [...]
   dir_name = alloca ((size_t) (base_name - filename + 2));
   /* Allocate enough space to store the dir_name + plus one extra
      character sometimes needed under Windows (see below), and
      then the closing \000 character */
   strncpy (dir_name, filename, base_name - filename);
   dir_name[base_name - filename] = '\000';

   #if defined(__CYGWIN__) || defined(__MINGW32__)
   if (strlen (dir_name) == 2 &&
       is_letter (dir_name[0]) && dir_name[1] == ':')
     {
       dir_name[2] = '.';
       dir_name[3] = '\000';
     }
   #endif

   real_path = gdb_realpath (dir_name);
   [...]

> This doesn't work if the input is "\\", which is also a root directory.
> You should use the more portable IS_DIR_SEPARATOR macro (defined on 
> include/filenames.h) instead.

Cool macro.

> Finally, I don't understand why do you avoid duplicate slashes when
> dir_name is "/", but not if it is "/foo/bar/".  Why not handle the 
> other case as well?  (This issue is a general one, not something specific 
> to MS-Windows, although the case of "d:/", the root directory on drive d:, 
> was what initially brought that to my attention.)

Since I thought that only cygwin-style filenames were supported, I
thought that the the double-slash issue would only happen with the root
directory.

Is this better if I modify the last part of the function to be
(can I consider that SLASH_STRING will always be one character long?):

   if (IS_DIR_SEPARATOR (real_path[strlen (real_path) - 1]))
     result = concat (real_path, base_name, NULL);
   else
     result = concat (real_path, SLASH_STRING, base_name, NULL);

Thanks,
-- 
Joel


  reply	other threads:[~2002-04-02 15:22 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-04-01  0:50 Joel Brobecker
2002-04-01  1:43 ` Eli Zaretskii
2002-04-02  7:22   ` Joel Brobecker [this message]
2002-04-03  5:12     ` Eli Zaretskii
2002-04-03  5:19       ` Joel Brobecker
2002-04-04 23:44         ` Eli Zaretskii
2002-04-03 20:43 ` Andrew Cagney

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=20020402172232.C25687@act-europe.fr \
    --to=brobecker@act-europe.fr \
    --cc=eliz@is.elta.co.il \
    --cc=gdb-patches@sources.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