Eric Blake <[EMAIL PROTECTED]> writes:
>> Also, what's the point of DIRECTORY_SEPARATOR? Can't we just use '/'?
>
> I kept it with DIRECTORY_SEPARATOR, in case the application sets
> DIRECTORY_SEPARATOR to '\\' in config.h; after all, systems with drive
> letters have users that are used to the b
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Paul Eggert on 11/21/2005 5:42 PM:
Thanks for the review. Updated patch attached.
>
>>- /* If the file name ends in slash, use the trailing slash as
>>- the basename if no non-slashes have been found. */
>>+ /* If
Eric Blake <[EMAIL PROTECTED]> writes:
> - /* If the file name ends in slash, use the trailing slash as
> - the basename if no non-slashes have been found. */
> + /* If the file name ends in slash, but no non-slashes have
> + been found, then return the empty string.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Jim Meyering on 11/18/2005 6:28 AM:
>>so I am prepared to provide
>>this segregation into base_name() vs. last_component()
>>as part of my patch.
>
> I'd go along with that.
This is my patch to gnulib to change the semantics of base_name
[EMAIL PROTECTED] (Eric Blake) wrote:
...
> so I am prepared to provide
> this segregation into base_name() vs. last_component()
> as part of my patch.
I'd go along with that.
___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/
> > 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
Eric Blake <[EMAIL PROTECTED]> writes:
> OK, how about this approach: continue with the current rule that base_name
> always returns a pointer into the original string without modification.
> On systems where drive prefixes exist, have base_name("a:") return "" (it
> is a root), but base_name("foo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Paul Eggert on 11/10/2005 10:57 PM:
>
> We needn't conform strictly to the POSIX spec as far as slashes go;
> otherwise we'd be forced to treat "a/b" as not having a directory
> separator.
I think you meant 'a\b' in that comment. But I
Eric Blake <[EMAIL PROTECTED]> writes:
> On the other hand, on cygwin, "./a:b" is a valid name whose base_name is
> unambiguously "a:b" per POSIX,
We needn't conform strictly to the POSIX spec as far as slashes go;
otherwise we'd be forced to treat "a/b" as not having a directory
separator.
The
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Paul Eggert on 11/10/2005 6:44 PM:
>
> This makes it sound like we cannot implement base_name using the
> current approach. Currently, base_name always returns a suffix of the
> original file name. But under Cygwin if the file name is "
Eric Blake <[EMAIL PROTECTED]> writes:
> On cygwin, : can be a valid file character (cygwin has managed mounts,
> where cygwin transparently translates the names in use by the program into
> valid characters for the file system). There, drive letters are exactly
> [A-Za-z]:, and all other leading
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Paul Eggert on 11/9/2005 2:19 PM:
>
> However: what happens in DOS if you use a file name like "@:/a/b/c"?
In DOS, : is an invalid character, so the file name is outright rejected
when passed to a function that actually visits the disk.
Bruno Haible <[EMAIL PROTECTED]> writes:
>> An alternative to editing c-ctype is naming the dirname.h version
>> IS_DRIVE_LETTER instead of c_isalpha.
>
> Yes, this is much better. Also it reflects more closely what the macro is
> used for.
I also agree; sorry, I should have said it that way orig
Eric Blake wrote:
> > Why not use this instead?
> >
> > #define c_isalpha(c) (((unsigned int) (c) | ('a' - 'A')) - 'a' <= 'z' -
> > 'a')
>
> This is a slick definition, but it is different than what c-ctype.h
> provided, and that definition was not guarded. Bruno, would you accept
> the following
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Paul Eggert on 11/6/2005 3:59 AM:
>>My approach was to add a dependency on the c-ctype module to use c_isalpha
>
> That seems a bit overkill here, since you can assume ASCII and DOS.
> Why not use this instead?
>
> #define c_isalpha(c) (
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Paul Eggert on 11/7/2005 2:02 PM:
>>Should I add a dependency on the verify module to ensure that drive
>>letter prefixes are only used on ASCII platforms?
>
> I wouldn't bother, unless there's a serious possibility that we'll see
> drive
Eric Blake <[EMAIL PROTECTED]> writes:
> Should I add a dependency on the verify module to ensure that drive
> letter prefixes are only used on ASCII platforms?
I wouldn't bother, unless there's a serious possibility that we'll see
drive letter prefixes on an EBCDIC platform. I think that unlike
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Paul Eggert on 11/6/2005 3:59 AM:
>
>>My approach was to add a dependency on the c-ctype module to use c_isalpha
>
> That seems a bit overkill here, since you can assume ASCII and DOS.
> Why not use this instead?
>
> #define c_isalpha(c
Eric Blake <[EMAIL PROTECTED]> writes:
> My approach was to add a dependency on the c-ctype module to use c_isalpha
That seems a bit overkill here, since you can assume ASCII and DOS.
Why not use this instead?
#define c_isalpha(c) (((unsigned int) (c) | ('a' - 'A')) - 'a' <= 'z' - 'a')
Or perha
23 matches
Mail list logo
