Paolo Bonzini <pbonz...@redhat.com> writes:
>> > I kind of like the %-escapes, because they provide a compact and legible
>> > way to build QObjects. But with so little use, they're hardly earning
>> > their keep.
>>
>> What drives me most insane about them is that they are NOT the same
>> escapes as printf(), so the compiler can't help us with type safety, and
The intent was to pick conversion specifiers so that
__attribute__((format(gnu_printf, ...))) catches the type errors it can
catch. What exactly makes you think we've failed at that?
>> things like PRId64 don't always do what we want.
What would you want it to do?
Mind. we're *not* building a string from a template here, we're building
a QObject from a template. Therefore, PRId64 is for creating a QInt
holding an int64_t value.
>> And except for %p for
>> injecting nested objects, most of our escapes are just as easy to
>> perform with g_strdup_printf() (injecting a string, integer, or
>> boolean), or by manual creation of the QDict.
>
> Oh wait. Now I remember where we most used %-escapes and they're actually
> much more useful and pervasive than you estimated. See commit 563890c
> ("libqtest: escape strings in QMP commands, fix leak", 2014-07-01);
> they cannot be produced with g_strdup_printf, because %s automatically
> escapes strings.
Precisely. g_strdup_printf() is much easier to screw up than
qobject_from_jsonf() or building a QObject by hand.
> The patch actually fixed a failure in qom-test, if I'm not mistaken, due
> to a " appearing in a QOM path.
>
> However, I'm still in favor of limiting % to the testsuite.
Dunno. Let's have a look at the actual patches.
