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

Re: [Xen-devel] [PATCH v6 08/11] libxl: QEMU startup sync based on QMP

Anthony PERARD writes ("Re: [PATCH v6 08/11] libxl: QEMU startup sync based on 
> On Wed, Nov 21, 2018 at 04:49:06PM +0000, Anthony PERARD wrote:
> > I wounder what to do for this.
> > Maybe invent a JSON macro which would be:
> >     JSON(o) (libxl__json_object_to_json(gc, (o)) : ? "\"null\"")
> >     ("null" would actually be valid json)
> > Or do it without the macro, but there are plenty of other caller's of
> > libxl__json_object_to_json in libxl__ev_qmp implementation.
> Or simply change libxl__json_object_to_json to always return a valid
> json string. There are no user yet, so it is probably fine to make that
> change.

I very much like your suggestion that there should be some simple
thing that always returns something suitable for printing in an error

I'm not sure whether that thing should be libxl__json_object_to_json.
I don't like the idea that libxl__json_object_to_json should be able
to fail undetectably.

Nor do I like the idea that failures should be represented by a valid
parseable json string.

So I tentatively suggest either

  const char libxl__json_object_to_json_error[] = "<invalid-json-object>";

returning libxl__json_object_to_json_error on error, or

  #define JSON(o) (libxl__json_object_to_json(gc, (o)) \
                   : ? "<invalid-json-object>")

or some such.  I can't remember enough JS right now to be sure whether
`<invalid-json-object>' is a parse error but both json_pp and nodejs
seem to hate it well enough...


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.