On 04/11/2014 01:27 AM, Peter Maydell wrote: > On 11 April 2014 02:40, Eric Blake <ebl...@redhat.com> 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. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
