On 11/23/2016 07:45 AM, Markus Armbruster wrote: > Eric Blake <ebl...@redhat.com> writes: > >> The qobject_from_jsonf() function implements a pseudo-printf >> language for creating a QObject; however, it is hard-coded to >> only parse a subset of formats understood by printf(). In >> particular, any use of a 64-bit integer works only if the >> system's definition of PRId64 matches what the parser expects; >> which works on glibc (%lld) and mingw (%I64d), but not on >> Mac OS (%qd). Rather than enhance the parser, it is just as >> easy to open-code the few callers that were relying on this >> particular conversion. >> >> Reported by: G 3 <programmingk...@gmail.com> >> Signed-off-by: Eric Blake <ebl...@redhat.com> >> --- >> qapi/qmp-event.c | 12 +++++++----- >> 1 file changed, 7 insertions(+), 5 deletions(-)
> Commit message claims to change "the few callers", patch changes just > one. Which of the two is right? Rebase churn - there were four callers of qobject_from_jsonf() that I originally identified, then I split it up into the one caller that used %PRId64 vs. the other three that can be done differently. > > In my opinion, the code becomes less readable. > > We want to convert struct timeval members tv_sec (of type time_t) and > tv_usec (of type suseconds_t) here. Since qobject_from_jsonf() lacks > conversion specifiers for time_t and suseconds_t, we convert to int64_t > first, then use PRId64. The problem is that we don't actually implement > PRId64 everywhere. Why not simply long long and %lld? For 2.8, I can leave %lld support in qobject_from_jsonf(), and just cast to long long instead of int64_t. I'd still like to propose the series that kills all dynamic JSON for 2.9, but I don't mind posting a v2 of this series. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
