Re: [PATCH] printf: add __printf attribute

[Petr Mladek <pmladek@suse.com>]

On Thu 2026-01-15 09:53:37, Tamir Duberstein wrote:
> On Tue, Dec 16, 2025 at 5:13 AM Petr Mladek <pmladek@suse.com> wrote:
> >
> > On Mon 2025-12-08 16:07:28, Tamir Duberstein wrote:
> > > On Mon, Dec 8, 2025 at 9:06 AM Petr Mladek <pmladek@suse.com> wrote:
> > > >
> > > > 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, ...)
> > > > > > >
> > > > > > 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()...
> > >
> > > The nested `__test()` call cannot do the proper check because it cannot
> > > see the format string. Right?
> >
> > IMHO, it does see the format string. It is defined the following way:
> >
> > static void __printf(6, 7)
> > __test(struct kunit *kunittest, const char *file, const int line, const char *expect, int elen,
> >         const char *fmt, ...)
> >
> > #define test(expect, fmt, ...)                                  \
> >         __test(kunittest, __FILE__, __LINE__, expect, strlen(expect), fmt, ##__VA_ARGS__)
> >
> > static void
> > test_hashed(struct kunit *kunittest, const char *fmt, const void *p)
> > {
> >         char buf[PLAIN_BUF_SIZE];
> >
> >         plain_hash_to_buffer(kunittest, p, buf, PLAIN_BUF_SIZE);
> >
> >         test(buf, fmt, p);
> > }
> >
> >
> > Now, let's get for example:
> >
> >         test_hashed(kunittest, "%p", PTR_INVALID);
> >
> > it calls:
> >
> >         test(buf, "%p", PTR_INVALID);
> >
> > which is exapnded to:
> >
> >         __test(kunittest, file, line, buf, strlen(buf), "%p", PTR_INVALID)
> >
> > so, it gets the same printf arguments as the original test_hashed,
> > namely:
> >
> >         %p, PTR_INVALID
> >
> > Or do I miss anything, please?
> 
> the problem is that test_hashed is a function, not a macro, so it is
> not correct to say that
> 
> test_hashed(kunittest, "%p", PTR_INVALID)
> 
> is expanded to
> 
> __test(kunittest, file, line, buf, strlen(buf), "%p", PTR_INVALID)
> 
> thus the compiler cannot perform any meaningful checking of the
> test_hashed call.
> 
> We could make test_hashed a macro, though.

I am sorry but I still think that it is not worth it.
The proposed changes add more complexity or weird stuff for a little gain.

> > You might argue that it works by chance and that it might change in the
> > future. But I have hard times to imagine it. test_hashed() is just
> > a wrapper around "test()". The only purpose is to fill "buf" with
> > the expected outcome.
> >
> > If any refactoring is needed in the future. The __printf() macros
> > would need some refactoring as well.

IMHO, the above is still valid.

> Apologies for taking a month to reply here.

No problem at all.

Best Regards,
Petr