Re: bugs in dirname module

[Jim Meyering]

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.