[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: bugs in dirname module
From: |
Jim Meyering |
Subject: |
Re: bugs in dirname module |
Date: |
Thu, 17 Nov 2005 23:57:03 +0100 |
Paul Eggert <address@hidden> wrote:
> If we go this route, then base_name(F) cannot in general yield a
> suffix of F even on Unix systems, since we would want dir_name("a/b/")
> == "a/b" and base_name("a/b/") == ".". Hence base_name will need to
> allocate memory in general, even on Unix. On Cygwin it will need it
> to compute "./a:b".
That's a big departure from established tradition.
Do you really want to call the result base_name?
The first few uses of base_name in the coreutils that I looked at
do not seem amenable to the proposed change in semantics. E.g.,
/* Return true if the last component of NAME is `.' or `..'
This is so we don't try to recurse on `././././. ...' */
static bool
basename_is_dot_or_dotdot (const char *name)
{
char const *base = base_name (name);
return DOT_OR_DOTDOT (base);
}
> Also, src/dirname.c and src/basename.c will have to be modified to
> strip redundant trailing slashes before invoking dir_name and
> base_name.
Examples like the above (from remove.c) would also require removing
trailing slashes. So we'd have to make a writable copy and remove
trailing slashes in order to be able to use the new base_name function,
which would return a malloc'd result. And we'd have to free it, too,
of course.
That doesn't sound like an improvement.
- Re: bugs in dirname module, (continued)
- Re: bugs in dirname module, Bruno Haible, 2005/11/09
- Re: bugs in dirname module, Paul Eggert, 2005/11/09
- Re: bugs in dirname module, Eric Blake, 2005/11/09
- Re: bugs in dirname module, Paul Eggert, 2005/11/10
- Re: bugs in dirname module, Eric Blake, 2005/11/10
- Re: bugs in dirname module, Paul Eggert, 2005/11/11
- Re: bugs in dirname module, Eric Blake, 2005/11/11
- Re: bugs in dirname module, Paul Eggert, 2005/11/16
- Re: bugs in dirname module, Eric Blake, 2005/11/17
- Re: bugs in dirname module, Paul Eggert, 2005/11/17
- Re: bugs in dirname module,
Jim Meyering <=
Re: bugs in dirname module, Eric Blake, 2005/11/17
Re: bugs in dirname module, Eric Blake, 2005/11/17