qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 00/16] introduce OptsVisitor, rebase -net/-netde


From: Michael Roth
Subject: Re: [Qemu-devel] [PATCH 00/16] introduce OptsVisitor, rebase -net/-netdev parsing
Date: Wed, 6 Jun 2012 15:09:07 -0500
User-agent: Mutt/1.5.21 (2010-09-15)

On Wed, Jun 06, 2012 at 06:49:19PM +0200, Laszlo Ersek wrote:
> On 06/06/12 18:14, Michael Roth wrote:
> > On Wed, Jun 06, 2012 at 05:30:03PM +0200, Laszlo Ersek wrote:
> 
> >>   value < 0
> > 
> > I think this last one will cause problems though, since uint64_t's
> > within the valid range for visit_type_uint64() will fail due to being
> > interpreted as < 0 when cast to int64_t. With the others we can detect
> > these cases since the max unsigned value doesn't exceed the max signed
> > value of the intermediate type we're storing to.
> 
> The fallback (*v->type_int)() call stores an int64_t, according to its
> prototype ("interface contract"). IMHO it shouldn't try to communicate a
> mathematical value outside of [INT64_MIN, INT64_MAX]; it should report

But the contract with visit_type_int() is maintained: it's just that
visit_type_uint64() is casting it's uint64_t value to int64_t (and
back) to make use of the fallback. It's slightly dirty, but fairly common
throughout the tree.

> an error in this case. If a visitor genuinely wants to parse and store
> 2^63 for example, it should implement the "type_uint64" interface.

This doesn't buy us much, since ultimately that type_uint64 interface is
just gonna, in the case of QMP*Visitor anyway, end up casting back/forth
between a int64_t anyway so we can stick it into a QObject as a Qint.

So really we end up doing the same thing as before, except we do it in
more places.

> 
> Anyway I've been called "inflexible" before. I can send a v2 if you wish.

Your offer to send a v2 suggests otherwise :)

> 
> Thanks,
> Laszlo
> 



reply via email to

[Prev in Thread] Current Thread [Next in Thread]