Message-ID: <aTSj8uKD6G0cLq2T@smile.fi.intel.com>
Date: Sat, 6 Dec 2025 23:45:22 +0200
From: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
To: Tamir Duberstein <tamird@...nel.org>
Cc: Petr Mladek <pmladek@...e.com>, Steven Rostedt <rostedt@...dmis.org>,
	Rasmus Villemoes <linux@...musvillemoes.dk>,
	Sergey Senozhatsky <senozhatsky@...omium.org>,
	Kees Cook <kees@...nel.org>, linux-kernel@...r.kernel.org,
	oe-kbuild-all@...ts.linux.dev, kernel test robot <lkp@...el.com>
Subject: Re: [PATCH] printf: add __printf attribute

On Sat, Dec 06, 2025 at 02:57:48PM -0500, Tamir Duberstein wrote:
> On Sat, Dec 6, 2025 at 2:43 PM Andy Shevchenko
> <andriy.shevchenko@...ux.intel.com> wrote:
> > On Sat, Dec 06, 2025 at 12:52:53PM -0500, Tamir Duberstein wrote:
> > > On Sat, Dec 6, 2025 at 12:49 PM Andy Shevchenko
> > > <andriy.shevchenko@...ux.intel.com> wrote:
> > > > On Sat, Dec 06, 2025 at 12:13:34PM -0500, Tamir Duberstein wrote:
> > > > > On Sat, Dec 6, 2025 at 11:11 AM Andy Shevchenko
> > > > > <andriy.shevchenko@...ux.intel.com> wrote:
> > > > > > On Sat, Dec 06, 2025 at 08:19:09AM -0500, Tamir Duberstein wrote:

...

> > > > > > > -static void
> > > > > > > +static void __printf(2, 3)
> > > > > >
> > > > > > 3?!
> > > > > >
> > > > > > I think it should be (2, 0). Yes, the both users call it with "%p..." in format
> > > > > > string, but the second parameter tells compiler to check the variadic
> > > > > > arguments, which are absent here. Changing 'const void *p' to '...' will align
> > > > > > it with the given __printf() attribute, but I don't know if this what we want.
> > > > >
> > > > > The second parameter is the first-to-check, it is not specific to
> > > > > variadic arguments. Using 0 means that no arguments are checkable, so
> > > > > the compiler only validates the format string itself and won’t
> > > > > diagnose mismatches with `p`. This works whether or not we later
> > > > > change `const void *p` to `...`.
> > > >
> > > > Yes, but this is fragile. As I explained it works only because we supply
> > > > the format string stuck to "%p", anything else will require reconsidering
> > > > the function prototypes. So, strictly speaking this should be (2, 0) if
> > > > we leave const void *p as is.
> > > >
> > > I believe this is not correct. As I said, 0 means "do not check
> > > arguments" so only the format string will be checked. See the existing
> > > uses of this annotation in this file:
> > >
> > > static void __printf(7, 0)
> > > do_test(struct kunit *kunittest, const char *file, const int line, int
> > > bufsize, const char *expect,
> > > int elen, const char *fmt, va_list ap)
> > >
> > > and
> > >
> > > static void __printf(6, 7)
> > > __test(struct kunit *kunittest, const char *file, const int line,
> > > const char *expect, int elen,
> > > const char *fmt, ...)
> > >
> > > as you can see, 0 is used only when the arguments are not in the
> > > function prototype at all. When variadic arguments are present, N+1 is
> > > used.
> >
> > Yes to all what you said. And how does it object what I said? In the case
> > you are trying to add __print(2, 3) the 3rd one is *not* a variadic argument.
> > If you make it to be variadic, I will agree with __print(2, 3). Before that
> > it doesn't look right to me even if it works.
> 
> I addressed this in my first reply; the second parameter to `__print`
> is *not* specific to variadic functions. It can just as well be used
> for functions with a fixed number of arguments.

$ make all compile_commands.json scripts_gdb ARCH=um O=.kunit --jobs=48
ERROR:root:../lib/tests/printf_kunit.c:272:1: error: ‘format’ attribute argument 3 value ‘3’ does not refer to a variable argument list
  272 | {
      | ^

How did you compile it?

The GCC documentation
https://gcc.gnu.org/onlinedocs/gcc-15.2.0/gcc/Common-Function-Attributes.html#index-format-function-attribute
doesn't clearly say if the fixed-argument functions are eligible for the
__attribute__((format)). The parameter is called first-to-check, which
might imply that there is a second.

Additionally interesting discussion to read:
https://reviews.llvm.org/D112579

Seems it's feature of clang?

3147 As an extension to GCC's behavior, Clang accepts the ``format`` attribute on
3148 non-variadic functions. Clang checks non-variadic format functions for the same
3149 classes of issues that can be found on variadic functions, as controlled by the
3150 same warning flags, except that the types of formatted arguments is forced by
3151 the function signature. For example:

Seems to me for now it has to be __printf(2, 0) or you need to put some special
pragma:s or so around the function to make it work for clang differently.

-- 
With Best Regards,
Andy Shevchenko

Powered by blists - more mailing lists