On 21/06/2022 09.51, Kent Overstreet wrote:
>>> struct printf_spec {
>>> @@ -2520,7 +2521,16 @@ int format_decode(const char *fmt, struct printf_spec *spec)
>>> return ++fmt - start;
>>>
>>> case 'p':
>>> - spec->type = FORMAT_TYPE_PTR;
>>> + fmt++;
>>> + if (fmt[0] == 'f' &&
>>> + fmt[1] == '(') {
>>> + fmt += 2;
>>> + spec->type = FORMAT_TYPE_FN;
>>> + } else
>>> + spec->type = FORMAT_TYPE_PTR;
>>> + return fmt - start;
>>> + case '(':
>>> + spec->type = FORMAT_TYPE_FN;
>>> return ++fmt - start;
>>
>> NAK. Don't implement something that will never be tested nor used.
>> There's not a snowball's chance in hell that we'll ever build the kernel
>> without -Wformat.
>
> We're not stopping here. Matthew is taking this to WG14 and I'll be working on
> adding this functionality to glibc next, and %() is the syntax we intend to take
> to the working group.
>
> But the working group is naturally going to want to see that a working
> implementation of it exists.
OK. But implementation in glibc, musl and/or the kernel is much much
less interesting than support in gcc and clang for accepting %( in the
first place, and preferably also for not just treating %( as a synonym
for %p but actually checking that the argument is a function pointer and
that its signature matches the arguments between (). Once _that_ has
landed in gcc 24 and the kernel requirements have been bumped to that
can we consider adding "%(" format strings (and the necessary support).
Yes, I appreciate the chicken-and-egg situation. No, I don't think the
mainline kernel is a suitable place for proof-of-concept and highly
experimental code.
Rasmus
