Re: [PATCH] printf: add __printf attribute

[Andy Shevchenko <andriy.shevchenko@linux.intel.com>]

On Sun, Dec 07, 2025 at 08:32:53PM -0500, Tamir Duberstein wrote:
> On Sat, Dec 6, 2025 at 4:45 PM Andy Shevchenko
> <andriy.shevchenko@linux.intel.com> wrote:
> > 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@linux.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@linux.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@linux.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.
> 
> Ah, thanks for digging that up - and as confirmed by LKP you are right
> of course.
> 
> Since it doesn't make much sense to make this function variadic, I
> think the best we can do is a macro wrapper that combines this
> function with `no_printk`. Something like
> 
> #define test_hashed(kunittest, fmt, p) \
> do { \
> if (0) \
> no_printk(fmt, p); \
> __test_hashed(kunittest, fmt, p);\
> } while (0)

I am not sure about a macro approach.

> That would give us better diagnostics, but is more complex (and more
> lines of code than just repeating this function's body twice, which
> would also give good diagnostics). I think the best thing to do is just
> to ignore the report that prompted me to look into this. Please let me
> know if you disagree.

I think we may not ignore the report as it breaks builds in some cases.
As I said

- __printf(2, 0) for now

- and perhaps a comment on top to explain the clang approach that may cope
with fixed-argument functions for -Wformat (you can even put a link to that
LLVM discussion about the feature).

-- 
With Best Regards,
Andy Shevchenko