qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] qapi-commands.py generates code that uses uninitialized


From: Kevin Wolf
Subject: Re: [Qemu-devel] qapi-commands.py generates code that uses uninitialized variables
Date: Tue, 15 Apr 2014 11:40:40 +0200
User-agent: Mutt/1.5.21 (2010-09-15)

Am 11.04.2014 um 15:11 hat Eric Blake geschrieben:
> On 04/11/2014 01:27 AM, Peter Maydell wrote:
> > On 11 April 2014 02:40, Eric Blake <address@hidden> wrote:
> >> We uncovered a real bug that would be fixed by this patch:
> >> https://lists.gnu.org/archive/html/qemu-devel/2014-04/msg01745.html
> > 
> > No, that's a bug in the called code. The API here defines
> > that for optional parameters, if the have_foo bool is false
> > then the foo argument isn't set. The generated code
> > can't know the correct default value (it just happens
> > to be 0 in the case you point out, but what if the default
> > speed were 100?) so this must be handled by the called
> > code.
> 
> The called code ALSO needs a fix, but guaranteeing that
> 'have_foo==false' implies 'foo==0' is MUCH nicer than 'have_foo==false'
> implies 'foo is indeterminate'.  For this particular caller, an
> indeterminate foo had detrimental effects, and a known foo==0 happened
> to be the right default.  I agree that we can't always predict the right
> default for all callers, but avoiding random behavior can be considered
> a bug fix in its own right, and if we make it part of the contract that
> callers can rely on zero initialization, we could simplify a lot of
> callers that ARE happy with a 0 default.

In fact, I would really like to see support for default values in the
schema, so that generated code can supply it. It wouldn't only mean that
the called code doesn't have to care about it any more, but it also
serves as a better API documentation.

Kevin

Attachment: pgp2A5byb8ztX.pgp
Description: PGP signature


reply via email to

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