From: David Aguilar <davvid@gmail.com>
To: Jeff King <peff@peff.net>
Cc: git@vger.kernel.org, gitster@pobox.com, markus.heidelberg@web.de,
jnareb@gmail.com, j.sixt@viscovery.net
Subject: Re: [PATCH v5 2/3] path: add a find_basename() portability function
Date: Sat, 30 May 2009 15:14:14 -0700 [thread overview]
Message-ID: <20090530221413.GA10850@gmail.com> (raw)
In-Reply-To: <20090530140519.GA22905@sigill.intra.peff.net>
On Sat, May 30, 2009 at 10:05:19AM -0400, Jeff King wrote:
> On Fri, May 29, 2009 at 07:18:09PM -0700, David Aguilar wrote:
>
> > +/* return the basename of a path */
> > +const char *find_basename(const char *path)
> > +{
> > + const char *basename = path + strlen(path) - 1;
> > + while(*basename && basename > path) {
> > + basename--;
> > + if (is_dir_sep(*basename)) {
> > + basename++;
> > + break;
> > + }
> > + }
> > + return basename;
> > +}
>
> Hmm. Is there any point to the *basename condition in the loop? By using
> strlen, you are not going to go past any NULs, and you are already
> checking that you don't go past the beginning of the string.
>
> Speaking of which, how does this handle an input of ""? It seems that it
> would return a pointer to one character before the string. Given your
> loop, you need to special-case when *path is NUL.
>
> Also, how should trailing dir_seps be handled? basename() will actually
> return "" if given "foo/". Your implementation, when given "/foo/bar/"
> will return "bar/" (and it must keep the trailing bit since we are
> neither reallocating nor munging the input string). But given
> "/foo/bar//", it will return simply "/". I could see an argument for
> either "bar//" or "", but I think behaving differently for trailing "/"
> versus trailing "//" doesn't make sense.
>
> -Peff
You know.. going with the compat/basename.c solution is probably
a better idea now that you've pointed out all these issues.
Then we can just use the system's basename() when available and
use our compat/basename.c otherwise (is it only for Windows?).
Here's basename() from libiberty.
It drops constness (likely to keep in line with the standard)
and has some #defines that I'll have to translate into git
equivalents (e.g. IS_DIR_SEPARATOR -> is_dir_sep).
Do we have a cross-platform ISALPHA thing (just thinking out
loud -- I can check). I'm under the impression that going with
something like this should get us in a better place.
What do you think?
char *basename (const char *name)
{
const char *base;
#if defined (HAVE_DOS_BASED_FILE_SYSTEM)
/* Skip over the disk name in MSDOS pathnames. */
if (ISALPHA (name[0]) && name[1] == ':')
name += 2;
#endif
for (base = name; *name; name++) {
if (IS_DIR_SEPARATOR (*name)) {
base = name + 1;
}
}
return (char *) base;
}
--
David
prev parent reply other threads:[~2009-05-30 22:14 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-30 2:18 [PATCH v5 1/3] compat: add a mkstemps() compatibility function David Aguilar
2009-05-30 2:18 ` [PATCH v5 2/3] path: add a find_basename() portability function David Aguilar
2009-05-30 2:18 ` [PATCH v5 3/3] diff: generate pretty filenames in prep_temp_blob() David Aguilar
2009-05-30 14:05 ` [PATCH v5 2/3] path: add a find_basename() portability function Jeff King
2009-05-30 22:14 ` David Aguilar [this message]
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=20090530221413.GA10850@gmail.com \
--to=davvid@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=j.sixt@viscovery.net \
--cc=jnareb@gmail.com \
--cc=markus.heidelberg@web.de \
--cc=peff@peff.net \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.