Re: [PATCHv2] stdio: don't assume gets any more

On 03/29/2012 07:38 PM, Bruno Haible wrote: > Paul Eggert wrote: >> Gnulib shouldn't be catering >> to apps that use gets, since gets should never >> be used by anybody. > > Indeed. Good point. > > Eric Blake wrote: >> Gnulib intentionally does not have a gets module, and now that C11 >> and glib

[PATCH] maint.mk: fix syntax checks without exclusions

Commit 727075d0 skipped per-line exclusions if ${exclude} is left undefined, but was immediately broken by commit 44de969c which always initialized the variable to the empty string. * top/maint.mk (_sc_search_regexp): Allow for empty variable. Signed-off-by: Eric Blake --- Previously, I said >

Re: [PATCHv2] stdio: don't assume gets any more

Paul Eggert wrote: > Gnulib shouldn't be catering > to apps that use gets, since gets should never > be used by anybody. Indeed. Good point. Eric Blake wrote: > Gnulib intentionally does not have a gets module, and now that C11 > and glibc have dropped it, we should be more proactive about warnin

Re: warnings.m4: check the compiler, not the preprocessor.

Akim Demaille wrote: > Currently the macro does > not depend on the language to store its result This patch appears broken to me: - On one hand it augments CPPFLAGS without ever setting it back. - On the other hand it saves and restores CFLAGS or CXXFLAGS but without temporarily modifying

Re: Syntax check rules broken if 'exclude' is not defined

On 03/29/2012 07:17 AM, Daniel P. Berrange wrote: > I noticed that many (most) of the libvirt syntax-check rules were not > generating any results, despite me introducing obvious violations. > >>From my debugging the problem appears to be caused by this commit: > > commit 727075d03c670affa68f71

[PATCH] strerror_r: avoid compiler warning

Nested declarations are easy to avoid, and doing so avoids at least libvirt's choice of compiler warnings. * lib/strerror_r.c (strerror_r): Hoist extern declaration to top level. Signed-off-by: Eric Blake --- ChangeLog|4 lib/strerror_r.c |3 +-- 2 files changed, 5 insertio

[PATCH] fflush: avoid compiler warning

Compiling under glibc produced warnings. * lib/fflush.c (update_fpos_cache): Mark variables that are potentially unused. Signed-off-by: Eric Blake --- ChangeLog|4 lib/fflush.c |3 ++- 2 files changed, 6 insertions(+), 1 deletions(-) diff --git a/ChangeLog b/ChangeLog index 76

[PATCH] ssize_t: fix definition on mingw

We were blindly defining ssize_t to int. On mingw64, this is the correct size, but the wrong rank, which leads gcc to issue warnings for %zd printf directives. * m4/ssize_t.m4 (gt_TYPE_SSIZE_T): Match rank of size_t. Signed-off-by: Eric Blake --- Bruno, is this okay to apply? ChangeLog |

Re: warnings.m4: check the compiler, not the preprocessor.

On 03/29/2012 07:36 AM, Akim Demaille wrote: > For Bison I would like to test C and C++ warnings > in two different batches. Currently the macro does > not depend on the language to store its result, and > it does not try to compile, just to preprocess. > > * m4/warnings.m4 (gl_WARN_ADD): Use th

[PATCHv2] stdio: don't assume gets any more

Gnulib intentionally does not have a gets module, and now that C11 and glibc have dropped it, we should be more proactive about warning any user on a platform that still has a declaration of this dangerous interface. * m4/stdio_h.m4 (gl_STDIO_H, gl_STDIO_H_DEFAULTS): Drop gets support. * modules/s

Re: [PATCH] stdio: don't assume gets any more

On 03/29/2012 12:35 PM, Eric Blake wrote: > Any thoughts before I push this? Yes, thanks, this is the sort of thing that I had in mind in the earlier thread today about this . Some comments about the patch details: The GNULIB_G

[PATCH] stdio: don't assume gets any more

Gnulib intentionally does not have a gets module, and now that C11 and glibc have dropped it, we should be more proactive about warning any user on a platform that still has a declaration of this dangerous interface. * m4/stdio_h.m4 (gl_STDIO_H, gl_STDIO_H_DEFAULTS): Drop gets support. * lib/stdio

Re: build failure on cross build

On 03/29/2012 02:44 AM, Bruno Haible wrote: > I think gnulib should > 1) not assume that the function is declared, > 2) have a deprecated module 'gets' that declares this function only if > the declaration is missing. How about if gnulib drops support for gets instead? That would be simpl

warnings.m4: check the compiler, not the preprocessor.

For Bison I would like to test C and C++ warnings in two different batches. Currently the macro does not depend on the language to store its result, and it does not try to compile, just to preprocess. 0001-warnings.m4-check-the-compiler-not-the-preprocessor.patch Description: Binary data FWIW

Syntax check rules broken if 'exclude' is not defined

I noticed that many (most) of the libvirt syntax-check rules were not generating any results, despite me introducing obvious violations. >From my debugging the problem appears to be caused by this commit: commit 727075d03c670affa68f71313979781f5ba9bbfc Author: Eric Blake Date: Thu Mar 1

Re: [libvirt] [PATCH 2/4] Fix format specifiers in test cases on Win32

On Thu, Mar 29, 2012 at 06:45:03AM -0600, Eric Blake wrote: > On 03/29/2012 03:53 AM, Daniel P. Berrange wrote: > > From: "Daniel P. Berrange" > > > > Some of the test suites use fprintf with format specifiers > > that are not supported on Win32 and are not fixed by gnulib. > > > > The mingw32 c

Re: [libvirt] [PATCH 2/4] Fix format specifiers in test cases on Win32

On 03/29/2012 03:53 AM, Daniel P. Berrange wrote: > From: "Daniel P. Berrange" > > Some of the test suites use fprintf with format specifiers > that are not supported on Win32 and are not fixed by gnulib. > > The mingw32 compiler also has trouble detecting ssize_t > correctly, complaining that '

Re: bug#11115: linux date arithmetic

Eric Blake wrote: > > "10:38 minute" or "12:38 minute" is not a time designation I have ever heard > > in spoken nor written English. > > True, 'minute' in isolation, without a 'plus one' qualifier, is unusual; > but we have to continue to parse it in isolation since scripts may now > be relying o

Re: build failure on cross build

Pádraig Brady wrote: > gnulib (CC'd) says it's assuming 'gets' > is declared. Can you see why this isn't the case for you? Newer glibcs don't declare gets() any more. The glibc ChangeLog has this: 2012-01-12 Marek Polacek * libio/bits/stdio2.h: Do not define gets for ISO C11, ISO C++1

Re: build failure on cross build

2012/3/29 Pádraig Brady : > This is the bit triggering from gnulib (CC'd) says it's assuming 'gets' > is declared. Can you see why this isn't the case for you? > Sure, but how? :-) -- chs,

Re: build failure on cross build

On 03/28/2012 09:22 PM, Christer Solskogen wrote: > Hi! > > I've created my "own" cross compiler for powerpc (gcc, binutils and eglibc) > and > I'm having trouble cross compiling coreutils with that compiler. I do not > have > any > trouble compiling both binutils, eglibc and bash with the sa