On Sat, Dec 21, 2013 at 4:42 AM, Jeff King <peff@xxxxxxxx> wrote: > On Fri, Dec 20, 2013 at 10:45:01AM -0500, Samuel Bronson wrote: > >> These warnings don't really seem to make much sense for this file. > > Agreed, though the advice so far has been to put -Wno-format-zero-length > in your CFLAGS. Yes, auto-detecting acceptance of this flag and using it automatically might be a reasonable approach as well, but I thought this warning might potentially be useful WRT other printf-like functions. >> +/* We have good reasons for using zero-length format strings, and >> + * there's unfortunately no way to turn this off on a per-function >> + * basis ... */ >> +#pragma GCC diagnostic ignored "-Wformat-zero-length" > > Are other compilers happy to ignore this pragma? I guess we could wrap > it in an #ifdef, if so. I assume you meant we could use an #ifdef if *not*? > It's also really not about this file in particular. The whole concept of > format-zero-length is questionable, as it ignores the concept that a > format function might actually do something useful with an empty format > (e.g., by adding boilerplate, or having a side-effect). It's just that > this file is the only one that happens to do so. Hmm, I think I saw one other instance of this warning, actually, but it didn't seem worth adding the pragma to a file for just one warning. > Annotating the _function_ to say "it's useful to pass an empty format > into this function" would make sense, but as you note, there is no way > to do that. I made a note about this at <http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47901#c9> (comment #9 on "-Wall should not imply -Wformat-zero-length by default") > So I dunno. This seems like it does not quite specify what we want to > say as well as just "-Wno-format-zero-length", but it is more convenient > in practice (because we take care of it in the source code, rather than > relying on the user's build settings). Yeah. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html