| Message ID | 20250320180926.4002817-6-andriy.shevchenko@linux.intel.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | vsprintf: Add __printf attribute to where it's required | expand |
On Thu, Mar 20 2025, Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote: > pointer() is using printf() type of format, and GCC compiler > (Debian 14.2.0-17) is not happy about this: > > lib/vsprintf.c:2466:17: error: function ‘pointer’ might be a candidate for ‘gnu_printf’ format attribute [-Werror=suggest-attribute=format] > > Fix the compilation errors (`make W=1` when CONFIG_WERROR=y, which is default) > by adding __printf() attribute. > I had quite a bit of trouble reproducing, until I realized I had to apply your patches in reverse order, because adding the attribute to one function will then "taint" its callers. So this one seems to be self-inflicted pain by the annotation of va_format (which is completely broken, I'll reply separately to that one). This doesn't solve the false warning for va_format(), but how about we at least do static char *va_format(char *buf, char *end, struct va_format *va_fmt, - struct printf_spec spec, const char *fmt) + struct printf_spec spec) { case 'V': - return va_format(buf, end, ptr, spec, fmt); + return va_format(buf, end, ptr, spec); case 'K': because va_format() doesn't use that fmt argument at all. Rasmus
On Fri, Mar 21, 2025 at 02:43:18PM +0100, Rasmus Villemoes wrote: > On Thu, Mar 20 2025, Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote: > > pointer() is using printf() type of format, and GCC compiler > > (Debian 14.2.0-17) is not happy about this: > > > > lib/vsprintf.c:2466:17: error: function ‘pointer’ might be a candidate for ‘gnu_printf’ format attribute [-Werror=suggest-attribute=format] > > > > Fix the compilation errors (`make W=1` when CONFIG_WERROR=y, which is default) > > by adding __printf() attribute. > > > > I had quite a bit of trouble reproducing, until I realized I had to > apply your patches in reverse order, because adding the attribute to one > function will then "taint" its callers. Exactly, that's why cover letter has "strict order" mention. > So this one seems to be self-inflicted pain by the annotation of > va_format (which is completely broken, I'll reply separately to that > one). This doesn't solve the false warning for va_format(), but how > about we at least do > > static char *va_format(char *buf, char *end, struct va_format *va_fmt, > - struct printf_spec spec, const char *fmt) > + struct printf_spec spec) > { > > case 'V': > - return va_format(buf, end, ptr, spec, fmt); > + return va_format(buf, end, ptr, spec); > case 'K': > > because va_format() doesn't use that fmt argument at all. Yes, I was thinking about this. I'll do it in a separate patch in v2.
diff --git a/lib/vsprintf.c b/lib/vsprintf.c index 56fe96319292..8ebb5f866b08 100644 --- a/lib/vsprintf.c +++ b/lib/vsprintf.c @@ -2419,7 +2419,7 @@ char *rust_fmt_argument(char *buf, char *end, void *ptr); * from Rust code to format core::fmt::Arguments. Do *not* use it from C. * See rust/kernel/print.rs for details. */ -static noinline_for_stack +static noinline_for_stack __printf(1, 0) char *pointer(const char *fmt, char *buf, char *end, void *ptr, struct printf_spec spec) {
pointer() is using printf() type of format, and GCC compiler (Debian 14.2.0-17) is not happy about this: lib/vsprintf.c:2466:17: error: function ‘pointer’ might be a candidate for ‘gnu_printf’ format attribute [-Werror=suggest-attribute=format] Fix the compilation errors (`make W=1` when CONFIG_WERROR=y, which is default) by adding __printf() attribute. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> --- lib/vsprintf.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)