On 7 March 2017 at 07:20, Markus Armbruster <arm...@redhat.com> wrote:
> Actually, the command line option is the least part of this series.
> Its bulk is about building infrastructure and getting errors out of
> the JSON parser.
>
> The design of the command line interface was discussed here:
> Subject: Non-flat command line option argument syntax
> Message-ID: <87bmukmlau....@dusky.pond.sub.org>
> https://lists.gnu.org/archive/html/qemu-devel/2017-02/msg00555.html
>
> v3: A few commit messages touched up, code unchanged
>
> The following changes since commit fbddc2e5608eb655493253d080598375db61a748:
>
> Merge remote-tracking branch 'remotes/armbru/tags/pull-qapi-2017-02-28'
> into staging (2017-03-06 10:18:33 +0000)
>
> are available in the git repository at:
>
> git://repo.or.cz/qemu/armbru.git tags/pull-block-2017-02-28-v3
>
> for you to fetch changes up to de479f01438d974100ac9ec10ab82c2ee1ad124f:
>
> keyval: Support lists (2017-03-07 08:15:18 +0100)
The clang sanitizer has a complaint about your new test:
GTESTER tests/test-keyval
/home/petmay01/linaro/qemu-for-merges/util/keyval.c:129:15: runtime
error: member access within null pointer of type 'QString' (aka
'struct QString')
which is the line:
new = QOBJECT(value) ?: QOBJECT(qdict_new());
This is because QOBJECT is defined as:
#define QOBJECT(obj) (&(obj)->base)
and so it doesn't have the "if you pass in NULL you get NULL"
semantics that OBJECT() and all the QOM object typecast
macros do.
(As an aside, it's rather confusing to have a QObject
whose header claims it's part of the "QEMU Object Model"
which is completely different from the QOM Object...)
thanks
-- PMM
