Re: "inline" overused in .c files?

2010-07-26 Thread Chen Guo
On Mon, Jul 26, 2010 at 11:53 AM, Paul Eggert wrote: > I noticed thirteen "inline"s in coreutils/src/sort.c.  Just for fun, I > removed them all.  In ten cases, removing "inline" made no difference to > the generated machine code on my platform (RHEL 5, x86-64, GCC 4.1.2, > compiled with the typic

Re: bug#6734: "inline" overused in .c files?

2010-07-26 Thread Paul Eggert
After Bruno's comments it seems that some typical compilers can benefit from "inline" on some functions, particularly small and commonly used functions, so I removed just the "inline"s that didn't appear like they would help measurably on any typical platform. >From 66e934b61f05ef32583df2a33f371c7

Re: stat-time -> LGPLv3+

2010-07-26 Thread Bruno Haible
[Adding James to the CC] > > We’d like to use ‘stat-time’ in libguile, but libguile is LGPLv3+. > > Could you make the license change? > > Or LGPL v2.1+ too. > > Anyway, CCed the other contributors (Bruno and Eric). According to 'gitk lib/stat-time.h', Paul, James, Eric, Jim, and I are contribu

Re: "inline" overused in .c files?

2010-07-26 Thread Bruno Haible
Hi Paul, In some cases, I experienced that a program can be made 5% faster just by marking selected functions as 'inline'. Good candidates are those which are only used at one place, and those which are small and where the function call overhead would be noticeable. In gnulib, we use 'inline' wit

Re: "inline" overused in .c files?

2010-07-26 Thread Pádraig Brady
On 26/07/10 19:53, Paul Eggert wrote: > I noticed thirteen "inline"s in coreutils/src/sort.c. Just for fun, I > removed them all. In ten cases, removing "inline" made no difference to > the generated machine code on my platform (RHEL 5, x86-64, GCC 4.1.2, > compiled with the typical gcc -O2). In

Re: "inline" overused in .c files?

2010-07-26 Thread Paolo Bonzini
On 07/26/2010 08:53 PM, Paul Eggert wrote: I noticed thirteen "inline"s in coreutils/src/sort.c. Just for fun, I removed them all. In ten cases, removing "inline" made no difference to the generated machine code on my platform (RHEL 5, x86-64, GCC 4.1.2, compiled with the typical gcc -O2). In

"inline" overused in .c files?

2010-07-26 Thread Paul Eggert
I noticed thirteen "inline"s in coreutils/src/sort.c. Just for fun, I removed them all. In ten cases, removing "inline" made no difference to the generated machine code on my platform (RHEL 5, x86-64, GCC 4.1.2, compiled with the typical gcc -O2). In the three sort.c functions that were exceptio

[PATCH] timespec: use cast and not conditional, as truncation isn't possible

2010-07-26 Thread Paul Eggert
* lib/timespec.h (timespec_cmp): Use cast to pacify gcc -Wconversion instead of a conditional. Comment about the situation in more detail. This undoes most of the 2009-10-29 patch. --- ChangeLog |7 +++ lib/timespec.h | 32 2 files changed, 35 inser

Re: stat-time -> LGPLv3+

2010-07-26 Thread Eric Blake
On 07/26/2010 05:35 AM, Paolo Bonzini wrote: > On 07/26/2010 12:37 PM, Ludovic Courtès wrote: >> Hello! >> >> We’d like to use ‘stat-time’ in libguile, but libguile is LGPLv3+. >> Could you make the license change? > > Or LGPL v2.1+ too. Now that POSIX 2008 requires nanosecond resolution in stat(

Re: stat-time -> LGPLv3+

2010-07-26 Thread Paul Eggert
On 07/26/10 10:19, Eric Blake wrote: > Not sure why your parenthetical list is shorter than your CC list, but > 'git log lib/stat-time.h | grep Author' confirms that we also need Jim > and Paul's consent. Switching it to LGPLv3+ is fine with me.

Re: stat-time -> LGPLv3+

2010-07-26 Thread Paolo Bonzini
On 07/26/2010 12:37 PM, Ludovic Courtès wrote: Hello! We’d like to use ‘stat-time’ in libguile, but libguile is LGPLv3+. Could you make the license change? Or LGPL v2.1+ too. Anyway, CCed the other contributors (Bruno and Eric). Paolo

stat-time -> LGPLv3+

2010-07-26 Thread Ludovic Courtès
Hello! We’d like to use ‘stat-time’ in libguile, but libguile is LGPLv3+. Could you make the license change? Thanks, Ludo’. pgpKD10rjyIsW.pgp Description: PGP signature