SvMemoryStream remainingSize returned the size from current
position to internal buffer size instead to end of data. This
was not consistent with what remainingSize description says on
SvStream (and other SvStream implementations work) and what the
user expects.
Change-Id: I7ff391754a386c5f067a4bd4eed2ee7f2d7fd77e
...which does not make sense. On Linux and Mac OS X, they potentially end up
exported from multiple libs (weakly, though), while on Windows the potentially
even end up not emitted at all, which could cause link errors.
Change-Id: I092c9ba39e686c17b6e91581cdd4753f1c4d582f
It appears that the C++ standard allows overriding destructors to be marked
"override," but at least some MSVC versions complain about it, so at least make
sure such destructors are explicitly marked "virtual."
Change-Id: I0e1cafa7584fd16ebdce61f569eae2373a71b0a1
...mostly done with a rewriting Clang plugin, with just some manual tweaking
necessary to fix poor macro usage.
Change-Id: I71fa20213e86be10de332ece0aa273239df7b61a
First, I updated the clang rewriter to do the conversion.
Then I lightly hand-tweaked the output for the few places where
the rewriter messed up, mostly when dealing with calls on "this".
Change-Id: I40a6a977959cd97415c678eafc8507de8aa3b1a9
Reviewed-on: https://gerrit.libreoffice.org/7879
Reviewed-by: Michael Stahl <mstahl@redhat.com>
Tested-by: Michael Stahl <mstahl@redhat.com>
Use a clang rewriter to rewrite SvStream::operator<< to methods
like WriteUInt32.
Note that the rewriter is not perfect, and hand-tweaking the output
is necessary.
Change-Id: I0291c8192ca74d6334ed3cf8cb713212b2f0c67d
Reviewed-on: https://gerrit.libreoffice.org/7307
Reviewed-by: Michael Stahl <mstahl@redhat.com>
Tested-by: Michael Stahl <mstahl@redhat.com>
It inherits from SvStream, so it could be used easily.
Basically, it's just a simple wrapper around
osl_executeProcess_WithRedirectedIO() and osl_readFile().
Change-Id: Ifa225c87d2c9be7e71ea113b0832a4fe83ec65b3
I changed SvCacheStream class to SvMemoryStream class in
the following: MSE40HTMLClipFormatObj, SfxLockBytesItem,
SwEditShell, INetMIMEMessageStream classes,
MakeLockBytes_Impl function and SwUnoCursorHelper namespace.
I modified header the precompiled_sw.hxx, wrtsh1.cxx, unoobj2.cxx.
I added two functions in SvMemoryStream class: GetBuffer and
GetSize, and I renamed the old GetSize function to GetBufSize.
I deleted SvCacheStream class.
Change-Id: I929236538dfbe23cccfd1eb85f10c1d5411baa8d
Reviewed-on: https://gerrit.libreoffice.org/4847
Reviewed-by: Andras Timar <atimar@suse.com>
Tested-by: Andras Timar <atimar@suse.com>
As the recent regression after merging AOO patch adding code serializing
"long" variables has shown, this overload (which was added in
7b2a0e541567be9750dfc7d98374555967da3470) is a bad idea.
In a unxlngx build, nm finds uses of the symbols _ZN8SvStreamrsERl
and _ZN8SvStreamlsEl in these files:
- sbxvalue.cxx: this appears to be a legitimate use with sal_Int64
- dateitem.cxx: this was accidentally changed by commit
9830fd36dbdb72c79703b0c61efc027fba793c5a
- atrfrm.cxx: this was added for Table Autoformat enhancement in
7e8c0bd73ee59ff3041e55268c77203373962e51, which is after the
sal_Int64 operators were added, so the file format is now
platform dependent
Change-Id: I78352b5429b53612c4831cdb81b587b5de5180a9
see https://gerrit.libreoffice.org/#/c/3367/
and Change-Id: I00c96fa77d04b33a6f8c8cd3490dfcd9bdc9e84a for details
Change-Id: I199a75bc4042af20817265d5ef85b1134a96ff5a
