maint.mk v. gzip 1.2.4

Greetings: While trying to build a recent edition of wget on a Tru64 system, I ran into a problem, apparently involving gnulib's maint.mk ("build-aux/maint.mk"?) 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 g

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

Bruno Haible <[EMAIL PROTECTED]> writes: > 1) test them both as reference implementations, like done in test-truncf2.c >and test-trunc2.c. > 2) use round_bruno1 as the implementation in lib/round.c if the corresponding >functions floor, ceil (or floorf, ceilf, or floorl, ceill) are not >

Re: regex cannot be compiled with g++

Sam Steingold <[EMAIL PROTECTED]> writes: > this is the standard way to handle calloc/malloc/alloca. It's one standard way, but there are others. In C, generally it's better to avoid the casts, since casts can suppress useful diagnostics. So, in C, it's usually better to not cast the results of

Re: new module: xprintf

Jim Meyering <[EMAIL PROTECTED]> wrote: > I've just added a new module: > > http://git.sv.gnu.org/gitweb/?p=gnulib.git;a=commitdiff;h=78da34d40e6a2 > > It was prompted by this thread: > > http://thread.gmane.org/gmane.comp.gnu.coreutils.bugs/11611/focus=11620 On this subject, I'm nearly co

some failing tests

Hello, I noticed that some gnulib tests fail on GNU/Linux/x86_64. ../../gltests/test-ceilf2.c:125: assertion failed /bin/sh: line 4: 6728 Aborted (core dumped) EXEEXT='' [...] srcdir='../../gltests' [...] ${dir}$tst FAIL: test-ceilf2 If I remove the assertion here, I get this o

new module: xprintf

I've just added a new module: http://git.sv.gnu.org/gitweb/?p=gnulib.git;a=commitdiff;h=78da34d40e6a2 It was prompted by this thread: http://thread.gmane.org/gmane.comp.gnu.coreutils.bugs/11611/focus=11620

Re: regex cannot be compiled with g++

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Eric Blake wrote: > > You do realize that your patch is a fork from glibc. I do now. > Why not push upstream on the glibc people, then? http://sources.redhat.com/bugzilla/show_bug.cgi?id=5200 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU

Re: gnulib-tool --lgpl doesn't convert gplv3 to lgplv2.1

Bruno Haible <[EMAIL PROTECTED]> writes: > Simon Josefsson wrote: >> I noticed this for the dummy.c module, which after been imported with >> --lgpl said: >> >>This program is free software: you can redistribute it and/or modify >>it under the terms of the GNU Lesser General Public Licens

Re: regex cannot be compiled with g++

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Sam Steingold on 10/19/2007 7:53 AM: >> The diffs may require updates every few months, when the copy in gnulib >> changes. (gnulib-tool gives an error when a .diff is stored in gnulib-local >> but it does not apply cleanly any more.) > >

Re: regex cannot be compiled with g++

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bruno Haible wrote: > Sam Steingold wrote: >> why not just apply the patch? > > You can also have your patch automatically applied by gnulib-tool. > To achieve this: > - create a directory, say, gnulib-local, > - store your regcomp.diff in gnulib-

stash clear, was Re: git: avoiding merges, rebasing

Hi, On Tue, 2 Oct 2007, Eric Blake wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > [adding the git list] > > According to Bruno Haible on 10/2/2007 5:50 AM: > > Hello Benoit, > > > >>> $ git stash > >>> $ git pull > >>> $ git stash apply > >>> $ git stash clean

Re: vasnprintf's "%n in writable segment" chokes with _FORTIFY_SOURCE == 2

Bruno Haible <[EMAIL PROTECTED]> wrote: > Jim Meyering wrote: >> It is the key that gives format-abusers so much latitude >> in choosing what value to write where. Without that >> feature, coming up with a real exploit is much harder. > > Without %n, one can still use format strings like > %.100

Re: @FOO@ vs. $(FOO)

Jim Meyering wrote: > In that vein, you may want to change your modules: > > modules/csharpexec:DEFS += -DEXEEXT=\"$(EXEEXT)\" > modules/javaexec:DEFS += -DEXEEXT=\"$(EXEEXT)\" > modules/relocatable-prog:DEFS += -DEXEEXT=\"$(EXEEXT)\" Done. http://git.sv.gnu.org/gitweb/?p=gnulib.git;a=commi

Re: vasnprintf's "%n in writable segment" chokes with _FORTIFY_SOURCE == 2

Jim Meyering wrote: > It is the key that gives format-abusers so much latitude > in choosing what value to write where. Without that > feature, coming up with a real exploit is much harder. Without %n, one can still use format strings like %.1000f%.1000f%.1000f%.1000f%.1000f

Re: vasnprintf's "%n in writable segment" chokes with _FORTIFY_SOURCE == 2

Bruno Haible <[EMAIL PROTECTED]> wrote: > > * m4/vasnprintf.m4 (VASNPRINTF): Don't use %n on glibc >= 2.3 systems. > Reported by Jim Meyering. > > *** lib/vasnprintf.c.orig 2007-10-19 01:49:53.0 +0200 Thanks for fixing it. I've corrected the ChangeLog.

Re: vasnprintf's "%n in writable segment" chokes with _FORTIFY_SOURCE == 2

Bruno Haible <[EMAIL PROTECTED]> wrote: > Jim Meyering wrote: >> But disallowing %n in a writable format string does >> protect applications from an entire class of exploits. >> That is worth more than enough to compensate for the minor limitation. > > Two remarks: > > * The %n has to serve as a sc

Re: @FOO@ vs. $(FOO)

Bruno Haible <[EMAIL PROTECTED]> wrote: > Jim Meyering wrote: >> BTW, does anyone know why all modules that add LIBINTL add >> it with the anachronistic @LIBINTL@, rather than $(LIBINTL)? >> Similarly, there are many uses of @EXEEXT@ that should be $(EXEEXT) >> these days. > > Why "anachronistic"?