Hello all...<br><br>Progress to date:<br><br>In tools/inc/tools/stream.hxx<br>Removed operator>> declarations for types long, short, int<br>Removed operator<< declarations for types long, short, int<br>Added operator>> declarations for types sal_uInt16, sal_uInt32, sal_uInt64, sal_Int16, sal_Int32, sal_Int64<br>
Added operator<< declarations for types sal_uInt16, sal_uInt32, sal_uInt64, sal_Int16, sal_Int32, sal_Int64<br><br>In tools/source/stream/stream.cxx<br>Removed operator>> definitions for types long, short, int<br>
Removed operator<< definitions for types long, short, int<br>Added operator>> definitions for types sal_uInt16, sal_uInt32, sal_uInt64, sal_Int16, sal_Int32, sal_Int64<br>Added operator<< definitions for types sal_uInt16, sal_uInt32, sal_uInt64, sal_Int16, sal_Int32, sal_Int64<br>
<br>Building tools/ results in errors from tools/inc/fract.o, tools/inc/tools/gen.o, tools/source/generic/fract.o and tools/source/generic/poly.o due to "undefined reference to SvStream::operator>>(long&)"<br>
<br>Question: Should I modify these classes to use the sal_ types?<br><br>Searching through the code (cxx files only so far), SvStream is used in 510 files.<br><br>In basic/source/sbx/sbxvalue.cxx - functions SbxValue::LoadData and SbxValue::StoreData which both have comments and workarounds for SvStream having operator>>/<< (long) defined. <br>
<br>------------------------------------------------------------------------------------------------------------------------------------<br><br>In basic/source/runtime/methods1.cxx - function:<br><br>sal_Bool lcl_WriteSbxVariable( const SbxVariable& rVar, SvStream* pStrm, sal_Bool bBinary, short nBlockLen, sal_Bool bIsArray )<br>
<br><br> case SbxSALINT64:<br> case SbxSALUINT64:<br> if( bIsVariant )<br> *pStrm << (sal_uInt16)SbxSALINT64; // VarType Id<br> *pStrm << (sal_uInt64)rVar.GetInt64();<br>
break;<br><br>BUT, in the corresponding read function:<br><br>sal_Bool lcl_ReadSbxVariable( SbxVariable& rVar, SvStream* pStrm, sal_Bool bBinary, short nBlockLen, sal_Bool bIsArray )<br><br> case SbxSALINT64:<br>
case SbxSALUINT64:<br> {<br> sal_uInt32 aInt;<br> *pStrm >> aInt;<br> rVar.PutInt64( (sal_Int64)aInt );<br> }<br> break;<br>
<br>So it serializes a sal_uInt64 but deserializes a sal_uInt32. Could this be a potential problem?<br><br>------------------------------------------------------------------------------------------------------------------------------------<br>
<br>In editeng/source/rtf/rtfgrf.cxx - function:<br><br>static void WriteBMPHeader( SvStream& rStream, const SvxRTFPictureType& rPicType )<br><br>This makes heavy use of the SWAP_LONG macro from solar.h via an inline SwapLong function while serializing sal_ types. SvStream already swaps the bytes depending on the endianness, so is this (possible) double swapping necessary?<br>
<br>------------------------------------------------------------------------------------------------------------------------------------<br><br>In the following directories, where SvStream was used, it was used with the sal_ types.<br>
connectivity/<br>cppcanvas/<br>dbaccess/<br>desktop/<br>extensions/<br>filter/<br>forms/<br>framework/<br>idl/<br>linguistics/<br>lotuswordpro/<br>sc/<br>sd/<br>sfx2/<br>slideshow/<br>sot/<br>starmath/<br>svl/<br>svtools/<br>
svx/<br>sw/<br>unotools/<br>vcl/<br>writerfilter/<br>writerperfect/<br><br>Shall I forge ahead with changing the necessary files under tools/ to make it build correctly? I can then perform a full build and see if I missed any other uses. <br>
<br>Have a good weekend everyone. :)<br><br>Kind regards<br>Keith<br>