Paul Eggert <[EMAIL PROTECTED]> 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.
_______________________________________________
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib
