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
