Re: regex cannot be compiled with g++

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-local/lib/regcomp.c.diff andregexec.diff in gnulib-local/lib/regexec

Re: regex cannot be compiled with g++

Paul Eggert wrote: That problem arises because for some reason glibc prefers old-style function definitions when defining external functions meant to be called from C code. Does anyone know why that is? I assume it's some API thing. Sounds highly improbable. I thought that the function defini

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

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 scapegoat here. The exploit in [1] is a combination

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

Jim Meyering wrote: > The fact is that the current implementation in vasnprintf.c > penalizes *all* systems for the sake of the few with snprintf > that don't return a valid count. It has a few more instructions than needed, for portability. When cross- compiling, the gl_SNPRINTF_DIRECTIVE_N autoc

Re: gplv3 files and updates

Brett Smith <[EMAIL PROTECTED]> writes: > I'll go ahead and take that to RMS, then, so we can hammer out > something final. Thanks. > if you all would prefer, I can just send the final text back to this > list once the dust settles. That would be fine. If some interaction is needed please feel

Re: regex cannot be compiled with g++

That problem arises because for some reason glibc prefers old-style function definitions when defining external functions meant to be called from C code. Does anyone know why that is? I assume it's some API thing. As for changes like this: - dfa->state_table = calloc (sizeof (struct re_state_t

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

Jim Meyering <[EMAIL PROTECTED]> writes: > vasnprintf.c should resort to incurring the > expense of that portability kludge only when necessary. > How about if it does that only when a configure-time test > has detected that snprintf's return value is not conforming? That sounds like a good idea.

Re: gplv3 files and updates

On Thu, Oct 18, 2007 at 12:45:03AM -0700, Paul Eggert wrote: > That won't work well, because it's common for developers to use > symbolic links to gnulib source files, not munged copies of the source > files. Understood. Thanks for clearing that up for me. > The proposed permissions wording in >

@FOO@ vs. $(FOO) (was: Re: filenamecat-tests)

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"? Why "should"? Automake allows to write it both wa

Re: regex cannot be compiled with g++

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 patches attached -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHF9JnPp1Qsf2qnMcRAsTDAKCq8T4zZjQa4GK1ryygPrq3BLm1QACcCh8q 3amH5P4qSQ9+fMW/aL4BsN8= =JO3v -END PG

regex cannot be compiled with g++

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 looks like regex still does not support g++: g++ -DHAVE_CONFIG_H -I. -I../../src/gllib -I.. -MT regex.lo -MD -MP -MF .deps/regex.Tpo -c ../../src/gllib/regex.c -fPIC -DPIC -o .libs/regex.o ../../src/gllib/regcomp.c:260: error: 'reg_syntax_t re_set_s

Re: [Bug-tar] GNU tar 1.19 on HP-UX

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 H.Merijn Brand wrote: > On Thu, 18 Oct 2007 05:50:42 -0600, Eric Blake <[EMAIL PROTECTED]> wrote: > >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> According to H.Merijn Brand on 10/18/2007 1:43 AM: >>> Please convince the GNU world to add

Re: filenamecat-tests

