Re: error.c triggers -Wformat-extra-args

[Eric Blake]

On 06/25/2014 12:08 PM, Daniel E. Macks wrote:
> Building gettext-0.19.1, which embeds copies of gnulib, on OS X 10.8,
> which uses the clang compiler (via XCode-5.1), gives:
> 
> clang -DHAVE_CONFIG_H -DEXEEXT=\"\" -I. -I..  -I../intl -I../intl 
> -DDEPENDS_ON_LIBICONV=1 -DDEPENDS_ON_LIBINTL=1  -I/sw/include  -Os -c -o 
> error.o error.c
> error.c:381:12: warning: data argument not used by format string 
> [-Wformat-extra-args]
>            file_name, line_number);
>            ^

Thanks for the report.  In the past, we've been reluctant to silence
warnings like this when the code is closely copied from glibc, unless
the glibc version gets patched first.  Our recommendation has been to
not enable as many warnings for gnulib as what you enable for the rest
of your project, precisely because gnulib is used among more projects
with differing styles where we cannot possibly be warning-free for all
those styles.  Coreutils is a good example of a project that uses fewer
warnings on gnulib than on its own code.

> whole alternative fprintf() with appropriate parameters in a
> conditional if/else block rather than just conditional on the
> format-string. Something like:
> 
>   if (file_name != NULL)
>     fprintf (stderr, "%s:%d: ", file_name, line_number)
>   else
>     fprintf (stderr, " ");
> 

Yes, that would work at avoiding the warning, but then you'd have to
duplicate the code for the glibc __fxprintf case, and double the code
becomes a maintenance nightmare.  If you can convince glibc to clean up
their copy first, I don't mind following suit, but for now, I'd rather
not change this in gnulib.  As the code is functionally correct, making
it more verbose and repetitive merely to shut up a compiler warning is
extra work for not much gain.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature