Re: bug#8732: uinttostr: comparison of unsigned expression 0 is always false
Eric Blake wrote: [adding bug-gnulib] On 05/25/2011 03:29 PM, Eric Blake wrote: building coreutils-8.12 with '--enable-gcc-warnings' fails on my SLES 10.3 server: CC uinttostr.o cc1: warnings being treated as errors In file included from uinttostr.c:3: anytostr.c: In function 'uinttostr': anytostr.c:39: warning: comparison of unsigned expression 0 is always false the warning is spurious. But we don't know how to shut up gcc. You're not the first to hit this, either: http://lists.gnu.org/archive/html/bug-gnulib/2010-10/msg00435.html Since our party line back then was to upgrade gcc or quit using -Werror with old gcc, I'm marking this as a wontfix; but if you can come up with a patch, we can reopen it. Jim, Paul, This patch silences the gcc warning even for gcc too old to honor the pragma, but I can't help but feel that it might be too gross (it makes functions like uinttostr larger in size). What do you think? Hi Eric, Thanks for investigating, but SLES 10.3's gcc is too old for --enable-gcc-warnings. Coreutils' documentation (this originated as a report against coreutils) is clear that you should use the --enable-gcc-warnings option only with a very recent version of gcc: [from README-hacking] [*] The --enable-gcc-warnings option is useful only with glibc and with a very recent version of gcc. You'll probably also have to use recent system headers. If you configure with this option, and spot a problem, please be sure to send the report to the bug reporting address of this package, and not to that of gnulib, even if the problem seems to originate in a gnulib-provided file. The solution is not to enable those warnings on anything but new enough gcc+glibc. I've closed the coreutils ticket.
Re: [bug-patch] patch on x86-interix
On 05/26/11 10:51, Andreas Gruenbacher wrote: On Thursday 26 May 2011 10:43:41 Markus Duft wrote: [snip] Trying to find out ;) First of all, patch seems to miss strnlen.c in the tarball (2.6.1). it seems a well known problem, as even gentoo linux has a patch for this; see [1] and [2]. (from [2] there is a link to a ml-thread, where you already replied to the issue :)) Checking ... but could you please try the latest snapshot in ftp://alpha.gnu.org/gnu/patch/ instead? yep, that works for strnlen, and even fixes the quotearg problem! :) very interesting. so a gnulib issue remains (since i wasn't even able to build mbs stuff from gnulib), but patch should be fine with the next release. thanks! in the meantime, things can stay as they are, since my current patch does no real harm, and can be removed with the next release. i did run the testsuite too, which yielded the attached result(s). don't know whether this is due to it beeing a dev-snapshot, or something else though. i even did run the old testsuite (from 2.6.1), which yielded a very interesting result (all failed, see attached). however the 2.6.1 patch did work flawlessly since ever, with all the use cases i have for it ;p [1] http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/sys-devel/patch/patch-2.6.1.ebuild?revision=1.3view=markuppathrev=HEAD [2] http://bugs.gentoo.org/show_bug.cgi?id=300845 regards, markus Thanks, Andreas make-check.log.bz2 Description: application/bzip old-make-check.log.bz2 Description: application/bzip
Re: patch on x86-interix
Markus Duft wrote: and send us the log files of these three commands, plus config.log and gltests/config.log. all attached, except make check, as i could not run it, as make already failed :/ Thanks. The configure runs produce results similar to Interix 3.5., which is already covered in gnulib's documentation. The make log that you sent compiled only one file and did not fail. I guess that was a second make run after the first make run failed. Anyway, now you reported that newer releases from ftp://alpha.gnu.org/gnu/patch/ work fine. So the problem is solved; no need to follow up. Bruno -- In memoriam Jeane Gardiner http://en.wikipedia.org/wiki/Jeane_Gardiner
Re: [PATCH] getopt: for ambiguous options, enumerate the possibilities.
James, Thanks for the updates. From my point of view, this can go in now. Bruno -- In memoriam Jeane Gardiner http://en.wikipedia.org/wiki/Jeane_Gardiner
Re: [PATCH] getopt: for ambiguous options, enumerate the possibilities.
James Youngman wrote:
* lib/getopt.c (_getopt_internal_r): Merge glibc change printing
the ambiguous options when an ambiguous prefix is given. This was
http://sourceware.org/bugzilla/show_bug.cgi?id=7101. The merged
glibc change was
http://sourceware.org/git/?p=glibc.git;a=commit;h=bd25564e1e98910ed69043ed6a6f884ce60e5780.
...
diff --git a/lib/getopt.c b/lib/getopt.c
..
@@ -550,6 +592,13 @@ _getopt_internal_r (int argc, char **argv, const char
*optstring,
return '?';
}
+ while (ambig_list != NULL)
+{
+ struct option_list *pn = ambig_list-next;
+ free (ambig_list);
+ ambig_list = pn;
+}
+ --- trailing spaces
if (pfound != NULL)
{
option_index = indfound;
Hi James,
Thanks for doing that.
One nit that emacs highlights (while reading this via Gnus)
is that there is a line with trailing spaces above.
Other than that, it looks fine.
Re: patch on x86-interix
On 05/26/11 12:35, Bruno Haible wrote: Markus Duft wrote: and send us the log files of these three commands, plus config.log and gltests/config.log. all attached, except make check, as i could not run it, as make already failed :/ Thanks. The configure runs produce results similar to Interix 3.5., which is already covered in gnulib's documentation. The make log that you sent compiled only one file and did not fail. I guess that was a second make run after the first make run failed. hah, silly me; i | tee'd without redirecting stderr :) so it did actually fail on localcharset, but all the relevant output was missing from the log. the output was pasted to the mail itself though, so you had all information :) markus Anyway, now you reported that newer releases from ftp://alpha.gnu.org/gnu/patch/ work fine. So the problem is solved; no need to follow up. Bruno
Re: [bug-patch] patch on x86-interix
On Thursday 26 May 2011 10:43:41 Markus Duft wrote: On 05/25/11 22:43, Bruno Haible wrote: [CCing bug-gnulib] Markus Duft wrote in http://lists.gnu.org/archive/html/bug-patch/2011-05/msg00023.html: For quite a while now, i have patch working on x86-interix with a small patch ( :D ). I'd really love to see this patch ([1]) go upstream, if that's ok with you. Could you please take a look at it, and possibly comment on it? [1] http://overlays.gentoo.org/proj/alt/browser/trunk/prefix-overlay/sys -devel/patch/files/patch-2.6.1-interix-nomultibyte.patch This patch touches quotearg.c, which comes from gnulib. Your comment indicates bugs in the wide character support of that platform. Gnulib attempts to work around all such issues. Do you know what goes wrong? Do you have a small test program? Trying to find out ;) First of all, patch seems to miss strnlen.c in the tarball (2.6.1). Checking ... but could you please try the latest snapshot in ftp://alpha.gnu.org/gnu/patch/ instead? Thanks, Andreas
Re: [PATCH] getopt: for ambiguous options, enumerate the possibilities.
On 05/26/2011 05:03 AM, Jim Meyering wrote: Hi James, Thanks for doing that. One nit that emacs highlights (while reading this via Gnus) is that there is a line with trailing spaces above. Other than that, it looks fine. Pushed with that fixed. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
apology
I guess I should apologize for constantly harping about dependency creep in gnulib. No, gnulib is not the worst here. By far! I just did yum install perl-Net-SSH-Perl.noarch and it pulled 26 (that's right, twenty six!) packages for dependencies, including perl-Math-GMP and perl-Math-Pari. That's right, to interact with an ssh client, perl needs to do be able to do number theoretical computer algebra system. Can you believe it?! -- Sam Steingold (http://sds.podval.org/) on CentOS release 5.6 (Final) X 11.0.60900031 http://iris.org.il http://camera.org http://ffii.org http://honestreporting.com http://palestinefacts.org http://pmw.org.il Two wrongs don't make a right, but three rights make a left.
Re: need for computer algebra
Hi Sam, That's right, to interact with an ssh client, perl needs to do be able to do number theoretical computer algebra system. Can you believe it?! Yes, the dependency list [1] is impressing. I haven't looked why it needs Pari, but a good candidate is elliptic-curve cryptography. If a package needs that, why spend 25 man-days implementing elliptic curve arithmetic, when you can get it immediately, written by a world-class professor of cryptography, as part of Pari? Also, the 'factor' program in coreutils could become a lot faster if it were to use elliptic curves, like Paul Zimmermann's ECMNET program [2], rather than Pollard-ρ. Really, computer algebra is located near the bottom of the dependency graph of large software. Don't be surprised if you need it when inserting a bank card into an ATM. Bruno [1] http://rpm.pbone.net/index.php3/stat/4/idpl/15546485/dir/fedora_1/com/perl-Net-SSH-Perl-1.34-8.fc14.noarch.rpm.html#requires [2] http://www.loria.fr/~zimmerma/records/ecmnet.html -- In memoriam Jeane Gardiner http://en.wikipedia.org/wiki/Jeane_Gardiner
gen-uni-tables.c comments
I assume these stale comments are due to some old code? /Simon diff --git a/lib/gen-uni-tables.c b/lib/gen-uni-tables.c index e63a18d..0eddbb1 100644 --- a/lib/gen-uni-tables.c +++ b/lib/gen-uni-tables.c @@ -5672,7 +5672,7 @@ output_tables (const char *filename, const char *version) fprintf (stream, escape_char /\n); fprintf (stream, comment_char %%\n); fprintf (stream, \n); - fprintf (stream, %% Generated automatically by gen-unicode-ctype for Unicode %s.\n, + fprintf (stream, %% Generated automatically by gen-uni-tables.c for Unicode %s.\n, version); fprintf (stream, \n); @@ -7297,7 +7297,7 @@ output_lbrk_tables (const char *filename1, const char *filename2, const char *ve fprintf (stream, /* DO NOT EDIT! GENERATED AUTOMATICALLY! */\n); fprintf (stream, /* Line breaking properties of Unicode characters. */\n); - fprintf (stream, /* Generated automatically by gen-lbrk for Unicode %s. */\n, + fprintf (stream, /* Generated automatically by gen-uni-tables.c for Unicode %s. */\n, version); fprintf (stream, \n); @@ -7778,7 +7778,7 @@ output_wbrk_tables (const char *filename, const char *version) fprintf (stream, /* DO NOT EDIT! GENERATED AUTOMATICALLY! */\n); fprintf (stream, /* Line breaking properties of Unicode characters. */\n); - fprintf (stream, /* Generated automatically by gen-uni-tables for Unicode %s. */\n, + fprintf (stream, /* Generated automatically by gen-uni-tables.c for Unicode %s. */\n, version); fprintf (stream, \n); @@ -8528,7 +8528,7 @@ output_composition_tables (const char *filename, const char *version) fprintf (stream, /* DO NOT EDIT! GENERATED AUTOMATICALLY! */\n); fprintf (stream, /* Canonical composition of Unicode characters. */\n); - fprintf (stream, /* Generated automatically by gen-uni-tables for Unicode %s. */\n, + fprintf (stream, /* Generated automatically by gen-uni-tables.c for Unicode %s. */\n, version); fprintf (stream, \n); @@ -8661,7 +8661,7 @@ output_simple_mapping_test (const char *filename, fprintf (stream,You should have received a copy of the GNU General Public License\n); fprintf (stream,along with this program. If not, see http://www.gnu.org/licenses/. */\n); fprintf (stream, \n); - fprintf (stream, /* Generated automatically by gen-case.c for Unicode %s. */\n, + fprintf (stream, /* Generated automatically by gen-uni-tables.c for Unicode %s. */\n, version); fprintf (stream, \n); fprintf (stream, #include \test-mapping-part1.h\\n); @@ -8723,7 +8723,7 @@ output_simple_mapping (const char *filename, fprintf (stream, /* DO NOT EDIT! GENERATED AUTOMATICALLY! */\n); fprintf (stream, /* Simple character mapping of Unicode characters. */\n); - fprintf (stream, /* Generated automatically by gen-case.c for Unicode %s. */\n, + fprintf (stream, /* Generated automatically by gen-uni-tables.c for Unicode %s. */\n, version); t.p = 7;
Re: need for computer algebra
Hi Bruno, * Bruno Haible oe...@pyvfc.bet [2011-05-26 21:19:55 +0200]: That's right, to interact with an ssh client, perl needs to do be able to do number theoretical computer algebra system. Can you believe it?! a good candidate is elliptic-curve cryptography. yes, it turned out that the packages reimplements an ssh client rather than being an interface to an existing external one, in which case pari would obviously be not necessary. incidentally, I was not able to get it working on either Cygwin of CentOS, using either pre-supplied package managers or cpan. -- Sam Steingold (http://sds.podval.org/) on CentOS release 5.6 (Final) X 11.0.60900031 http://openvotingconsortium.org http://www.PetitionOnline.com/tap12009/ http://memri.org http://jihadwatch.org http://palestinefacts.org Professionalism is being dispassionate about your work.
Re: gen-uni-tables.c comments
Hi Simon, I assume these stale comments are due to some old code? Yes. Your fixes are good. Can you apply them, please? Bruno -- In memoriam Jeane Gardiner http://en.wikipedia.org/wiki/Jeane_Gardiner
Re: gen-uni-tables.c comments
Bruno Haible br...@clisp.org writes: Hi Simon, I assume these stale comments are due to some old code? Yes. Your fixes are good. Can you apply them, please? Done, thanks for review. /Simon
u32_normalize UNINORM_NFKC on 0xD800
I'm doing some Unicode NFKC operations and noticing that u32_normalize fails for U+D800. Is this behaviour permitted by TR15? I thought toNFKC should succeed for all code points. /Simon
Re: u32_normalize UNINORM_NFKC on 0xD800
Simon Josefsson wrote: I'm doing some Unicode NFKC operations and noticing that u32_normalize fails for U+D800. This is a valid behaviour, because U+D800 is a surrogate point code and therefore not a valid character code point. See the Unicode standard, chapter 2 [1], pages 23..24: Surrogate code points and other non-character code points should never be interchanged. This means, for libunistring, that they are invalid input and invalid output in all functions taking or returning UTF-32 strings or UTF-8 strings. Character code points and code points that are in regions that may be assigned in future Unicode versions must not be rejected; these are valid input. Bruno [1] http://www.unicode.org/versions/Unicode6.0.0/ch02.pdf -- In memoriam Jeane Gardiner http://en.wikipedia.org/wiki/Jeane_Gardiner
