Re: characters allowed in --enable-*/--with-*

Hello Bruno, * Bruno Haible wrote on Wed, Aug 04, 2010 at 11:24:19PM CEST: > If I can't convince you, then I would propose to be silent about this > question in the GNU standards for the moment, This is not an option IMVHO, because it has the very distinct disadvantage that you cannot build packa

Re: propose renaming gnulib memxfrm to amemxfrm (naming collision with coreutils)

On 08/05/2010 01:44 AM, Simon Josefsson wrote: Paul Eggert writes: Come to think of it, looking at gnulib memxfrm gave me an idea to improve the performance of GNU sort by bypassing the need for an memxfrm-like function entirely. I pushed a patch to do that at

Re: propose renaming gnulib memxfrm to amemxfrm (naming collision with coreutils)

Paul Eggert writes: > Come to think of it, looking at gnulib memxfrm gave me an idea > to improve the performance of GNU sort by bypassing the need for an > memxfrm-like function entirely. I pushed a patch to do that at >

Re: propose renaming gnulib memxfrm to amemxfrm (naming collision with coreutils)

On 08/03/10 16:33, Bruno Haible wrote: > But when the stack buffer is not sufficient, then the use of coreutils memxfrm > is 30% to 70% slower than the use of gnulib memxfrm, with a difference of > 700 μsec at least. (Ooo! Ooo! Performance measurements! I love this stuff!) It depends on the da

Re: characters allowed in --enable-*/--with-*

I was merely musing on my experiences in that initial reply, not making final proclamations or anything. Sorry if I gave that impression. I realize there are advantages to allowing +, which you have ably enumerated :). I'm ok with proposing to rms that + be allowed, along with: -_.A-Za-z I wasn

Re: gettext in bootstrap-tools

Hi Bruno, Paul, On Sat, 31 Jul 2010, Bruno Haible wrote: > Regarding gettext, there is usually no functional difference between .mo > files generated by msgfmt 0.11 and those generated by msgfmt 0.18.1.1. > So it's probably not worth mentioning. For users who are trying to debug a bison build pr

Re: AC_FUNC_ALLOCA shouldn't define prototype

[adding bug-gnulib, as another interested party in alloca replacements] On 08/04/2010 03:59 PM, Thomas Klausner wrote: > Hi! > > Joerg Sonnenberger recently committed the attached patch to pkgsrc > (for autoconf-2.66) prohibiting AC_FUNC_ALLOCA from defining a > prototype on the BSDs. > > The re

Re: characters allowed in --enable-*/--with-*

Hello Karl, > > Autoconf 2.66 added '+' to the set of allowed characters in --enable-* > > Why? There were three reasons behind my proposal on bug-autoconf on 2010-03-13: 1) For --enable/--disable: So that programs can use --enable-c++, which is easier for the user to remember than ei

Re: characters allowed in --enable-*/--with-*

[ adding bug-gnulib ] * Karl Berry wrote on Tue, Aug 03, 2010 at 01:11:47AM CEST: > So gnulib could have --enable-c++. > > I guess I missed some discussion on bug-gnulib. Overall, "cplusplus" > seems like it would have been simpler/more customary. (That ++ causes > endless hassle everywhere

Re: [PATCH] read-file: Avoid memory reallocations with seekable files.

Paul Eggert writes: > It would be clearer without the casts. (Casts are often > overkill in C; they disable too much checking.) Also, I'm still > dubious about going ahead with a file that's too > large to fit into memory. Here is another version, it fails with ENOMEM on files that don't fit i