Messages in this thread | | | Date | Tue, 21 Jun 2022 10:47:23 +0200 | Subject | Re: [PATCH v4 05/34] vsprintf: %pf(%p) | From | Rasmus Villemoes <> |
| |
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
| |