qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Luiz Capitulino <lcapitulino@redhat.com>
To: Markus Armbruster <armbru@redhat.com>
Cc: aliguori@us.ibm.com, qemu-devel@nongnu.org, avi@redhat.com
Subject: Re: [Qemu-devel] [PATCH 1/3] qemu-char: Introduce Memory driver
Date: Fri, 12 Nov 2010 14:54:05 -0200	[thread overview]
Message-ID: <20101112145405.6c155f26@doriath> (raw)
In-Reply-To: <m3y68yedc7.fsf@blackfin.pond.sub.org>

On Fri, 12 Nov 2010 17:06:16 +0100
Markus Armbruster <armbru@redhat.com> wrote:

> Luiz Capitulino <lcapitulino@redhat.com> writes:
> 
> > On Fri, 12 Nov 2010 16:04:39 +0100
> > Markus Armbruster <armbru@redhat.com> wrote:
> >
> >> Luiz Capitulino <lcapitulino@redhat.com> writes:
> >> 
> >> > On Fri, 12 Nov 2010 15:16:33 +0100
> >> > Markus Armbruster <armbru@redhat.com> wrote:
> >> >
> >> >> Luiz Capitulino <lcapitulino@redhat.com> writes:
> >> >> 
> >> >> > On Fri, 12 Nov 2010 11:21:57 +0100
> >> >> > Markus Armbruster <armbru@redhat.com> wrote:
> >> >> >
> >> >> >> Luiz Capitulino <lcapitulino@redhat.com> writes:
> >> >> [...]
> >> >> >> > +QString *qemu_chr_mem_to_qs(CharDriverState *chr)
> >> >> >> > +{
> >> >> >> > +    MemoryDriver *d = chr->opaque;
> >> >> >> > +
> >> >> >> > +    if (d->outbuf_size == 0) {
> >> >> >> > +        return qstring_new();
> >> >> >> > +    }
> >> >> >> 
> >> >> >> Why is this necessary?  Is qstring_from_substr() broken for empty
> >> >> >> substrings?  If it is, it ought to be fixed!
> >> >> >
> >> >> > qstring_from_substr() takes a character range; outbuf_size stores a size,
> >> >> > not a string length. So we do:
> >> >> >
> >> >> >> > +    return qstring_from_substr((char *) d->outbuf, 0, d->outbuf_size - 1);
> >> >> >
> >> >> > If outbuf_size is 0, we'll be passing a negative value down.
> >> >> 
> >> >> What's wrong with that?
> >> >
> >> > Although it's going to work with the current QString implementation, I don't
> >> > think it's it's a good idea to rely on a negative index.
> >> 
> >> How should I extract the substring of S beginning at index B with length
> >> L?  If I cant't do this for any B, L with interval [B,B+L-1] fully
> >> within [0,length(S)], then the API is flawed, and ought to be replaced.
> >
> > Not sure we're talking about the same problem, anymore. When you said:
> >
> >> >> What's wrong with that?
> >
> > What did you mean? Did you mean 'let's not decrement outbuf_size' or did
> > you mean 'let's pass -1 anyway'?
> 
> Yes, what's wrong with qstring_from_substr(S, 0, -1)?
> 
> Its function comment is imprecise, it doesn't tell us whether the END-th
> character is included in the substring or not.
> 
> The code, however, is clear enough: it *is* included.  And the unit test
> checks that.
> 
> Therefore, qstring_from_substr("abc", 0, 0) returns the qstring "a".
> 
> > Both seem wrong to me: the substring [0,-1] should be invalid
> 
> Why?
> 
> How do you express "the empty substring starting at 0" then?

I didn't consider that when I wrote the code, so it's a matter a defining
the behavior we want it to have.


> 
> >                                                               and not
> > decrementing outbuf_size is wrong, because it contains the buffer size and
> > qstring_from_substr() will consume an additional char from the buffer (which
> > should be '\0' today, but we shouldn't count on that).
> >
> >> 
> >> > Maybe, we could have:
> >> >
> >> > return qstring_from_substr((char *) d->outbuf, 0,
> >> >                             d->outbuf_size > 0 ? d->outbuf_size - 1 : 0);
> >> >
> >> > A bit harder to read, but makes the function smaller.
> >> 
> >> Err, doesn't qstring_from_substr(s, 0, 0) extract a substring of length
> >> 1?
> >
> > Yeah, it's a bug. But that doesn't change my suggestion, can we do this way?
> >
> > This should fix the bug (not even compiled tested):
> >
> > diff --git a/qstring.c b/qstring.c
> > index 4e2ba08..72a25de 100644
> > --- a/qstring.c
> > +++ b/qstring.c
> > @@ -42,10 +42,10 @@ QString *qstring_from_substr(const char *str, int start, int end)
> >  
> >      qstring = qemu_malloc(sizeof(*qstring));
> >  
> > -    qstring->length = end - start + 1;
> > -    qstring->capacity = qstring->length;
> > +    qstring->length = end - start;
> > +    qstring->capacity = qstring->length + 1;
> >  
> > -    qstring->string = qemu_malloc(qstring->capacity + 1);
> > +    qstring->string = qemu_malloc(qstring->capacity);
> >      memcpy(qstring->string, str + start, qstring->length);
> >      qstring->string[qstring->length] = 0;
> 
> I suspect this will fail your unit test.

Haven't checked it yet, but maybe it has to be fixed too.

  reply	other threads:[~2010-11-12 16:54 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-11 19:31 [Qemu-devel] [PATCH v3 0/3]: QMP: Human Monitor passthrough Luiz Capitulino
2010-11-11 19:31 ` [Qemu-devel] [PATCH 1/3] qemu-char: Introduce Memory driver Luiz Capitulino
2010-11-12 10:21   ` Markus Armbruster
2010-11-12 13:57     ` Luiz Capitulino
2010-11-12 14:16       ` Markus Armbruster
2010-11-12 14:49         ` Luiz Capitulino
2010-11-12 15:04           ` Markus Armbruster
2010-11-12 15:40             ` Luiz Capitulino
2010-11-12 16:06               ` Markus Armbruster
2010-11-12 16:54                 ` Luiz Capitulino [this message]
2010-11-11 19:31 ` [Qemu-devel] [PATCH 2/3] QMP: Introduce Human Monitor passthrough command Luiz Capitulino
2010-11-11 19:31 ` [Qemu-devel] [PATCH 3/3] QMP/qmp-shell: Introduce HMP mode Luiz Capitulino
  -- strict thread matches above, loose matches on Subject: below --
2010-11-16 19:19 [Qemu-devel] [PATCH v4 0/3]: QMP: Human Monitor passthrough Luiz Capitulino
2010-11-16 19:19 ` [Qemu-devel] [PATCH 1/3] qemu-char: Introduce Memory driver Luiz Capitulino
2010-11-10 18:59 [Qemu-devel] [PATCH v2 0/3]: QMP: Human Monitor passthrough Luiz Capitulino
2010-11-10 18:59 ` [Qemu-devel] [PATCH 1/3] qemu-char: Introduce Memory driver Luiz Capitulino
2010-11-11 15:30   ` Markus Armbruster
2010-11-11 15:48     ` Luiz Capitulino
2010-11-11 16:32       ` Markus Armbruster
2010-11-11 18:44         ` Luiz Capitulino
2010-11-12 10:16           ` Markus Armbruster
2010-11-12 13:52             ` Luiz Capitulino
2010-11-12 15:54               ` Markus Armbruster
2010-11-12 16:28                 ` Luiz Capitulino

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20101112145405.6c155f26@doriath \
    --to=lcapitulino@redhat.com \
    --cc=aliguori@us.ibm.com \
    --cc=armbru@redhat.com \
    --cc=avi@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).