Re: regex cannot be compiled with g++

Paul Eggert wrote: This casting business is a relatively minor point; I'm more worried about the old-style function definitions. I wish I knew why glibc does it that way. http://sources.redhat.com/bugzilla/show_bug.cgi?id=5200 just ask.

Re: maint.mk v. gzip 1.2.4

From: Bruno Haible > This was already reported and fixed in coreutils, in > http://lists.gnu.org/archive/html/bug-coreutils/2006-08/msg00111.html I like my "2>&1" better than that "2>/dev/null", as mine would work if the thing being sought were actually there. (And it's shorter.) Discar

Re: typo in count-one-bits module

Bruno Haible <[EMAIL PROTECTED]> writes: > GCC does not define the macro __GNUC_MINOR. Its use looks like a typo to me. > OK to commit this? Yes, please do so. -- Ben Pfaff http://benpfaff.org

Re: maint.mk v. gzip 1.2.4

Bruno Haible <[EMAIL PROTECTED]> writes: > Why do coreutils and gnulib have to have different copies of these Makefile > rules? I think this is because someone (not me or Jim; I forget who) changed how those files worked in gnulib without getting those changes integrated into coreutils, and the f

Re: stdbool.h test v. Compaq C on Tru64

In a followup to , Ralf Wildenhues <[EMAIL PROTECTED]> writes: > It would be more interesting to see why gnulib's stdbool.h can't cope. I agree. This is a longstanding problem with DEC/Compaq/HP C. It's case 3411658RE in thei

typo in count-one-bits module

Hi Ben, GCC does not define the macro __GNUC_MINOR. Its use looks like a typo to me. OK to commit this? 2007-10-20 Bruno Haible <[EMAIL PROTECTED]> * lib/count-one-bits.h (COUNT_ONE_BITS): Use the builtin also for gcc-3.4.x. --- lib/count-one-bits.h.orig 2007-10-21 01:05:36.

Re: xstrdup (NULL)

Hi, Colin Watson wrote: > The hand-rolled implementation of xstrdup I used to use before > converting to Gnulib tolerated being passed a NULL string and simply > returned NULL. I found this convenient; it saved a number of tedious > checks, in much the same way that free doesn't mind being passed

Re: 'round' modules takes 3

Bruno Haible <[EMAIL PROTECTED]> writes: > In m4/round.m4, the test whether floor() is available without libm is useful > for any uses of floor(). I'm therefore putting it into a separate module > 'floor' which you can then depend on. Thanks, done. > In m4/roundf.m4 you need an AC_REQUIRE([gl_FU

Re: new module: xprintf

Bruno Haible <[EMAIL PROTECTED]> wrote: > Eric Blake wrote: >> gnulib-tool output is already verbose > > It was mentioned that verbosity can be overcome by looking at the differences > between the previous run and the current run. I use the attached script daily. > >> is there a better way to just

xstrdup (NULL)

The hand-rolled implementation of xstrdup I used to use before converting to Gnulib tolerated being passed a NULL string and simply returned NULL. I found this convenient; it saved a number of tedious checks, in much the same way that free doesn't mind being passed a NULL pointer. Would you conside

Re: new module: xprintf

Eric Blake wrote: > gnulib-tool output is already verbose It was mentioned that verbosity can be overcome by looking at the differences between the previous run and the current run. I use the attached script daily. > is there a better way to just automatically update po/Makevars (possibly > by te

Re: new module: xprintf

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Bruno Haible on 10/20/2007 8:22 AM: > So that this doesn't get forgotten in the future, I propose this patch. It > has the effect that gnulib-tool reports: gnulib-tool output is already verbose; is there a better way to just automatically

Re: new module: xprintf

Bruno Haible <[EMAIL PROTECTED]> wrote: >> I've just added a new module: >> >> http://git.sv.gnu.org/gitweb/?p=gnulib.git;a=commitdiff;h=78da34d40e6a2 > > gnulib-tool gives these warnings when the module is used: > warning: module xprintf depends on a module with an incompatible license: exit >

Re: new module: xprintf

Jim Meyering wrote: > I've just added a new module: > > http://git.sv.gnu.org/gitweb/?p=gnulib.git;a=commitdiff;h=78da34d40e6a2 Note that the XGETTEXT_OPTIONS will need to be updated to take into account these new functions that take a format string as argument. So that this doesn't get forg

Re: new module: xprintf

Bruno Haible <[EMAIL PROTECTED]> wrote: > Thanks; this module is necessary. > > Two suggestions: > > - Add a call to va_end() that matches the va_start() call. POSIX says: > "Each invocation of the va_start() and va_copy() macros shall be matched >by a corresponding invocation of the va_end()

Re: new module: xprintf

Hi Jim, > I've just added a new module: > > http://git.sv.gnu.org/gitweb/?p=gnulib.git;a=commitdiff;h=78da34d40e6a2 gnulib-tool gives these warnings when the module is used: warning: module xprintf depends on a module with an incompatible license: exit warning: module xprintf depends on a mo

Re: new module: xprintf

Bruno Haible <[EMAIL PROTECTED]> wrote: > Jim Meyering wrote: >> On this subject, I'm nearly convinced that we need printf and fprintf >> wrappers that call fseterr when necessary. That would be cleaner and >> more maintainable than doing s/printf/xprintf/ everywhere. > > I disagree. When you cal

Re: new module: xprintf

Jim Meyering wrote: > On this subject, I'm nearly convinced that we need printf and fprintf > wrappers that call fseterr when necessary. That would be cleaner and > more maintainable than doing s/printf/xprintf/ everywhere. I disagree. When you call fseterr, you lose information about the origin

Re: new module: xprintf

Hi Jim, > I've just added a new module: > > http://git.sv.gnu.org/gitweb/?p=gnulib.git;a=commitdiff;h=78da34d40e6a2 Thanks; this module is necessary. Two suggestions: - Add a call to va_end() that matches the va_start() call. POSIX says: "Each invocation of the va_start() and va_copy() m

Re: some failing tests

Hello Ralf, Thanks for this testing! x86_64 platforms are important nowadays. > ../../gltests/test-ceilf2.c:125: assertion failed > /bin/sh: line 4: 6728 Aborted (core dumped) EXEEXT='' [...] > srcdir='../../gltests' [...] ${dir}$tst > FAIL: test-ceilf2 > > ../../gltests/test-f

new modules 'floor', 'ceil'

I added new modules 'floor', 'ceil'. Since all systems have these functions and (as far as we know) declare them in , all these modules do is to determine whether linking with -lm is necessary or not. http://git.sv.gnu.org/gitweb/?p=gnulib.git;a=commitdiff;h=93ac3c97f65305215855750c72024a3745948aa

Re: 'round' modules takes 3 (was: Re: modules 'round', 'roundf', 'roundl' for review)

Hi Ben, Well done! > Finally, I noticed a nit in that test-trunc2 and test-truncf2 use > %a in fprintf, a C99 feature, but do not depend on fprintf-posix. > I did add that dependency to round-tests and roundf-tests. Oops, you're right. Done also for ceilf-tests, floorf-tests, trunc[f]-tests. In

Re: maint.mk v. gzip 1.2.4

Hi Jim & Simon, Steven M. Schweda wrote: >On a system with an old gzip, say version 1.2.4 (which is supplied > with Tru64), the victim gets much spewage from an unhappy gzip test. > For example: > ... >The cause of this clutter appears to be this part of maint.mk: > > # Do not save