Re: portability of 'printf' command

2010-04-12 Thread Karl Berry
rms said fine to adding printf to the list. It is committed now.

Re: gnulib bugs on OSX & C++

2010-04-12 Thread Bruno Haible
Hi Eric, > > + parametrization and the 'char' parametrization get compiled in the same > > s/parametrization/parameterization/g Both spellings appear to be valid: 1) Google for +parameterization -> 136 hits +parametrization -> 673000 hits 2)

Re: "const" scalars

2010-04-12 Thread Paul Eggert
Jim Meyering writes: > By "local variables" you must mean "local scalar variables". > You wouldn't argue for dropping "const" as a pointer attribute. Yes, that's right. That is, it's fine to have this: { char const *p = &a[i]; ... } because the 'const' is tal

[PATCH] maint.mk: generate more concise timing data for syntax-check rules

2010-04-12 Thread Jim Meyering
FYI, before sytnax-check timing data were more verbose: 4.06: sc_trailing_blank done now they look like this: 4.06 trailing_blank >From 24cd93edf4333d19223a9d02af5ad9d3394e6755 Mon Sep 17 00:00:00 2001 From: Jim Meyering Date: Mon, 12 Apr 2010 22:15:19 +0200 Subject: [PATCH] maint.mk:

Re: [PATCH] Don't error out if stdin/stdout/stderr was already closed.

2010-04-12 Thread Jim Meyering
James Youngman wrote: > On Sun, Apr 11, 2010 at 1:06 PM, Jim Meyering wrote: >> James Youngman wrote: >>> * lib/closeout.c (close_stdout): Don't signal an error closing >>> stdout or stderr if it was already closed. >>> * lib/closein.c (close_stdin): Don't signal an error closing stdin >>> if it w

Re: [PATCH] Really update the git index to avoid false -dirty versions

2010-04-12 Thread Jim Meyering
Andreas Gruenbacher wrote: > On Monday 12 April 2010 19:38:07 Jim Meyering wrote: >> Andreas Gruenbacher wrote: >> > On Monday 12 April 2010 18:25:01 Jim Meyering wrote: >> >> Can you describe a scenario in which >> >> using "git update-index --refresh" makes >> >> git-version-gen work better than

Re: Failing test case 67 Fatal errors but M4 continues producing output

2010-04-12 Thread Petr Machata
11.04.2010 20:40, Joel E. Denny wrote: > On Sun, 11 Apr 2010, Bruno Haible wrote: > >> The code in bison-2.4.2/src/output.c looks fine. > > Thanks for confirming. > >> Can you help reproducing or debugging it, with just 2 executables: bison >> and m4? (I.e. give a "how to reproduce" that does no

Re: Failing test case 67 Fatal errors but M4 continues producing output

2010-04-12 Thread Petr Machata
10.04.2010 21:49, Joel E. Denny wrote: > Before switching to create_pipe_bidi, I had observed a race condition. > That is, I could run a test for this problem on the same system many times > in a row, and it would fail only some of the time. This race condition > might still be there. Well, d

Re: [PATCH] Really update the git index to avoid false -dirty versions

2010-04-12 Thread Andreas Gruenbacher
On Monday 12 April 2010 19:38:07 Jim Meyering wrote: > Andreas Gruenbacher wrote: > > > On Monday 12 April 2010 18:25:01 Jim Meyering wrote: > >> Can you describe a scenario in which > >> using "git update-index --refresh" makes > >> git-version-gen work better than with "git status"? > >> In the

Re: [PATCH] Really update the git index to avoid false -dirty versions

2010-04-12 Thread Jim Meyering
Andreas Gruenbacher wrote: > On Monday 12 April 2010 18:25:01 Jim Meyering wrote: >> Can you describe a scenario in which >> using "git update-index --refresh" makes >> git-version-gen work better than with "git status"? >> In the example I tried (touch an unmodified, vc'd file), >> they appear to

Re: "const" scalars

2010-04-12 Thread Jim Meyering
Ben Pfaff wrote: > Jim Meyering writes: > >> Paul Eggert wrote: >>> I agree with Bruno on this point. It's hard enough to read C code >>> without having to wade through all those 'const's on local variables. >> >> By "local variables" you must mean "local scalar variables". >> You wouldn't argue

Re: [PATCH] maint.mk: print the elapsed time for each syntax-check rule

2010-04-12 Thread Eric Blake
On 04/11/2010 03:31 AM, Jim Meyering wrote: > This patch does something I've wanted for a while. > It prints the elapsed time for each individual syntax-check rule. > > I don't particularly like the fact that each new rule > - uses a temporary .sc-start-* file in which it saves each start time >

Re: gnulib bugs on OSX & C++

2010-04-12 Thread Eric Blake
On 04/10/2010 02:27 PM, Bruno Haible wrote: > +#if !USE_SNPRINTF || !HAVE_SNPRINTF_RETVAL_C99 > + > +/* Use a different function name, to make it possible that the 'wchar_t' > + parametrization and the 'char' parametrization get compiled in the same s/parametrization/parameterization/g -- Eric

Re: "const" scalars

2010-04-12 Thread Ben Pfaff
Jim Meyering writes: > Paul Eggert wrote: >> I agree with Bruno on this point. It's hard enough to read C code >> without having to wade through all those 'const's on local variables. > > By "local variables" you must mean "local scalar variables". > You wouldn't argue for dropping "const" as a

Re: [PATCH] Really update the git index to avoid false -dirty versions

2010-04-12 Thread Andreas Gruenbacher
On Monday 12 April 2010 18:25:01 Jim Meyering wrote: > Can you describe a scenario in which > using "git update-index --refresh" makes > git-version-gen work better than with "git status"? > In the example I tried (touch an unmodified, vc'd file), > they appear to have the same net effect. I can't

Re: [PATCH] Really update the git index to avoid false -dirty versions

2010-04-12 Thread Jim Meyering
Andreas Gruenbacher wrote: > * build-aux/git-version-gen: Use git update-index here; git status > will leave the index outdated. > --- > build-aux/git-version-gen |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/build-aux/git-version-gen b/build-aux/git-version-gen

[PATCH] Really update the git index to avoid false -dirty versions

2010-04-12 Thread Andreas Gruenbacher
* build-aux/git-version-gen: Use git update-index here; git status will leave the index outdated. --- build-aux/git-version-gen |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/build-aux/git-version-gen b/build-aux/git-version-gen index 16da2a8..e754c77 100755 --- a/buil

Re: const local variables

2010-04-12 Thread Ludovic Courtès
Hello, Paul Eggert writes: > All other things being equal, we should be encouraging a functional > style in which most local variables and parameters are never modified > once set. Agreed. How about adding something along these lines in the GCS? Thanks, Ludo’.

"const" scalars

2010-04-12 Thread Jim Meyering
Paul Eggert wrote: > I agree with Bruno on this point. It's hard enough to read C code > without having to wade through all those 'const's on local variables. Hi Paul, By "local variables" you must mean "local scalar variables". You wouldn't argue for dropping "const" as a pointer attribute. >