Re: failure to build due to ignoring fwrite() result

Karl, all, > @pindex lint > ! Don't make the program ugly to placate @code{lint}. Please don't insert any > ! casts to @code{void}. Zero without a cast is perfectly fine as a null > ! pointer constant, except when calling a varargs function. Here is a proposed wording that - acknowledges th

Re: feature request: detect CPU instruction set

Sam Steingold wrote: > > So, except for code style, you are fine with that proposed module? > yes. OK. In the absence of other comments, I committed and pushed the new module. Bruno

Re: feature request: detect CPU instruction set

Hi Bruno, On 8/31/10, Bruno Haible wrote: > > It apparently depends for whom the code should be readable. since you will be maintaining the code, it is your choice. > So, except for code style, you are fine with that proposed module? yes. -- Sam Steingold

Re: next m4 snapshot [was: debugging M4 on AIX 5.3]

On Mon, Aug 30, 2010 at 01:55:02PM -0600, Eric Blake wrote: > [phooey - hit send too soon] > > On 08/30/2010 01:53 PM, Eric Blake wrote: > >On 08/21/2010 02:42 AM, Ralf Wildenhues wrote: > >>I'm trying to debug the recent regression of git branch-1.4 M4 over M4 > >>1.4.14 on AIX. > > > >Here's the

Re: feature request: detect CPU instruction set

Hi Sam, > you say you want to cache just once. > fine, remove AC_CACHE_CHECK. Yes, I removed the AC_CACHE_CHECK invocations and then found that there was no good reason any more to keep the CL_CACHE_EGREP_CPP and CL_SET_CPU_ABI macros. > I have > dnl CL_CACHE_EGREP_CPP(what,variable,condition) >

Re: feature request: detect CPU instruction set

Bruno Haible wrote: Compared to the code that you proposed: - I changed the name, of course. - I chose to use AC_CACHE_CHECK once for the result of the entire macro, not for each AC_EGREP_CPP inside it. - I dropped Convex CPUs; these are dead for more than 10 years. - I added an AH_TO

Re: [PATCH] hash: silence spurious clang warning

Eric Blake wrote: > On 08/31/2010 08:11 AM, Eric Blake wrote: >> On 08/31/2010 02:10 AM, Jim Meyering wrote: >>> Eric, I've listed you as an author, so will wait for your ACK. >>> From 5bcff7b85b7b88fa4809ad874a1203e27abed085 Mon Sep 17 00:00:00 2001 >>> From: Eric Blake >>> Date: Tue, 31 Aug

Re: [PATCH] hash: silence spurious clang warning

On 08/31/2010 08:11 AM, Eric Blake wrote: On 08/31/2010 02:10 AM, Jim Meyering wrote: Eric, I've listed you as an author, so will wait for your ACK. From 5bcff7b85b7b88fa4809ad874a1203e27abed085 Mon Sep 17 00:00:00 2001 From: Eric Blake Date: Tue, 31 Aug 2010 10:06:16 +0200 Subject: [PATCH] h

Re: [PATCH] hash: silence spurious clang warning

On 08/31/2010 02:10 AM, Jim Meyering wrote: Eric, I've listed you as an author, so will wait for your ACK. From 5bcff7b85b7b88fa4809ad874a1203e27abed085 Mon Sep 17 00:00:00 2001 From: Eric Blake Date: Tue, 31 Aug 2010 10:06:16 +0200 Subject: [PATCH] hash: factor, and guard against misbehaving

Re: failure to build due to ignoring fwrite() result

On 08/31/2010 05:34 AM, Bruce Korb wrote: 1. GCC needs to relax the constraint that functions marked with warn-unused-result cause warnings when the result_is_ handled with a void cast. This is done by design (I disagree, but this is not going to change). This is the only reason wh

Re: failure to build due to ignoring fwrite() result

On 08/31/2010 03:24 AM, Bruno Haible wrote: Hi Paul, + @pindex gcc @pindex lint ! @pindex valgrind ! Don't make the program ugly to placate @code{gcc -Wall}, -Wextra should fix Bruno's valid complaint. @code{lint}, ! @code{valgrind}, or other software analysis tools. These tools can ! h

Re: next m4 snapshot

Rainer Tammer wrote: > All checks are OK on AIX 5.3. > All checks are OK on AIX 6.1 > All checks are OK on AIX 7BETA Nice! Thanks for testing. > Which gnulib patch fixed the regex problem on AIX ?? It was apparently this one: http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commitdiff;h=560be6

Re: [PATCH] hash: silence spurious clang warning

Eric Blake wrote: > On 08/30/2010 05:09 PM, Bruno Haible wrote: >> Hi Eric, >> >>> - if (! (bucket< table->bucket_limit)) >>> + if (! (bucket&& bucket< table->bucket_limit)) >>> abort (); >> >> I would not apply this, because it causes a slowdown at runtime >> for no good reason. > > Hmm