RE: Minor problem with GNU-lib as used in coreutils-8.14

> -Original Message- > From: Paul Eggert [mailto:egg...@cs.ucla.edu] > Sent: Thursday, December 15, 2011 8:19 PM > To: Joachim Schmitz > Cc: 'Bruno Haible'; bug-gnulib@gnu.org > Subject: Re: Minor problem with GNU-lib as used in coreutils-8.14 > > Thanks. I think Bruno fixed that bug on N

Re: inttypes.h compile error

On 12/15/2011 10:07 PM, Alexander V. Lukyanov wrote: > This patch works if I use C++ compiler for AC_COMPILE tests. > Not if I use plain C. I don't observe that problem. Can you show how to reproduce it? >> -#define __STDC_LIMIT_MACROS 1 /* to make it work also in C++ before C++11 */ >> -#defin

Re: inttypes.h compile error

On Thu, Dec 15, 2011 at 11:50:23AM -0800, Paul Eggert wrote: > On 12/15/11 04:50, Alexander V. Lukyanov wrote: > > I get this message in a C++ program on linux (glibc-2.14). > > > > ../lib/inttypes.h:58:3: error: #error "This file assumes that 'int' has > > exactly 32 bits. Please report your pla

Re: inttypes.h compile error

On 12/15/11 04:50, Alexander V. Lukyanov wrote: > I get this message in a C++ program on linux (glibc-2.14). > > ../lib/inttypes.h:58:3: error: #error "This file assumes that 'int' has > exactly 32 bits. Please report your platform and compiler to > ." Thanks for reporting that. I installed th

Re: [PATCH] localcharset: Use an absolute path in TESTS_ENVIRONMENT

Hi Paul, > Somehow there was a mixup in the ChangeLog entry that got > committed: the è (e-with-grave-accent) got committed as a single > byte "\350" rather than the proper UTF-8 "\303\250". I just > now fixed that. Thanks! I had applied the patch using $ git am -3 < 0001-localcharset-Use-an-a

Re: Minor problem with GNU-lib as used in coreutils-8.14

Thanks. I think Bruno fixed that bug on November 4 in gnulib so we should be OK already; this fix should appear in the next coreutils release.

[PATCH] alloca: protect comment from gnulib-tool

I pushed this trivial workaround: alloca: protect comment from gnulib-tool * lib/alloca.c: Change "GCC version 2" to "GCC 2" in comment, so that gnulib-tool doesn't think it's a license, and munge it to say "GCC version 3". diff --git a/lib/alloca.c b/lib/alloca.c index c7e91ab..ee0f018 100644 ---

Re: [PATCH] localcharset: Use an absolute path in TESTS_ENVIRONMENT

On 12/15/11 02:50, Bruno Haible wrote: > Hello Ludo, > >> This patch allows running unit tests that are in a subdirectory from >> another directory. > > Thanks, makes sense. Applied (with a corrected ChangeLog entry). Somehow there was a mixup in the ChangeLog entry that got committed: the è (e-

Re: coreutils-8.14, "rm -r" fails with EBADF

On 12/15/11 08:28, Jim Meyering wrote: > If you can debug it further to narrow down what/how it is failing, > eventually we'll find the cause. One way to do that might be to put a breakpoint on all the following functions, and to let us know what their arguments are when called, and what they retu

Re: coreutils-8.14, "rm -r" fails with EBADF

Joachim Schmitz wrote: ... >> but what I really need to know is what happened just prior, in fts_read. >> Can you run gdb, set a breakpoint in fts_read and show us the result of >> stepping >> through fts_read? That would be most useful. > > Sorry, no gdb, the debugger here is calls eInspect (but

Re: uc_width and wcwidth optimization

On 12/13/2011 11:32 AM, Bruno Haible wrote: I'm attaching the benchmark program I'm experimenting with. So far, it seems that locale_charset() is really slow, whereas the is_cjk stuff is not a big speed problem. I would love to have locale_charset be either faster or use some thread-safe cache.

Re: inttypes.h compile error

On 12/15/2011 05:50 AM, Alexander V. Lukyanov wrote: > I get this message in a C++ program on linux (glibc-2.14). > > ../lib/inttypes.h:58:3: error: #error "This file assumes that 'int' has > exactly 32 bits. Please report your platform and compiler to > ." > > I think it's because of this in /

Re: [PATCH] localcharset: Use an absolute path in TESTS_ENVIRONMENT

Hi Bruno, Bruno Haible skribis: > Hello Ludo, > >> This patch allows running unit tests that are in a subdirectory from >> another directory. > > Thanks, makes sense. Applied (with a corrected ChangeLog entry). Thank you! Ludo’.

Re: coreutils-8.14, "rm -r" fails with EBADF

Joachim Schmitz wrote: > I got coreutils-8.9, 8.13 and 8.14 to compile for my platform, and most of the Thanks for the report. More details will help us help you: Which platform is that? Including your config.h might help. > utilities work, but as soon as it comes to recurring thru the file syst

coreutils-8.14, "rm -r" fails with EBADF

Hi folks I got coreutils-8.9, 8.13 and 8.14 to compile for my platform, and most of the utilities work, but as soon as it comes to recurring thru the file system some utils fail, e.g.: ~/coreutils-8.14/src $ ./rm -R /tmp/foo ./rm: traversal failed: `/tmp/foo': Bad file descriptor ~/coreut

Minor problem with GNU-lib as used in coreutils-8.14

Hi Bruno, list... closedir.c fails to compile in C99 mode due to a prototype for _gl_unregister_fd() not being in sight. My patch: /usr/local/bin/diff -EBbu ./lib/closedir.c.orig ./lib/closedir.c --- ./lib/closedir.c.orig 2011-09-19 10:09:24.0 -0500 +++ ./lib/closedir.c2011-12-1

inttypes.h compile error

I get this message in a C++ program on linux (glibc-2.14). ../lib/inttypes.h:58:3: error: #error "This file assumes that 'int' has exactly 32 bits. Please report your platform and compiler to ." I think it's because of this in /usr/include/stdint.h: /* The ISO C99 standard specifies that in C++

Re: uc_width and wcwidth optimization

Here is another patch which changes linear search to bsearch. With charset aliases of DARWIN7 case I get 10 times reduction of benchmark execution time. This patch should be thread-safe, in worst case it would leak some memory _once_ (just as before). -- Alexander. diff --git a/lib/localchar

Re: [PATCH] localcharset: Use an absolute path in TESTS_ENVIRONMENT

Hello Ludo, > This patch allows running unit tests that are in a subdirectory from > another directory. Thanks, makes sense. Applied (with a corrected ChangeLog entry). Bruno