qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v3 01/12] qobject: Accept "%"PRId64 in qobject_f


From: Eric Blake
Subject: Re: [Qemu-devel] [PATCH v3 01/12] qobject: Accept "%"PRId64 in qobject_from_jsonf()
Date: Fri, 28 Jul 2017 13:56:36 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1

On 07/28/2017 01:13 PM, Markus Armbruster wrote:

>> Finally, update configure to barf on any libc that uses yet
>> another form of PRId64 that we have not yet coded for, so that we
>> can once again update json-lexer.c to cater to those quirks (my
>> guess? we might see %jd next) (on the bright side, json-parser.c
>> should no longer need updates).  Yes, the only way I could find
>> to quickly learn what spelling is preferred when cross-compiling
>> is to grep a compiled binary; C does not make it easy to turn a
>> string constant into an integer constant, let alone make
>> preprocessor decisions; and even parsing '$CC -E' output is
>> fragile, since 64-bit glibc pre-processes as "l" "d" rather than
>> "ld", and newer gcc splits macro expansions across multiple lines.
>> I'm assuming that 'strings' is portable enough during configure;
>> if that assumption fails in some constrained docker environment,
>> an easy hack is to add this to configure:
>>   strings () { tr -d '\0' < "$1"; }
>>

>> +# Sanity check that we can parse PRId64 and friends in json-lexer.c
>> +# (Sadly, the "easiest" way to do this is to grep the compiled binary,
>> +# since we can't control whether the preprocessor would output "ld" vs.
>> +# "l" "d", nor even portably ensure it fits output on the same line as
>> +# a witness marker.)
>> +cat > $TMPC <<EOF
>> +#include <inttypes.h>
>> +int main(void) {
>> +    static const char findme[] = "\nUnLiKeLyToClAsH_" PRId64 "\n";
>> +    return !findme[0];
>> +}
>> +EOF
>> +if ! compile_prog "$CFLAGS" "$LIBS" ; then
> 
> Would compile_object suffice?
> 

Probably.  It's one less step, although I'd have to make sure that
compile_object has a sane counterpart to compile_prog's $TMPE,...

>> +    error_exit "can't determine value of PRId64"
>> +fi
>> +nl='
>> +'
>> +case $(strings $TMPE | grep ^UnLiKeLyToClAsH) in

since we have to grep something, after all.


>> +++ b/qobject/json-lexer.c
>> @@ -29,9 +29,11 @@
>>   *
>>   * '([^\\']|\\[\"'\\/bfnrt]|\\u[0-9a-fA-F]{4})*'
>>   *
>> - * Extension for vararg handling in JSON construction:
>> + * Extension for vararg handling in JSON construction [this lexer
>> + * actually accepts multiple forms of PRId64, but parse_escape() later
>> + * filters to only parse the current platform's spelling]:
> 
> I'd stick to (parenthesis) instead of [square brackets] here.

Sure.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]