Re: [PATCH v4 05/34] vsprintf: %pf(%p)

[Rasmus Villemoes <linux@rasmusvillemoes.dk>]

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