H.Merijn Brand [EMAIL PROTECTED] writes:
Can you give me a snapshot? I'll try again.
Please try http://www.cs.ucla.edu/~eggert/tar-1.19.tar.gz.
This is not a copy of tar 1.19; it is a modified version.
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 http://www.cs.ucla.edu/~eggert/tar-1.19.tar.gz.
This is not a copy of tar 1.19; it is a modified version.
Please
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 fact
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 )
extern
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's
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 uninitialized in
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
[Exit
-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
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
[Exit
-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
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 coreutils, where
-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 coreutils, where test
-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 error,
* 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
-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
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
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 free
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
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
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
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
21 matches
Mail list logo
