> Hi Markos, > > i think that the flag "haveListType" is not reset correctly if the element > passes from > > haveTypedValue && haveTypedTypedValue && haveListType > to > haveTypedValue && haveTypedTypedValue && !haveListType > > I would add: > else > textChild->resetHaveListValue(); > near line 499 of pul_primitives.cpp > > since if the textchild has this flag true when it has not a list type it could > cause some bad crash in > void ElementNode::getTypedValue() > > Do you agree?
Yes, done, thanks! > > I dont't think the following is an issue but just to be sure. > If a node has the flag haveTypedValue true before the apply() and false > afterwards the haveListValue/haveEmptyValue flags could still be true since > they are not reset at line 503. > I verified that the store always check haveTypedValue first and then > haveListValue/haveEmptyValue. > However a third party could use the public haveListValue()/haveEmpty... > methods directly and have incorrect results. (if he expects them to have > useful results on an untyped element) > > What do you think? I think that haveListValue/haveEmptyValue have no meaning if haveTypedValue is false. Therefore, they should not be used in this case. What do you mean by "third party"? These methods do not appear in the store api, If somebody is programming within the simple store, they shouldn't be considered a third party (either they know what they are doing, or their code is going to be reviewed by somebody who does know). -- https://code.launchpad.net/~markos-za/zorba/bugs2/+merge/78834 Your team Zorba Coders is subscribed to branch lp:zorba. -- Mailing list: https://launchpad.net/~zorba-coders Post to : zorba-coders@lists.launchpad.net Unsubscribe : https://launchpad.net/~zorba-coders More help : https://help.launchpad.net/ListHelp
