Re: test results on MacOS X 10.5

Bruno Haible wrote: ... > #include > #include > #include > int main () > { > static struct tm tm; > time_t t; > > tm.tm_sec = 0; > tm.tm_min = 0; > tm.tm_hour = 0; > tm.tm_mday = 1; > tm.tm_mon = 0; > tm.tm_year = -1900; > tm.tm_isdst = -1; > t = mktime (&tm); > printf ("%l

Re: gnulib bugs on OSX & C++

Bruno Haible wrote: >> The only formatting problem I saw was the one fixed here. >> Did you mean something else? > > I also meant to move the REPLACE_FCHOWNAT=1 statement to the next line. > It is too easily overlooked when it is tucked so far to the right. I pushed this: >From d6116655f30bb175a5

Re: const local variables

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. The tiny extra benefit that they provide is not worth the overhead on people trying to read the code. What's next? Should we also add 'const' to parameter decla

Re: strnlen on OSX & C++

> The problem here is that gnulib's handling of strnlen is using an ancient > idiom. The same ancient idiom is also in a few other places: m4/calloc.m4: AC_DEFINE([calloc], [rpl_calloc], m4/getopt.m4: AC_DEFINE([__GETOPT_PREFIX], [[rpl_]], m4/timegm.m4: AC_DEFINE([mktime], [rpl_mkti

Re: test results on MacOS X 10.5

Hi Jim, Jim Meyering wrote: > > 0101.00 mismatch (-: actual; +:expected) > > --62167132800 > > +-62167219200 > > FAIL: test-posixtm > > > > Jim, what does this mean? > > I suspect that is due to a bug in their mktime function. > I presume that test is using the system version of mktime, >

Re: gnulib bugs on OSX & C++

Jim, > The only formatting problem I saw was the one fixed here. > Did you mean something else? I also meant to move the REPLACE_FCHOWNAT=1 statement to the next line. It is too easily overlooked when it is tucked so far to the right. Bruno

Re: gnulib bugs on OSX & C++

Bruno Haible wrote: >> > >> > Is it ok to apply it? >> >> Yes, please. >> I'll correct the formatting afterward. > > I've applied and pushed this now. Thanks. The only formatting problem I saw was the one fixed here. Did you mean

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

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 not involve bison's > testsuite? I'm not inclined to l

Re: [PATCH 00/15] Add libunistring-optional module

On 04/11/2010 06:43 PM, Bruno Haible wrote: > Then you don't even use libunistring-optional. libunistring-optional is > what adds gl_LIBUNISTRING for you, basically. Oh, I see. I was confused because I thought that modules/libunistring-optional and m4/libunistring-optional.m4 belong together,

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

Hi Joel, > In the create_pipe_bidi invocation above, I set the slave_process argument > to true. create_pipe_bidi passes that argument to create_pipe, which then > invokes register_slave_subprocess, which uses atexit to register a > function that invokes kill. > > Moreover the documentation i

warn-on-use: stricter checking in testdirs

warn-on-use.h contains some code which provides warnings if GCC 4.3 or higher is in use. And it fails if the function is not declared. But most of my testing (Cygwin 1.5, mingw, MacOS X) is currently done with GCC versions older than that, therefore I may miss these errors that would occur with oth

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

Hi Bruno, On Sun, 11 Apr 2010, Bruno Haible wrote: > > pid = create_pipe_bidi ("m4", m4, (char **)(void*)argv, false, true, > > true, filter_fd); > > I thought that create_pipe_bidi is supposed to make sure > > that the m4 subprocess is killed when Bison invokes exi

Re: const local variables

James Youngman wrote: > On Sun, Apr 11, 2010 at 1:08 PM, Bruno Haible wrote: >> James Youngman wrote: >>> * lib/close-stream.c (close_stream): Make boolean variables const >>> to document the fact that we set but do not change them. >>> --- a/lib/close-stream.c >>> +++ b/lib/close-stream.c >>> @@

Re: [PATCH 00/15] Add libunistring-optional module

Hi Paolo, > > In cases where only very little from libunistring is used, like the > > 'unicodeio' module which only depends on 'unistr/u8-uctomb', it would be > > overkill to link with -lunistring just for this. > > Then you don't even use libunistring-optional. libunistring-optional is > what

Re: [PATCH 03/15] libunistring: improve diagnostics

Paolo Bonzini wrote: > * m4/libunistring.m4: Do not repeat twice "no, consider installing GNU > libunistring". Also add a missing-message parameter like the one > of AM_LIB_HAVE_LINKFLAGS. I'm applying the first part of your patch, like below. With it, the output is changed from checking for l

Re: [PATCH 03/15] libunistring: improve diagnostics

Paolo Bonzini wrote: > * m4/libunistring.m4: Do not repeat twice "no, consider installing GNU > libunistring". While testing the case that this code is meant for, I noticed that it did not work at all. How to reproduce: 0) Create an empty directory, used as --prefix for everything that follows. 1

