Hello Michael, On Thu, 2011-02-10 at 12:33 +0000, Michael Meeks wrote: > So - I think this is way too big to ship between 3.3.1 RC1 and our > final release of that; so - I'd say no for 3.3.1. I'd say yes for 3.3 > (and hence 3.3.2) but I have a few questions:
Ok. > When writing we do this: > > - SwWW8Writer::WriteString_xstz( *pDataStrm, ffdeftext, true ); > + if ( !type ) > + SwWW8Writer::WriteString_xstz( *pDataStrm, ffdeftext, true ); This is not in the same file than the code below ;) one is for export and the other for import. The first one is the necessary one :D > - pDataStream->SeekRel(4 * (nType ? 2 : 1)); > + String sEntryMacro = WW8Read_xstz(*pDataStream, 0, true); > + String sExitMacro = WW8Read_xstz(*pDataStream, 0, true); > + //pDataStream->SeekRel(4 * (nType ? 2 : 1)); > > That concerns me - we unconditionally read and advance the stream > pointer here presumably by 8 bytes, rather than dependent on nType by > either 4 or 8 (or some multiple thereof). Are we missing an if (nType) > branch here ? and do we have a document that tests the other case ? Well, nType should be replace by a boolean as we only set it to 0 or 1. If you meant type... then the word specs says that if the FFData.bits.iType needs to be 0 for this value to be stored. http://msdn.microsoft.com/en-us/library/dd906422%28v=office.12%29.aspx > incidentally commenting out code instead of removing it is ... > curious :-) Oops, that's a code cleanup thing I forgot to do. The whole ww8par3.cxx changed should be completely removed as we can't use those macros names ATM. I did that for some testing purpose and forgot to clean it up. Regards, -- Cédric Bosdonnat LibreOffice hacker http://documentfoundation.org OOo Eclipse Integration developer http://cedric.bosdonnat.free.fr _______________________________________________ LibreOffice mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/libreoffice
