Re: [Xen-devel] [PATCH v4 17/32] libxl_qmp: Parse JSON input from QMP

[Roger Pau Monné <roger.pau@xxxxxxxxxx>]

On Fri, Aug 03, 2018 at 04:33:31PM +0100, Anthony PERARD wrote:
> On Thu, Aug 02, 2018 at 12:25:53PM +0200, Roger Pau Monné wrote:
> > On Fri, Jul 27, 2018 at 03:05:59PM +0100, Anthony PERARD wrote:
> > > +    /* workaround strstr limitation */
> > > +    ev->rx_buf[ev->buf_used] = '\0';
> > 
> > Why not use strnstr to limit the size of the rx_buf that's searched? I
> > think that would allow you to get rid of the '-1' that you have to
> > take into account in several places?
> 
> Because that's a FreeBSD API, at least on my machine (Arch Linux), to
> attempt to use it, I will need to install a new package, libbsd. So I
> don't think strnstr was an option.

Oh, that's a shame. It would make the code easier IMO.

> > > +
> > > +    /*
> > > +     * Search for the end of a QMP message: "\r\n" in the newly received
> > > +     * bytes + the last byte on the previous read() if any
> > > +     *
> > > +     * end: This will point to the byte right after \r\n
> > > +     */
> > > +    end = strstr(ev->rx_buf + ev->buf_used - r
> > > +                 + (ev->buf_used - r == 0 ? 0 : -1),
> > > +                 "\r\n");
> > > +    if (end)
> > > +        end += 2;
> > > +
> > > +    while (end) {
> > > +        libxl__json_object *o;
> > > +        size_t len;
> > > +        char *s;
> > > +
> > > +        /* Start parsing from s */
> > > +        s = ev->rx_buf + ev->buf_consumed;
> > > +        /* Findout how much can be parsed */
> > > +        len = end - s;
> > 
> > You can init both s and len above when defining them.
> 
> Would not that looks a bit weird?
> 
> +    while (end) {
> +        libxl__json_object *o;
> +        /* Start parsing from s */
> +        char *s = ev->rx_buf + ev->buf_consumed;
> +        /* Findout how much can be parsed */
> +        size_t len = end - s;
> 
> But that can be done.

I have a tendency to try to init as much as possible at definition
time in order to make the code shorter, but that's my preference.
There's no rule in coding style that mandates that AFAIK.

Roger.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel