Paul Eggert egg...@cs.ucla.edu 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
[ 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.)
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
[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 reason
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
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
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
Paul Eggert egg...@cs.ucla.edu 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
On 08/05/2010 01:44 AM, Simon Josefsson wrote:
Paul Eggertegg...@cs.ucla.edu 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
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
10 matches
Mail list logo