* Jim Meyering wrote on Thu, Oct 18, 2007 at 02:35:35PM CEST: > > 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. But three already use $(E

Re: filenamecat-tests

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Jim Meyering on 10/18/2007 6:35 AM: > Eric Blake <[EMAIL PROTECTED]> wrote: >> The filenamecat-tests module needs an LDADD line to pull in -lintl on >> cygwin. Committing: > > Why does it need -lintl? Because it uses xmalloc, which uses

Re: filenamecat-tests

Eric Blake <[EMAIL PROTECTED]> wrote: > The filenamecat-tests module needs an LDADD line to pull in -lintl on > cygwin. Committing: Why does it need -lintl? > 2007-10-18 Eric Blake <[EMAIL PROTECTED]> > > * modules/filenamecat-tests (Makefile.am): Link against -lintl. ... > +test_filenam

Re: [Bug-tar] GNU tar 1.19 on HP-UX

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [Adding automake-patches; other lists can be dropped in replies.] > > According to H.Merijn Brand on 10/18/2007 1:43 AM: > > > > > > Please convince the GNU world to add 'make test' as alias for > > > 'make check'. > > > > It won't work for coreutil

Re: [Bug-tar] GNU tar 1.19 on HP-UX

On Thu, 18 Oct 2007 05:50:42 -0600, Eric Blake <[EMAIL PROTECTED]> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > According to H.Merijn Brand on 10/18/2007 1:43 AM: > > > > Please convince the GNU world to add 'make test' as alias for > > 'make check'. > > It won't work for coreut

filenamecat-tests

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The filenamecat-tests module needs an LDADD line to pull in -lintl on cygwin. Committing: 2007-10-18 Eric Blake <[EMAIL PROTECTED]> * modules/filenamecat-tests (Makefile.am): Link against -lintl. - -- Don't work too hard, make some time f

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

Bruno Haible <[EMAIL PROTECTED]> wrote: > Jim Meyering wrote: >> When I build a coreutils snapshot with -D_FORTIFY_SOURCE=2 on a >> relatively recent fedora-based system, seq always aborts like this: >> >> $ ./seq 1 >> *** %n in writable segment detected *** >> 1zsh: abort ./seq 1

Re: [Bug-tar] GNU tar 1.19 on HP-UX

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to H.Merijn Brand on 10/18/2007 1:43 AM: > > Please convince the GNU world to add 'make test' as alias for > 'make check'. It won't work for coreutils, where test is the name of a built program. That's why the GNU Coding Standards mandate '

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

Bruno Haible <[EMAIL PROTECTED]> wrote: > Jim Meyering wrote: >> When I build a coreutils snapshot with -D_FORTIFY_SOURCE=2 on a >> relatively recent fedora-based system, seq always aborts like this: >> >> $ ./seq 1 >> *** %n in writable segment detected *** >> 1zsh: abort ./seq 1

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

Bruno Haible <[EMAIL PROTECTED]> wrote: > Jim Meyering wrote: >> $ ./seq 1 >> *** %n in writable segment detected *** > > The use of format strings in writable memory is valid. Of course it is valid. No one questions that. But disallowing %n in a writable format string does protect applic

Re: several trim bugs

On Thu, Oct 18, 2007 at 12:57:17PM +0200, Bruno Haible wrote: > Thanks for reporting all this. I'm applying the appended patch to fix > all this. Thanks. > Colin Watson wrote: > > Fourthly, gcc complains: > > > > trim.c: In function ‘trim2’: > > trim.c:67: warning: ‘r’ may be used uninitiali

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

Jim Meyering wrote: > $ ./seq 1 > *** %n in writable segment detected *** The use of format strings in writable memory is valid. A use case is, for example, in printf (gettext ("foo %d bar %x %n"), ...); When the translator's and the user's charset encoding are not the same, or when m

Re: several trim bugs

Colin Watson wrote: > Firstly, the trim module fails to add its files to lib_SOURCES, so they > don't get built. > > Secondly, after fixing that, it tries to include "mbuiter.h" without > depending on that module. On inspection, I found that it claims to be > including it for MB_CUR_MAX, but that'

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

Jim Meyering wrote: > When I build a coreutils snapshot with -D_FORTIFY_SOURCE=2 on a > relatively recent fedora-based system, seq always aborts like this: > > $ ./seq 1 > *** %n in writable segment detected *** > 1zsh: abort ./seq 1 > [Exit 134 (ABRT)] > > That is due to the

Re: [Bug-tar] GNU tar 1.19 on HP-UX

H.Merijn Brand wrote: > cc -DHAVE_CONFIG_H -I. -I.. -I../lib -I../lib -I../src > -DLOCALEDIR=\"/pro/share/locale\" -Ae -O2 +Onolimit +Z -z +DD64 > -I/usr/local/ia64/include -I/usr/include/X11R6 -I/usr/contrib/X11R6/include > -c argcv.c > "../lib/string.h", line 82: error #2018: expected a ")"

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

Hi Bruno, When I build a coreutils snapshot with -D_FORTIFY_SOURCE=2 on a relatively recent fedora-based system, seq always aborts like this: $ ./seq 1 *** %n in writable segment detected *** 1zsh: abort ./seq 1 [Exit 134 (ABRT)] That is due to the fact that vasnprintf write

Re: gplv3 files and updates

Brett Smith <[EMAIL PROTECTED]> writes: > simply put the standard LGPL license header notice on the files that > are LGPLed, and give gnulib-tool a --gpl switch to convert the > files' headers to a GPL license notice on request. That won't work well, because it's common for developers to use symb

Re: [Bug-tar] GNU tar 1.19 on HP-UX

On Thu, 18 Oct 2007 00:04:14 -0700, Paul Eggert <[EMAIL PROTECTED]> wrote: > "H.Merijn Brand" <[EMAIL PROTECTED]> writes: > > > Can you give me a snapshot? I'll try again. > > Please try . > This is not a copy of tar 1.19; it is a modified version.

Re: [Bug-tar] GNU tar 1.19 on HP-UX

"H.Merijn Brand" <[EMAIL PROTECTED]> writes: > Can you give me a snapshot? I'll try again. Please try . This is not a copy of tar 1.19; it is a modified version.