throw exception in SvStream when reading past end of file

to avoid chasing weird problems where we read past the end
of file, which leads to random data in the variable we read into.

I expect a couple of possible regressions from this change

(1) memory leaks caused by non-exception-safe memory handling.
Of which there should not be much because we're pretty good
about using smart pointer classes these days.

(2) Broken files which used to load, will no longer do so.
These will have to be debugged by putting a breakpoint
on the SvStreamEOFException constructor, and examining
the backtrace to see where we should be catching and ignoring
the exception to make the code continue to handle such broken
files.

Change-Id: I351be031bb083a3484a9a1b650a58892700e6fb7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105936
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>

1 files changed, 0 insertions, 12 deletions

diff --git a/tools/qa/cppunit/test_stream.cxx b/tools/qa/cppunit/test_stream.cxx
index d8e4d1ef71e1..b58d1f07aaa5 100644
--- a/tools/qa/cppunit/test_stream.cxx
+++ b/tools/qa/cppunit/test_stream.cxx
@@ -84,18 +84,6 @@ namespace
         //yet, the read didn't succeed
         CPPUNIT_ASSERT(!aMemStream.good());
 
-        //set things up so that there is only one byte available on an attempt
-        //to read a two-byte sal_uInt16.  The byte should be consumed, but the
-        //operation should fail, and tools_b should remain unchanged,
-        sal_uInt16 tools_b = 0x1122;
-        aMemStream.SeekRel(-1);
-        CPPUNIT_ASSERT(!aMemStream.eof());
-        CPPUNIT_ASSERT(aMemStream.good());
-        aMemStream.ReadUInt16( tools_b );
-        CPPUNIT_ASSERT(!aMemStream.good());
-        CPPUNIT_ASSERT(aMemStream.eof());
-        CPPUNIT_ASSERT_EQUAL(static_cast<sal_uInt16>(0x1122), tools_b);
-
         iss.clear();
         iss.seekg(0);
         CPPUNIT_ASSERT(iss.good());