Eric Blake <[EMAIL PROTECTED]> writes:
> Is there a preference for 'const char *' over 'char const *'?
I prefer putting type qualifiers like "const" after the types they
modify, as that's more consistent. For example, "char * const *" puts
the "const" after the "char *", where it belongs. Simil
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Is there a preference for 'const char *' over 'char const *'? A quick
grep of my locally-modified gnulib repository shows 208 "char const *" vs.
793 "const char *" in the .c and .h files. The GNU Coding Standards offer
no help - http://www.gnu.org/pr
> > Actually, I think that calling base_name should strip the trailing
> > slashes, similar to POSIX basename().
>
> But if you do that, you violate this basic rule:
>
> > If you have a valid file name F, then accessing F is the same as
> > chdir(dir_name(F)) followed by accessing base_name(F
> 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 U
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 C
Eric Blake <[EMAIL PROTECTED]> writes:
> Actually, I think that calling base_name should strip the trailing
> slashes, similar to POSIX basename().
But if you do that, you violate this basic rule:
> If you have a valid file name F, then accessing F is the same as
> chdir(dir_name(F)) followe
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Paul Eggert on 11/16/2005 1:50 PM:
>
> I'm trying to map this to the bigger picture, and coming up empty.
> Among other things, I don't like having "" be a special case.
My only question on this front is whether base_name("") would then
