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
