it is not valid to use (type & ND_TEXTNODE) before casting to SwTxtNode,
type of SwCntntNode has the ND_TEXTNODE bit as well, but SwCntntNode is not
derived from SwTxtNode.
>>= operator overload turn the right-value of the operator into a
left value... which confuse the heck out of the compiler's detection
of use of unitialized variables (and also C-reader like me for
whom >>= means something else altogether...
(why on earth are we right-bitshifting... with an unitialized variable...
oh! fracking operator overload!!!)
It's simply a bunch of documents with various math features in them.
It'd be nice to have an automated test built on top of them that
checks the formula is the same (roughly, in the meaning, it can't be
precise because import adds e.g. extra {}'s) after an export+import
roundtrip.
Generalized the OSX ppc workaround for ancient bison versions,
factored out for all gcc platforms. Put bison version detection
into configure accordingly, to switch on that, and not on platform.
Otherwise we would fail to import the cell contents of those documents
that don't include table styles at all. Some hand-crafted ods documents
don't provide table styles, which 3.4 imported just fine.
Older releases stored a few function names not defined by ODFF, namely
EASTERSUNDAY instead of ORG.OPENOFFICE.EASTERSUNDAY, TDIST instead of
LEGACY.TDIST and B instead of BINOM.DIST.RANGE.
Since OOo/LibO 3.3 the proper function names can be read, additionally to the
"wrong" names. Now it's time to write the proper names and still accept the
incorrect ones.
Test cases are attached to AOOo issues:
ORG.OPENOFFICE.EASTERSUNDAY
https://issues.apache.org/ooo/show_bug.cgi?id=112882
LEGACY.TDIST and BINOM.DIST.RANGE
https://issues.apache.org/ooo/show_bug.cgi?id=110229
Note that the FALSE in A2 and A3 is a result of the string comparison of the
actual formula, that differs in separators (, vs ;) only.
(cherry picked from commit a9b03bd199)
