Jim Meyering wrote:
> I've pushed the following to coreutils.
> While I think the rege* changes are useful and do belong in gnulib,
> I'll wait to hear that someone else would benefit from doing something
> similar before migrating my gl/lib/*.diff patches into gnulib.
Humph! ;-)
Silly typo.
>Fr
On 10/29/2009 10:24 AM, Jim Meyering wrote:
In making your case, it would be good to be able to itemize
the glibc bug fixes that have not yet been ported to gnulib,
I think there are none pending.
and contrast that gain with the (theoretical?) loss of support for
strings of length>= 2GiB.
M
I've pushed the following to coreutils.
While I think the rege* changes are useful and do belong in gnulib,
I'll wait to hear that someone else would benefit from doing something
similar before migrating my gl/lib/*.diff patches into gnulib.
>From e26cb21e6b89b06c8629a44bc6b78b2d46d110c9 Mon Sep
Paolo Bonzini wrote:
> On 10/29/2009 10:02 AM, Jim Meyering wrote:
>> IMHO it is a bug fix.
>> A semantically unsigned variable must never be decremented to -1.
>> I didn't try to see if it could induce misbehavior.
>
> No, it couldn't. The problem is that the variable is semantically
> unsigned i
On 10/29/2009 10:02 AM, Jim Meyering wrote:
IMHO it is a bug fix.
A semantically unsigned variable must never be decremented to -1.
I didn't try to see if it could induce misbehavior.
No, it couldn't. The problem is that the variable is semantically
unsigned in gnulib because of the IMHO deba
Paolo Bonzini wrote:
> On 10/29/2009 09:23 AM, Jim Meyering wrote:
>>> - Idx idx = re_node_set_contains (dest_nodes, cur_node) - 1;
>>> > - re_node_set_remove_at (dest_nodes, idx);
>>> > + Idx idx = re_node_set_contains (dest_nodes, cur_node);
>>> > + if (id
On 10/29/2009 09:23 AM, Jim Meyering wrote:
- Idx idx = re_node_set_contains (dest_nodes, cur_node) - 1;
> - re_node_set_remove_at (dest_nodes, idx);
> + Idx idx = re_node_set_contains (dest_nodes, cur_node);
> + if (idx)
> + re_node_set_remove_
Pádraig Brady wrote:
> Jim Meyering wrote:
>> Subject: [PATCH 2/2] build (--enable-gcc-warnings): enable gcc's -Werror
>> also in lib/
>>
>> * configure.ac (GNULIB_WARN_CFLAGS): Define.
>> * lib/Makefile.am (AM_CFLAGS): Use $(GNULIB_WARN_CFLAGS)
>> rather than $(WARN_CFLAGS) and add $(WERROR_CFLA
Paolo Bonzini wrote:
>> +diff --git a/lib/regcomp.c b/lib/regcomp.c
Hi Paolo.
Thanks for the review!
> This is okay.
>
>> diff --git a/gl/lib/regex_internal.c.diff b/gl/lib/regex_internal.c.diff
>
> This is okay. There is one caller of re_node_set_remove_at, in
> regexec.c, which might pass SIZ
+diff --git a/lib/regcomp.c b/lib/regcomp.c
This is okay.
diff --git a/gl/lib/regex_internal.c.diff b/gl/lib/regex_internal.c.diff
This is okay. There is one caller of re_node_set_remove_at, in
regexec.c, which might pass SIZE_MAX as the second parameter to
re_node_set_remove_at. This wo
Jim Meyering wrote:
> With these two change sets, ./configure --enable-gcc-warnings && make
> in builds with most warnings enabled also in lib/.
>
> To make that work, I've chosen to disable-in-lib/ some warning options, via
>
> -Wno-missing-prototypes
> -Wno-uninitialized
> -Wno-unused-macro
Bruno Haible wrote:
> math.in.h does declare everything that it provides. But math.in.h is not
> always present when isnan[fdl].c is compiled.
>
> This should silence gcc and address your question.
>
> 2009-10-27 Bruno Haible
>
> * lib/isnan.c (rpl_isnan[fdl]): Repeat the specification dec
Bruno Haible wrote:
> Jim Meyering wrote:
>> build (--enable-gcc-warnings): enable gcc's -Werror also in lib/
>
> Does your README-hacking file say that building with
> --enable-gcc-warnings is only supported on glibc systems with
> recent enough GCC?
Good point. We all knew that, but it wasn't d
Eric Blake wrote:
> > b/lib/isnan.c
> > +@@ -67,6 +67,8 @@
> > + ((sizeof (DOUBLE) + sizeof (unsigned int) - 1) / sizeof (unsigned int))
> > + typedef union { DOUBLE value; unsigned int word[NWORDS]; } memory_double;
> > +
> > ++int FUNC (DOUBLE x);
>
> Why are there no header files declari
Jim Meyering wrote:
> build (--enable-gcc-warnings): enable gcc's -Werror also in lib/
Does your README-hacking file say that building with
--enable-gcc-warnings is only supported on glibc systems with
recent enough GCC? It is known that on other platforms and with
older GCC versions, gcc shows ma
Eric Blake wrote:
> According to Jim Meyering on 10/27/2009 6:24 AM:
>> +
>> + AC_SUBST([GNULIB_WARN_CFLAGS])
>> + GNULIB_WARN_CFLAGS="$WARN_CFLAGS -Wno-missing-prototypes
>> -Wno-uninitialized -Wno-unused-macros -Wno-old-style-definition"
>
> Shouldn't this use gl_MANYWARN_COMPLEMENT([var], [$w
Jim Meyering wrote:
> Subject: [PATCH 2/2] build (--enable-gcc-warnings): enable gcc's -Werror also
> in lib/
>
> * configure.ac (GNULIB_WARN_CFLAGS): Define.
> * lib/Makefile.am (AM_CFLAGS): Use $(GNULIB_WARN_CFLAGS)
> rather than $(WARN_CFLAGS) and add $(WERROR_CFLAGS).
> * gl/lib/isnan.c.diff:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Jim Meyering on 10/27/2009 6:24 AM:
> +
> + AC_SUBST([GNULIB_WARN_CFLAGS])
> + GNULIB_WARN_CFLAGS="$WARN_CFLAGS -Wno-missing-prototypes
> -Wno-uninitialized -Wno-unused-macros -Wno-old-style-definition"
Shouldn't this use gl_MANYWARN_C
With these two change sets, ./configure --enable-gcc-warnings && make
in builds with most warnings enabled also in lib/.
To make that work, I've chosen to disable-in-lib/ some warning options, via
-Wno-missing-prototypes
-Wno-uninitialized
-Wno-unused-macros
-Wno-old-style-definition"
In
19 matches
Mail list logo
