[Libreoffice] Bug 39428 (https://bugs.freedesktop.org/show_bug.cgi?id=39428#c1)

[Keith McRae]

Hello all...

Progress to date:

In tools/inc/tools/stream.hxx
Removed operator>> declarations for types long, short, int
Removed operator<< declarations for types long, short, int
Added operator>> declarations for types sal_uInt16, sal_uInt32, sal_uInt64,
sal_Int16, sal_Int32, sal_Int64
Added operator<< declarations for types sal_uInt16, sal_uInt32, sal_uInt64,
sal_Int16, sal_Int32, sal_Int64

In tools/source/stream/stream.cxx
Removed operator>> definitions for types long, short, int
Removed operator<< definitions for types long, short, int
Added operator>> definitions for types sal_uInt16, sal_uInt32, sal_uInt64,
sal_Int16, sal_Int32, sal_Int64
Added operator<< definitions for types sal_uInt16, sal_uInt32, sal_uInt64,
sal_Int16, sal_Int32, sal_Int64

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&)"

Question: Should I modify these classes to use the sal_ types?

Searching through the code (cxx files only so far), SvStream is used in 510
files.

In basic/source/sbx/sbxvalue.cxx - functions SbxValue::LoadData and
SbxValue::StoreData which both have comments and workarounds for SvStream
having operator>>/<< (long) defined.

------------------------------------------------------------------------------------------------------------------------------------

In basic/source/runtime/methods1.cxx - function:

sal_Bool lcl_WriteSbxVariable( const SbxVariable& rVar, SvStream* pStrm,
sal_Bool bBinary, short nBlockLen, sal_Bool bIsArray )


        case SbxSALINT64:
        case SbxSALUINT64:
                if( bIsVariant )
                    *pStrm << (sal_uInt16)SbxSALINT64; // VarType Id
                *pStrm << (sal_uInt64)rVar.GetInt64();
                break;

BUT, in the corresponding read function:

sal_Bool lcl_ReadSbxVariable( SbxVariable& rVar, SvStream* pStrm, sal_Bool
bBinary, short nBlockLen, sal_Bool bIsArray )

        case SbxSALINT64:
        case SbxSALUINT64:
                {
                sal_uInt32 aInt;
                *pStrm >> aInt;
                rVar.PutInt64( (sal_Int64)aInt );
                }
                break;

So it serializes a sal_uInt64 but deserializes a sal_uInt32. Could this be
a potential problem?

------------------------------------------------------------------------------------------------------------------------------------

In editeng/source/rtf/rtfgrf.cxx - function:

static void WriteBMPHeader( SvStream& rStream, const SvxRTFPictureType&
rPicType )

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?

------------------------------------------------------------------------------------------------------------------------------------

In the following directories, where SvStream was used, it was used with the
sal_ types.
connectivity/
cppcanvas/
dbaccess/
desktop/
extensions/
filter/
forms/
framework/
idl/
linguistics/
lotuswordpro/
sc/
sd/
sfx2/
slideshow/
sot/
starmath/
svl/
svtools/
svx/
sw/
unotools/
vcl/
writerfilter/
writerperfect/

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.

Have a good weekend everyone. :)

Kind regards
Keith
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/libreoffice/attachments/20120106/ecd58589/attachment.htm>