[Libreoffice-commits] core.git: 2 commits - vcl/source

[Michael Stahl]

 vcl/source/gdi/metaact.cxx    |    4 ++--
 vcl/source/gdi/regionband.cxx |   16 ++++++++--------
 2 files changed, 10 insertions(+), 10 deletions(-)

New commits:
commit 9bd0a976017fadf4344cbf6746abd395dfcc3cb7
Author: Michael Stahl <mstahl at redhat.com>
Date:   Sun Jun 30 00:16:59 2013 +0200

    fdo#66288: fix RegionBand (de)serialization
    
    Commit e717d1dcce7f8906311c5ccdbb2326b61a702630 interacts badly with
    commit 7b2a0e541567be9750dfc7d98374555967da3470:
    the newly added "long" variables serialized to SvStream with
    operator>>/<< now read/write 8 bytes.
    
    Using "long" for binary serialized integers is an idiotic idea in the
    first place.
    
    Change-Id: I9432c1bb2c339e797c064371f2cbdcfec2200994

diff --git a/vcl/source/gdi/regionband.cxx b/vcl/source/gdi/regionband.cxx
index 1a4d249..4268e0f 100644
--- a/vcl/source/gdi/regionband.cxx
+++ b/vcl/source/gdi/regionband.cxx
@@ -224,8 +224,8 @@ void RegionBand::load(SvStream& rIStrm)
         // insert new band or new separation?
         if(STREAMENTRY_BANDHEADER == (StreamEntryType)nTmp16)
         {
-            long nYTop;
-            long nYBottom;
+            sal_Int32 nYTop(0);
+            sal_Int32 nYBottom(0);
 
             rIStrm >> nYTop;
             rIStrm >> nYBottom;
@@ -248,8 +248,8 @@ void RegionBand::load(SvStream& rIStrm)
         }
         else
         {
-            long nXLeft;
-            long nXRight;
+            sal_Int32 nXLeft(0);
+            sal_Int32 nXRight(0);
 
             rIStrm >> nXLeft;
             rIStrm >> nXRight;
@@ -284,8 +284,8 @@ void RegionBand::save(SvStream& rOStrm) const
     {
         // put boundaries
         rOStrm << (sal_uInt16)STREAMENTRY_BANDHEADER;
-        rOStrm << pBand->mnYTop;
-        rOStrm << pBand->mnYBottom;
+        rOStrm << static_cast<sal_Int32>(pBand->mnYTop);
+        rOStrm << static_cast<sal_Int32>(pBand->mnYBottom);
 
         // put separations of current band
         ImplRegionBandSep* pSep = pBand->mpFirstSep;
@@ -294,8 +294,8 @@ void RegionBand::save(SvStream& rOStrm) const
         {
             // put separation
             rOStrm << (sal_uInt16)STREAMENTRY_SEPARATION;
-            rOStrm << pSep->mnXLeft;
-            rOStrm << pSep->mnXRight;
+            rOStrm << static_cast<sal_Int32>(pSep->mnXLeft);
+            rOStrm << static_cast<sal_Int32>(pSep->mnXRight);
 
             // next separation from current band
             pSep = pSep->mpNextSep;
commit 36e42c0bc094231cb80157a871862c76d6a2d03a
Author: Michael Stahl <mstahl at redhat.com>
Date:   Sun Jun 30 00:11:17 2013 +0200

    fdo#66288: fix MetaAction::Read()
    
    This is "collateral damage" from the actual bug, and is broken since CVS
    initial import (which likely means that in practice no bare MetaActions
    exist), but the MetaAction::Read() must not read the type from the
    stream since MetaAction::ReadMetaAction() has already done that!
    
    Change-Id: I9ab06ec3112c1eefb86ab70ddfa2f588af257b88

diff --git a/vcl/source/gdi/metaact.cxx b/vcl/source/gdi/metaact.cxx
index b8725eb..a522e05 100644
--- a/vcl/source/gdi/metaact.cxx
+++ b/vcl/source/gdi/metaact.cxx
@@ -144,9 +144,9 @@ void MetaAction::Write( SvStream& rOStm, ImplMetaWriteData* )
 
 // ------------------------------------------------------------------------
 
-void MetaAction::Read( SvStream& rIStm, ImplMetaReadData* )
+void MetaAction::Read( SvStream&, ImplMetaReadData* )
 {
-    rIStm >> mnType;
+    // DO NOT read mnType - ReadMetaAction already did that!
 }
 
 // ------------------------------------------------------------------------