Re: bugs in dirname module
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 patch to c-ctype, so that the order between "c-ctype.h" and
> my patched "dirname.h" won't matter?
> (c_isalpha) [C_CTYPE_ASCII]: Guard against redefinition.
No, I don't think that would be good: It's not dirname.h's job to define
macros for testing character properties. dirname.h should only export
things related to filenames and pathnames. Any other macro in it should
be made private, i.e. renamed to something like _DIRNAME_ISALPHA or so,
so that it is clear that it is not meant to be used for other purposes.
> 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.
Bruno
___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib
Re: xstrtoimax compilation warning on Solaris 7
Eric Blake writes: > > But C89 does not have long long - what does the standard say about > literals that exceed long? They have type unsigned long. (Similarly, C99 says that unsuffixed decimal literals that are too big to fit in long long have type unsigned long long.) -Larry Jones I don't want to be THIS good! -- Calvin ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
Re: namespace conflict for des
Simon Josefsson <[EMAIL PROTECTED]> writes: > The interface seem somewhat inefficient, because you can't do a > "setkey" operation and then use the scheduled key for several > operations. It has a strange license: > > * Sun RPC is a product of Sun Microsystems, Inc. and is provided for > * unrestricted use provided that I think that license is OK; it's compatible with the LGPL. > Unless someone feel strongly (and, preferably, even want to do the leg > work...) I'll simply fix the namespace of the current DES module. That sounds good. ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
Re: bugs in dirname module
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 originally. However: what happens in DOS if you use a file name like "@:/a/b/c"? Is this parsed as an invalid file letter, and then rejected, or as a file name that's much like "@_/a/b/c" but just happens to have an colon rather than an underscore? If the former, then surely dirname should not bother to check whether the first character is a letter. ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
Re: xstrtoimax compilation warning on Solaris 7
Eric Blake <[EMAIL PROTECTED]> writes: > But C89 does not have long long - what does the standard say about > literals that exceed long? They're of type unsigned long if they fit, and they're an error otherwise. GCC has long long as an extension, so it handles them as long long if they fit, unsigned long long otherwise -- or an error if they're too big even for unsigned long long. So Solaris works as intended, albeit with some chatter. ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
readline fix
Is this right? I'm not sure what a portable way to remove EOL is. Anyway, I installed this because it work on known platforms. 2005-11-10 Simon Josefsson <[EMAIL PROTECTED]> * readline.c: Remove EOL. --- readline.c 20 Sep 2005 11:12:16 +0200 1.2 +++ readline.c 10 Nov 2005 03:16:03 +0100 @@ -33,6 +33,7 @@ #include "readline.h" #include +#include #include char * @@ -47,5 +48,10 @@ if (getline (&out, &size, stdin) < 0) return NULL; + if (out[strlen (out) - 1] == '\r') +out[strlen (out) - 1] = '\0'; + if (out[strlen (out) - 1] == '\n') +out[strlen (out) - 1] = '\0'; + return out; } ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
Re: bugs in dirname module
-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. But POSIX requires that basename(1) and dirname(1) operate even in the presence of invalid file names, without checking for existance or legality. 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 characters (besides slashes, of course), are treated as a relative pathname from ./ rather than a drive designator. > Is this parsed as an invalid file letter, and then rejected, or as a > file name that's much like "@_/a/b/c" but just happens to have an > colon rather than an underscore? If the former, then surely dirname > should not bother to check whether the first character is a letter. Dirname really does need to check the first character for correctness on cygwin. - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDcsoS84KuGfSFAYARAstiAKCYECXbkcK9zww6hwQYQLDAoEPK5ACgrNV5 /92BFZApq/6gyrmUapWTQV8= =NxxZ -END PGP SIGNATURE- ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
Re: readline fix
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Simon Josefsson on 11/9/2005 7:17 PM: > Is this right? I'm not sure what a portable way to remove EOL is. > Anyway, I installed this because it work on known platforms. The concept is correct (the full-blown readline library does indeed strip the trailing newline), but whether you should also strip \r is a different matter. > > > + if (out[strlen (out) - 1] == '\r') > +out[strlen (out) - 1] = '\0'; > + if (out[strlen (out) - 1] == '\n') > +out[strlen (out) - 1] = '\0'; This is backwards: Windows text files have \r\n, so you should strip \n before \r if you are working from the end (and if others agree that stripping \r is the right thing to do). Also, it ignores the fact that getline() can return embedded NULs, so that a) strlen() may be inaccurate, and b) it is a waste of computation since the return value of getline() is already the full length rather than walking the string multiple times. - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDctTC84KuGfSFAYARAoDAAJ9ZGEiQrUJCICFIXbG3fX31Kwh5KACgupxq /JDFkoRVihv/v69Kb0gMR2A= =6qMR -END PGP SIGNATURE- ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
