All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.