[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
signature.asc
Description: OpenPGP digital signature
[Qemu-devel] [PATCH v3 05/12] tests: Clean up string interpolation into QMP input (simple cases), Eric Blake, 2017/07/25
[Qemu-devel] [PATCH v3 06/12] tests/libqos/usb: Clean up string interpolation into QMP input, Eric Blake, 2017/07/25