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 <meyer...@redhat.com>
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 <j...@meyering.net>
> Bruno Haible <br...@clisp.org>
>
> 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.
