bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: enable -Werror for lib/ in coreutils


From: Jim Meyering
Subject: Re: enable -Werror for lib/ in coreutils
Date: Wed, 28 Oct 2009 08:52:51 +0100

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 documented.
It is, now:

>From 02af47308667ffb33101943e27b411306f0e98af Mon Sep 17 00:00:00 2001
From: Jim Meyering <address@hidden>
Date: Wed, 28 Oct 2009 08:49:51 +0100
Subject: [PATCH] doc: tell --enable-gcc-warnings users where to report problems

* README-hacking: Add a caveat for --enable-gcc-warnings.
---
 README-hacking |    8 +++++++-
 1 files changed, 7 insertions(+), 1 deletions(-)

diff --git a/README-hacking b/README-hacking
index c5d3128..014114d 100644
--- a/README-hacking
+++ b/README-hacking
@@ -35,7 +35,7 @@ which are extracted from other source packages:

 And there you are!  Just

-        $ ./configure --quiet #[--enable-gcc-warnings]
+        $ ./configure --quiet #[--enable-gcc-warnings] [*]
         $ make
         $ make check

@@ -48,6 +48,12 @@ should output no difference.

 Enjoy!

+[*] The --enable-gcc-warnings option is useful only with glibc
+and with a very recent version of gcc.  You'll probably also have
+to use recent system headers.  If you configure with this option,
+and spot a problem, please be sure to send the report to the bug
+reporting address of this package, and not to that of gnulib, even
+if the problem seems to originate in a gnulib-provided file.
 -----

 Copyright (C) 2002-2009 Free Software Foundation, Inc.
--
1.6.5.2.344.ga473e

> It is known that on other platforms and with
> older GCC versions, gcc shows many warnings, most of which are
> irrelevant. I don't want to spend time on reducing the number of
> pointless warnings on non-glibc platforms, since we are not using
> these for productive development (except maybe Eric). My goal with
> gnulib is to get code written for POSIX or glibc systems compile
> fine, producing correct executables. Minimizing the verbosity of
> the build log on non-glibc platforms is not a goal for me.
>
>> +--- a/lib/unicodeio.c
>> ++++ b/lib/unicodeio.c
>> +@@ -38,6 +38,7 @@
>> +
>> + #include "localcharset.h"
>> + #include "unistr.h"
>> ++#include "ignore-value.h"
>> +
>> + /* When we pass a Unicode character to iconv(), we must pass it in a
>> +    suitable encoding. The standardized Unicode encodings are
>> +@@ -162,7 +163,7 @@ fwrite_success_callback (const char *buf, size_t 
>> buflen, void *callback_arg)
>> + {
>> +   FILE *stream = (FILE *) callback_arg;
>> +
>> +-  fwrite (buf, 1, buflen, stream);
>> ++  ignore_value (fwrite (buf, 1, buflen, stream));
>> +   return 0;
>> + }
>> +
>
> gcc's warning is formally justified here. Ignoring the return value of
> a function marked with __attribute__((__warn_unused_result__ )) warrants
> a comment. I'm adding one like this:
>
>
> 2009-10-27  Jim Meyering  <address@hidden>
>             Bruno Haible  <address@hidden>
>
>       Avoid warning despite dropping the return value of fwrite.
>       * lib/unicodeio.c: Include ignore-value.h.
>       (fwrite_success_callback): Explicitly ignore fwrite's return value.
>       * modules/unicodeio (Depends-on): Add ignore-value.

Thanks.  That's one less.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]