Peter Maydell <peter.mayd...@linaro.org> writes: > On 22 October 2015 at 10:43, Daniel P. Berrange <berra...@redhat.com> wrote: >> For reasons I don't understand, it appears that even string >> fields which are marked as optional get a 'has_XXX' flag, >> to distinguish betweeen a NULL string and an unset string. >> I struggle to imagine why we need this. It makes sense for >> integer/boolean types, but I would have thought just checking >> for NULL was sufficient for string types. > > I think the argument here is pure consistency. *Every* optional > field should be implemented as has_fieldname (bool) plus fieldname > (actual value). Special casing string types because we happen > to have a special value we can use to indicate 'no string' > seems to me like it would cause more confusion than it would > be worth.
Having a has_FOO for pointer-valued FOOs also causes confusion, because it begs questions like "does has_FOO imply FOO != NULL?" and "if !has_FOO, do I have to worry about freeing FOO?". I believe we have these has_FOOs not because someone tried to minimize confusion, but due to laziness: it was simpler to blindly generate the has_FOO for every FOO. Since I don't think distinguishing "pointer argument omitted" from "pointer argument is null" makes sense, I want the has_FOO killed for pointer FOOs. Perhaps it's even in the QAPI review queue already, which Eric keeps filling faster than I can drain it :)
