Eric Blake <ebl...@redhat.com> writes:
> On 11/25/2015 02:23 PM, Markus Armbruster wrote:
>> Signed-off-by: Markus Armbruster <arm...@redhat.com>
>> ---
>> qobject/json-parser.c | 32 +++++++++++++++-----------------
>> 1 file changed, 15 insertions(+), 17 deletions(-)
>>
>
>> + if (!strcmp(val, "%p")) {
>> obj = va_arg(*ap, QObject *);
>> - } else if (token_is_escape(token, "%i")) {
>> + } else if (!strcmp(val, "%i")) {
>> obj = QOBJECT(qbool_from_bool(va_arg(*ap, int)));
>> - } else if (token_is_escape(token, "%d")) {
>> + } else if (!strcmp(val, "%d")) {
>> obj = QOBJECT(qint_from_int(va_arg(*ap, int)));
>> - } else if (token_is_escape(token, "%ld")) {
>> + } else if (!strcmp(val, "%ld")) {
>
> Not for this patch, but I'd love to kill our support for "%ld" - it has
> behavior that differs between 32-bit and 64-bit platforms, and is
> therefore useless for our goal of using fixed-width integer types.
>
>> obj = QOBJECT(qint_from_int(va_arg(*ap, long)));
>> - } else if (token_is_escape(token, "%lld") ||
>> - token_is_escape(token, "%I64d")) {
>> + } else if (!strcmp(val, "%lld") ||
>> + !strcmp(val, "%I64d")) {
>
> Not for this patch, but I'd love to kill our support for "%I64d". Isn't
> modern mingw friendlier to using POSIX escape sequences in printf()?
> I'm assuming mingw is the only reason we have this hold-out?
These escapes are chosen so we can get type checking from gcc via format
attribute. The code here is somewhat unclean; it should arguably
compare to "%" PRId64, whatever that may be. Instead, we accept
anything we anticipate it could be.
> Reviewed-by: Eric Blake <ebl...@redhat.com>
Thanks!
