On 11 April 2014 14:11, Eric Blake <ebl...@redhat.com> wrote: > 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.
I totally agree, which is why I reported this problem in the first place; but it's not 2.0 material. I have no problem with it being cc'd for stable if people want it in a 2.0.x. thanks -- PMM