Re: [PATCH 00/15] Add libunistring-optional module

On 04/11/2010 04:58 PM, Bruno Haible wrote: Hi Paolo, ... requires nearly no additional change for the user: He adds 'gl_LIBUNISTRING' to his configure.ac and is done with it. Not even that if the modules do that for him. In cases where only very little from libunistring is used, like the '

Re: [PATCH 00/15] Add libunistring-optional module

Hi Paolo, > > ... requires nearly no additional change for the > > user: He adds 'gl_LIBUNISTRING' to his configure.ac and is done with it. > > Not even that if the modules do that for him. In cases where only very little from libunistring is used, like the 'unicodeio' module which only depends

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

Jim Meyering wrote: > James Youngman wrote: ... >> * lib/close-stream.c (close_stream): Make boolean variables const >> to document the fact that we set but do not change them. ... > However, the const-adding part of your patch would be find all by itself. I've pushed this in your name: >From 1e4

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

Hi Joel, Joel E. Denny wrote: > > input.y: fatal error: too many arguments for @output directive in skeleton > > +/usr/bin/m4:./skel.c:175: ERROR: copying inserted file: Broken pipe > > +/usr/bin/m4: write error > > Thanks for the report. One of the goals of Bison 2.4.2 was to avoid m4's > rep

Re: [PATCH 00/15] Add libunistring-optional module

Thanks for doing that! It is simpler than the solution that I had imagined for the use in gettext, and requires nearly no additional change for the user: He adds 'gl_LIBUNISTRING' to his configure.ac and is done with it. Not even that if the modules do that for him. However, I disagree with

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

I'm adding bug-gnulib in case they have already seen this problem with create_pipe_bidi. On Fri, 9 Apr 2010, Petr Machata wrote: > I was rebasing the bison package to latest stable (2.4.2) in Fedora > distribution, and found out that the test case 67 fails. I'm attaching > testfile.log. Here's

Re: [PATCH] Fix handling of restrict keyword for newer Sun Studio C++.

On Sat, 10 Apr 2010, Bruno Haible wrote: > 2010-04-10 Bruno Haible > > * m4/gnulib-common.m4 (AC_C_RESTRICT): Don't define for > autoconf >= 2.62. > Reported by Joel E. Denny . That works for me. Please push. Thanks.

Re: [PATCH 00/15] Add libunistring-optional module

Hi Paolo, > This series adds a libunistring-optional module. The purpose of the > module is to allow using a system libunistring whenever present, while > leaving the source code in the package too for the case when it is absent. > > The obvious step would be to make this the default. Unfortuna

Re: const local variables

On Sun, Apr 11, 2010 at 1:08 PM, Bruno Haible wrote: > James Youngman wrote: >> * lib/close-stream.c (close_stream): Make boolean variables const >> to document the fact that we set but do not change them. >> --- a/lib/close-stream.c >> +++ b/lib/close-stream.c >> @@ -55,9 +55,9 @@ >>  int >>  clo

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

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 was already closed. >> * lib/c

Re: const local variables

James Youngman wrote: > * lib/close-stream.c (close_stream): Make boolean variables const > to document the fact that we set but do not change them. > --- a/lib/close-stream.c > +++ b/lib/close-stream.c > @@ -55,9 +55,9 @@ > int > close_stream (FILE *stream) > { > - bool some_pending = (__fpend

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

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 was already closed. > * lib/close-stream.c (close_stream): Make boolean variables const >

Re: [PATCH] maint.mk: detect_empty_lines_at_EOF_: avoid FP for an empty file

Jim Meyering wrote: > FYI, > I discovered (not in coreutils) that an empty version-controlled > file would provoke a false-positive match from this new rule. > But only when it is not the last file in the list. > > $ :>empty; echo > f; echo g > g; tail -n1 empty f g > ==> empty <== > > ==> f

Re: [PATCH] fprintftime: avoid a warning about ignored fwrite return value

James Youngman wrote: > I think strftime also needs to depend on ignore-value, since > ignore-value.h is included in strftime.c. See the attached patch > which I forgot to send at the time. Hi James, The sole use of ignore_value is within an #if FPRINTFTIME block, as is the #include. Thus the fp

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

* 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 was already closed. * lib/close-stream.c (close_stream): Make boolean variables const to document the fact that we set b

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

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 - uses awk to compute the difference of two floating

[PATCH] maint.mk: detect_empty_lines_at_EOF_: avoid FP for an empty file

FYI, I discovered (not in coreutils) that an empty version-controlled file would provoke a false-positive match from this new rule. But only when it is not the last file in the list. $ :>empty; echo > f; echo g > g; tail -n1 empty f g ==> empty <== ==> f <== ==> g <== g This fixes it