Date: prev next · Thread: first prev next last
2012 Archives by date, by thread · List index


On 01/06/2012 06:08 PM, Keith McRae wrote:
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?

You can either use a temporary sal_Int32 variable for just the operator >> call and leave the surrounding code using long, or you can go the extra mile of making the surrounding code use sal_Int32, too. But note that this can quickly grow into a large additional task that you would probably not want to mix with the task at hand. So, in all but trivial cases it might be best to go with the first option, potentially adding a comment to why such a temporary variable is needed (which can be removed again when the surrounding code is eventually cleaned up).

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

Those workarounds for SbxSALINT64 can be removed then, directly operating on the nInt64 member instead.

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?

This indeed looks like a bug.

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?

This also does not look right. --- Unless the BMP shall be in platform byte-order, in which case the additional swap on big-endian would cancel out with SvStream's internal swap. But <http://en.wikipedia.org/wiki/BMP_file_format> states that BMP uses little-endian, so this is probably indeed a bug (and exporting RTF bitmaps has never been tested with Solaris SPARC OOo...).

Thanks a lot for this in-depth work. Let us know if you find any other obstacles.

Stephan

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.