Re: [PATCH] printf: add __printf attribute

[Petr Mladek <pmladek@suse.com>]

On Mon 2025-12-08 15:30:53, Andy Shevchenko wrote:
> 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)
> 

IMHO, this is is not worth it. test_hashed(kunittest, fmt, p) calls
test(buf, fmt, p). It goes down to __test() which does the format
check:

static void __printf(6, 7)
__test(struct kunit *kunittest, const char *file, const int line, const char *expect, int elen,
	const char *fmt, ...)


> > 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).

I personally prefer this way. We just need to calm down the warning.
The proper check is done by the nested test()...

Best Regards,
Petr