Hi,
To conform with the majority gnulib style, I'm performing this stylistic
change on my code.
2007-01-29 Bruno Haible <[EMAIL PROTECTED]>
* lib/allocsa.h: Use '#if HAVE_*' instead of '#ifdef HAVE_*'.
* lib/execute.c: Likewise.
* lib/pipe.c: Likewise.
* lib/pri
Thanks. I installed these further patches to try to keep this module
in sync with POSIX and glibc as much as possible. I haven't tested
this on a Windows platform, though; please let me know if there are
any problems.
2007-01-29 Paul Eggert <[EMAIL PROTECTED]>
* lib/strptime.h (strpti
Eric Blake wrote:
> OK to apply this?
>
> 2007-01-29 Eric Blake <[EMAIL PROTECTED]>
>
> * lib/memrchr.c: Assume unconditionally, to pull in
> size_t as needed.
Yes, this is OK. Usually when one needs size_t, including
is the preferred choice, because it defines a minimum of decla
Jim Meyering <[EMAIL PROTECTED]> writes:
>> I was surprised to see Jim's report that the C locale made no
>> difference to him, compared to the en_US.UTF-8 locale.
>
> I hope I didn't say that.
> The only locale I tried was "C".
Ah, sorry, I misremembered what you said. I just now measured with
memrchr.c used size_t without pulling in the right headers:
gcc -std=gnu99 -I. -I/usr/local/include -g2 -Wall -Werror -MT memrchr.o -
MD -MP -MF .deps/memrchr.Tpo -c -o memrchr.o memrchr.c
memrchr.c:45: error: parse error before "size_t"
memrchr.c: In function `memrchr':
memrchr.c:53: error:
* Bruno Haible wrote on Sun, Jan 28, 2007 at 05:00:08PM CET:
> Ralf Wildenhues wrote:
>
> > > Adding newlines and backslashes to an AC_SUBSTed value limits its use: It
> > > can only be used in particular places of Makefiles.
> >
> > Which other places do you need gl_LIBOBJ at? Sorry, I fail to
Le lundi 29 janvier 2007 à 18:44 +0100, Jim Meyering a écrit :
> Yoann Vandoorselaere <[EMAIL PROTECTED]> wrote:
> > Here is a GnuLib module providing the strptime function, merged from the
> > glibc implementation. From my minor testing, the module seem to work.
>
> Thanks for contributing that.
Paul Eggert <[EMAIL PROTECTED]> wrote:
> Bruno Haible <[EMAIL PROTECTED]> writes:
>
>> Does the major speedup come from the transition a) -> b), or from the
>> transition b) -> c) ?
>
> I didn't code those solutions separately, so I don't know.
>
> I have written a replacement qsort that has the s
Bruno Haible <[EMAIL PROTECTED]> writes:
> Does the major speedup come from the transition a) -> b), or from the
> transition b) -> c) ?
I didn't code those solutions separately, so I don't know.
I have written a replacement qsort that has the same API as standard
qsort, but uses mpsort internal
Yoann Vandoorselaere <[EMAIL PROTECTED]> wrote:
> Here is a GnuLib module providing the strptime function, merged from the
> glibc implementation. From my minor testing, the module seem to work.
Thanks for contributing that.
On what systems it necessary?
Yoann Vandoorselaere wrote:
> Here is a GnuLib module providing the strptime function, merged from the
> glibc implementation. From my minor testing, the module seem to work.
Thanks. I added this to gnulib and made the following minor changes.
2007-01-29 Bruno Haible <[EMAIL PROTECTED]>
Hi,
Here is a GnuLib module providing the strptime function, merged from the
glibc implementation. From my minor testing, the module seem to work.
Regards,
--
Yoann Vandoorselaere <[EMAIL PROTECTED]>
Index: lib/strptime.c
===
RCS
Jim Meyering wrote:
> When sorting records larger than a pointer, reduced data movement is
> likely to be the overriding factor: better use of cache.
> I.e., setting up the array of pointers costs just O(N) time and memory,
> but you save O(N log(N)) time in reduced data copying costs, because
> mp
Bruno Haible <[EMAIL PROTECTED]> wrote:
> Hello Paul,
>
>> Such a function can lead to faster execution
>> in some important cases, as I have verified using GNU 'ls' as a guinea pig.
>
> Does the speedup come from the use of the mergesort algorithm, or from
> avoiding a function call in the compari
Hello Paul,
> Such a function can lead to faster execution
> in some important cases, as I have verified using GNU 'ls' as a guinea pig.
Does the speedup come from the use of the mergesort algorithm, or from
avoiding a function call in the comparison function (with qsort, the
pointer indirection
15 matches
Mail list logo
