Review: Needs Information

Hi Markos,

i think that the flag "haveListType" is not reset correctly if the element 
passes from

haveTypedValue && haveTypedTypedValue && haveListType
haveTypedValue && haveTypedTypedValue && !haveListType

I would add:
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?

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 
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?
Your team Zorba Coders is subscribed to branch lp:zorba.

Mailing list:
Post to     :
Unsubscribe :
More help   :

Reply via email to