Inspired by Paul's report of swapped strtol args (args 2 and 3)
in a coreutils-specific test that evoked a well-deserved warning.
However, I've missed it for ages because it was buried under so
many others. Now I'm motivated to enable -Werror also when compiling
in coreutils' gnulib-tests/
FYI,
From 9492afb6b3850fb798d9cf83d03b0f9664a4c7b2 Mon Sep 17 00:00:00 2001
From: Jim Meyering meyer...@redhat.com
Date: Wed, 13 Oct 2010 10:06:29 +0200
Subject: [PATCH] test-symlinkat: remove declaration of unused local
* tests/test-symlinkat.c (main): Remove unused local, buf.
---
ChangeLog
Hmm... now I know why I prefer emacs!
On 13 Oct 2010, at 16:40, Gary V. Vaughan wrote:
On 13 Oct 2010, at 03:26, Bruno Haible wrote:
And, please, in gnulib code, we don't use tabs any more, except in pieces
of Makefiles and ChangeLog. See the section Indent with spaces, not TABs
of
On 13 Oct 2010, at 03:43, Bruno Haible wrote:
Making libposix into a module makes life considerably easier.
Yes, it triggers the magic that tells gnulib-tool to omit the augmentation of
noinst_LIBRARIES.
But I don't agree with putting the module list here. Who will keep it
up-to-date?
On 13 Oct 2010, at 03:17, Bruno Haible wrote:
* gnulib-tool (func_import): support multiple gllib directories:
headers are generated for each gllib differently, depending on which
features are actually used, so we need to be able to include all
these generated headers without fear that one
On 13 Oct 2010, at 08:18, Bruce Korb wrote:
Hi Gary,
Howdy Bruce!
On 10/12/10 09:08, Gary V. Vaughan wrote:
+++ b/libposix/bootstrap
@@ -0,0 +1,55 @@
+#! /bin/sh
+
+PATH=..:$PATH
+
+gnulib-tool --import --lib=libposix --makefile-name=gnulib.mk \
+ --macro-prefix=LIBPOSIX --libtool
On 13 Oct 2010, at 03:03, Bruno Haible wrote:
Hi Gary,
Hallo Bruno,
This patch series is what I've just pushed as a new topic branch to
the savannah repo.
Wow! You're fast. I love your initiative and appreciate your approach.
Thanks. And thanks also for the fast responses.
Okay to
Hallo Bruno,
Thanks again for the speedy and thoughtful feedback on this
patch series. I'm sorry that I won't have the time to actually
apply any of your good advice for at least a couple of weeks,
but whatever is still outstanding when I next have discretionary
hacking time, I'll apply, retest
On 13 Oct 2010, at 03:55, Bruno Haible wrote:
Originally, I added noinst_HEADERS to the module definition files,
and then changed them all to nobase_nodist_include_HEADERS and
EXTRA_HEADERS in gnulib-tool if the gnulib library is installable.
However, I think it is much more flexible to add
On 13 Oct 2010, at 03:59, Bruno Haible wrote:
* libposix/bootstrap: New script to import gnulib posix modules
and bootstrap configury so that the result is an installable
libposix.la.
* libposix/configure.ac: New file to configure the new libposix
subdirectory.
* libposix/Makefile.am: New
On 10/12/2010 11:20 PM, Bruno Haible wrote:
Gary V. Vaughan wrote:
git-version-gen itself relies on the presence of .git in the
current directory. I've made a quick and dirty patch to it
here to also look in the parent directory... but surely there's
a nicer way to determine whether the
On 10/13/2010 10:19 AM, Jim Meyering wrote:
Hi Paolo,
Is this change ok with you?
Without it, I see many warnings like this when running
coreutils's make check (with --enable-gcc-warnings):
test-select.c: In function 'test_pair':
test-select.c:330: warning: ignoring return value of
Hallo Bruno,
On 13 Oct 2010, at 02:48, Bruno Haible wrote:
Then I believe the only viable option to provide stable support for
multiple gnulib directories in a single tree is to add a switch to
gnulib-tool to rewrite gnulib #include_next lines on import, so that
both types of compilers
Hi Paolo,
Is this change ok with you?
Without it, I see many warnings like this when running
coreutils's make check (with --enable-gcc-warnings):
test-select.c: In function 'test_pair':
test-select.c:330: warning: ignoring return value of 'write', declared \
with attribute
Hi Paul,
On 13 Oct 2010, at 03:12, Paul Eggert wrote:
On 10/11/10 18:21, Gary V. Vaughan wrote:
As I've tweaked it to support existing users, I've found that some
of them (bison and tar, I'm looking at you!) don't even use the
canonical version.
That's been fixed as of Oct 8 and Oct 11,
Paolo Bonzini wrote:
On 10/13/2010 10:19 AM, Jim Meyering wrote:
Hi Paolo,
Is this change ok with you?
Without it, I see many warnings like this when running
coreutils's make check (with --enable-gcc-warnings):
test-select.c: In function 'test_pair':
test-select.c:330: warning:
On 13 Oct 2010, at 03:35, Bruno Haible wrote:
By itself, this patch reduces unnecessary repetition, but also sets up
a later patch in this series to not need to make yet another copy of
the listed headers.
* modules/iconv_open (iconv_headers): New make macro to hold list of
iconv header
On 13 Oct 2010, at 03:26, Bruno Haible wrote:
* gnulib-tool (func_emit_lib_Makefile_am): transform hard-coded
`libgnu.a' in Makefile.am snippets to be either `$libname.a' or
`$libname.la', depending on whether --libtool/--no-libtool options
were given.
Here it's clear that we need a way to
Hi Bruno,
Is this ok with you?
With this, the other changes posted here today, as well as
one more in coreutils (to exempt 3 offenders I won't bother with),
gnulib-tests/ now compiles with -Werror.
From 6ff0dbc6886418b68b6f19cfdaec34e751ae88ad Mon Sep 17 00:00:00 2001
From: Jim Meyering
Hi Bruno,
Is this change ok with you?
Alternatively, I'd be slightly happier simply
to remove the warning-evoking tests.
Here's one of the 5 warnings:
test-nl_langinfo.c:56: warning: comparison of unsigned expression = 0 \
is always true [-Wtype-limits]
From
Nearly forgot this.
Technically you might argue that it is not really required, since
./gnulib-tool --create-testdir --with-tests --test select
succeeds without it. (some dependent module pulls in that commonly
required file) But it's better to make it explicit, so I've folded
this in:
diff
[adding bug-gnulib]
On 10/13/2010 06:22 AM, Daniel P. Berrange wrote:
On Wed, Oct 13, 2010 at 06:16:03AM -0600, Eric Blake wrote:
On 10/13/2010 04:34 AM, Daniel P. Berrange wrote:
The configure.ac file checks for termios.h, but its use is
not protected by HAVE_TERMIOS_H. This breaks the build
Giuseppe Scrivano wrote:
Bruno, Jim,
thanks for your comments.
Jim Meyering j...@meyering.net writes:
What is your use case?
I have the git repository in myserver/, but the top_srcdir is in
myserver/myserver/.
Won't this proposal cause trouble when
running git-version-gen in a
Hello,
Jim Meyering j...@meyering.net writes:
Not sure about more elegant, but here's a lower cost method:
Thanks for the patch but I think the problem you have reported here:
http://article.gmane.org/gmane.comp.lib.gnulib.bugs/21845
persists.
Here an example, where /tmp/foo is a git
Giuseppe Scrivano wrote:
Hello,
Jim Meyering j...@meyering.net writes:
Not sure about more elegant, but here's a lower cost method:
Thanks for the patch but I think the problem you have reported here:
http://article.gmane.org/gmane.comp.lib.gnulib.bugs/21845
persists.
Here an
Hi Gary,
* Gary V. Vaughan wrote on Wed, Oct 13, 2010 at 11:45:52AM CEST:
Hmm... it's a pity that there isn't an Automake syntax for transforming
lists of filenames (that works with portable make anyway), since having
four near-identical lists of filenames bothers me a (tiny) little bit.
For
Hello, and adding bug-automake,
* Gary V. Vaughan wrote on Wed, Oct 13, 2010 at 12:06:32PM CEST:
On 13 Oct 2010, at 03:55, Bruno Haible wrote:
And what's the role or effect of EXTRA_HEADERS? Automake does not do
anything with .h files that it doesn't do with .png files. gnulib-tool
already
Jim Meyering wrote:
Giuseppe Scrivano wrote:
Hello,
Jim Meyering j...@meyering.net writes:
Not sure about more elegant, but here's a lower cost method:
Thanks for the patch but I think the problem you have reported here:
http://article.gmane.org/gmane.comp.lib.gnulib.bugs/21845
* m4/termios_h.m4 (gl_TERMIOS_H_DEFAULTS): Set default.
(gl_TERMIOS_H): Adjust it on mingw.
* modules/termios (Makefile.am): Substitute new key.
* lib/termios.in.h (includes): Make include_next conditional.
* doc/posix-headers/termios.texi (termios.h): Update
documentation.
Reported by Daniel P.
i havent seen any mention on glibc or gnulib lists of CVE-2010-2632. the
report claims glibc is affected, and since the gnulib/glibc implementations
are pretty similar, gnulib would be as well. i dont suppose there is a bug
report somewhere i could follow for status on this ?
Mike Frysinger wrote:
i havent seen any mention on glibc or gnulib lists of CVE-2010-2632. the
report claims glibc is affected, and since the gnulib/glibc implementations
are pretty similar, gnulib would be as well. i dont suppose there is a bug
report somewhere i could follow for status
On 10/13/10 15:38, Bruno Haible wrote:
But why should this be a bug in libc? There are many functions in libc that
can allocate an arbitrary amount of memory.
I agree that applications should set reasonable memory limits, but
this is still a bug in glob, because glob should not return
On Wednesday, October 13, 2010 18:38:14 Bruno Haible wrote:
Mike Frysinger wrote:
i havent seen any mention on glibc or gnulib lists of CVE-2010-2632. the
report claims glibc is affected, and since the gnulib/glibc
implementations are pretty similar, gnulib would be as well. i dont
Hello Jim,
Jim Meyering j...@meyering.net writes:
Thanks again for the quick corrections.
Here's a better version. I'll wait for review this time ;-)
I have tried the new version and it seems to work well. I am going to
remove the workaround I had to use and keep my copy sync'ed with the
Hi Paul,
I agree that applications should set reasonable memory limits, but
this is still a bug in glob, because glob should not return duplicates.
For example, the pattern {.,.} should match just ., not two instances
of . as it does now.
POSIX describes glob() in a way that precludes
On 10/12/2010 12:58 PM, Jim Meyering wrote:
Please push that, too.
OK, I pushed that here, into gnulib:
http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commitdiff;h=1179fb893526296be259211c2530feb225ebefc8
On 10/13/2010 05:48 PM, Bruno Haible wrote:
But the braces are a GNU extension, and the doc
http://www.gnu.org/software/libc/manual/html_mono/libc.html
is pretty clear that {..,..} _will_ generate duplicates.
As near as I can tell, this is an accident, both of the libc implementation
and of
37 matches
Mail list logo
