ZCodec::Compress read a fresh chunk over whatever deflate had left unconsumed.
deflate stops as soon as its output buffer is full, and the write-back that
frees that buffer only ran at the top of the next iteration, by which time the
tail of the previous chunk was gone.
Nothing said so. EndCompression answers with the number of bytes taken and no
caller compared it, so the result was a shorter document than the one handed
in, compressed perfectly well. Passing 100000 bytes through a 64 byte output
buffer took 49152 of them.
Signed-off-by: Mike Kaganski <mike.kaganski@collabora.com>
Change-Id: I1044a46aa1d1f424e7d699a927e01a8427768919
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/13208
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
(cherry picked from commit 23e2e9c2136d8b5c9fd6d9604bccd35e9b657571)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211555
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Instead of selecting the first encoding returned by ucsdet_detectAll
(except the 5 CJK when they have confidence of 10), recalculate
confidence by removing 10 only when one of the 5 CJK encodings then
check each encoding returned by ucsdet_detectAll and select the one with
the max confidence with this new rule.
I also tested this again on tdf#172905, no regression.
Change-Id: I6a8e2b30e8467fefd53c02296484e48ca467c662
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/209143
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
whereas 0 is the starting point (eg for iso-8859-*)
So don't retain the CJK character sets if they're just at 10
and there's no other character sets
+ add some debug traces to track charsets detected by libicu
and their associated confidence
Change-Id: I7d89d06ffb963143276aff749e7d1a6f7a531cca
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208899
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
This sentence was added in
commit cf9bc834a4
Date: Mon Apr 8 15:34:25 2013 +0200
update documentation
and the two tickets it references are both marked
RESOLVED FIXED as they were both about
porting code using a specific subset of the tools
module to something else, not about dropping
the tools module altogether.
(At least that's what was agreed on in the end
for the scope of those tickets, see discussion
in these tickets.)
Change-Id: Iea3fcb2b3e7a98d0a63382ef8ca6dc4177fac857
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208127
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
IsExoticProtocol used GetHost() to recover the nested package url of a
vnd.sun.star.pkg url, but the package content provider in
ucb/source/ucp/package/pkguri.cxx uses the whole authority between "://"
and the next '/', which GetHost() truncates at '@'. Check the same
substring the provider does.
The vnd.sun.star.zip branch below already did the equivalent extraction,
so pull the shared parts into a helper that both branches call.
Signed-off-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Change-Id: I27be6a839108f2e58d62baefc1a71dcbfc9a4568
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/4410
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Stephan Bergmann <stephan.bergmann@collabora.com>
(cherry picked from commit ce436efb34d2e0e90ee2cdb450da285530c562f7)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/206681
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Jenkins
...as emsdk 5.0.3 deprecated the predefined EMSCRIPTEN macro (see
<https://github.com/emscripten-core/emscripten/commit/506052bd8b4e23ded7f2351c62ca3b24d40c8cf3>
"Warn about usage of deprecated EMSCRIPTEN macro. NFC (#26381)"), causing
failures like
> In file included from static/source/unoembindhelpers/PrimaryBindings.cxx:29:
> In file included from include/sfx2/viewsh.hxx:35:
> In file included from include/editeng/outliner.hxx:32:
> In file included from include/tools/color.hxx:26:
> include/osl/endian.h:66:15: error: macro 'EMSCRIPTEN' has been marked as deprecated: use __EMSCRIPTEN__ instead [-Werror,-Wdeprecated-pragma]
> 66 | #elif defined EMSCRIPTEN
> | ^
> /home/sberg/emsdk/5.0.4/emsdk/emscripten/main/cache/sysroot/include/emscripten/emscripten.h:35:66: note: macro marked 'deprecated' here
> 35 | #pragma clang deprecated(EMSCRIPTEN, "use __EMSCRIPTEN__ instead")
> | ^
To avoid confusion, also suppress the -D$(OS) in
solenv/gbuild/platform/unxgcc.mk that would unnecessarily keep defining
EMSCRIPTEN.
Change-Id: Ic1f187cf1c6417cd95d4092e9cea01a665bd1b2f
Reviewed-on: https://gerrit.collaboraoffice.com/c/core/+/34
Reviewed-by: Michael Stahl <michael.stahl@collabora.com>
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
(cherry picked from commit 50291c2ed83bdb49bb827a4a12905d94b8c42035)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205167
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
- Convert include guards to #pragma once in salhelper, starmath, tools, ucb, and o3tl.
- Kept changes minimal to a small cross-module batch as requested by the easyHack guidance.
- Verified with: container=1 make -j4 o3tl.build salhelper.build starmath.build tools.build ucb.build
Change-Id: Ic047061433985e12be41bdb6463ac4c8e8969ddd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/204555
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Jenkins
And not truncate it to an integer value.
Add additional overload for attribute that takes an enumerated type, otherwise
the compiler will complain about ambiguous conversion because it cannot
choose between the attribute that takes a integral value and the one that
takes a double value.
Change-Id: I9eae22817ec3b26da7b9468d1c8b5e6f3e900538
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/201193
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Tested-by: Jenkins
Starts a process of converting the call-sites of SvFileStream
to just write data, relying on the stream being set
into the correct encoding somewhere during initialisation.
In this commit, I change WriteByteStringLine to do that.
For most of the call sites, they either:
(a) use the stream encoding explicitly
(b) already set the stream to the encoding being used at the call-site
Only in buildFontMenuName did I need to make the stream explicitly
set the stream encoding.
Also add a utility constructor to SvFileStream to make it easy
to set the stream in the correct mode at open-time.
Ideally a stream should be set into the correct encoding
at open time and never changed.
Change-Id: I57afa74807e15320a176a05d43c94c377dad4561
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/200289
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Use the correct term. E.g., Unicode charset has different encodings
like UTF-8 and UTF-16, and we mean encoding here.
Change-Id: I65e90b31cda6e39fdb1584b492e6e0b9821865a5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/200285
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Seems like recent font/pdf related changes have exposed a latent
bug(?) in the SvMemoryStream class. Specifically, writing to
SvMemoryStream using a source pointer that points inside the SvMemoryStream
data buffer causes trouble when the buffer is re-allocated.
Make SvMemoryStream tolerant of this, although it is a rather
dodgy use-case.
READ of size 177 at 0x531000155fe7 thread T0
SvMemoryStream::PutData(void const*, unsigned long) /tools/source/stream/stream.cxx:1578:5
SvStream::WriteBytes(void const*, unsigned long) /tools/source/stream/stream.cxx:1195:26
vcl::filter::PDFDocument::WriteCatalogObject(int, vcl::filter::PDFReferenceElement*&) /vcl/source/filter/ipdf/pdfdocument.cxx:577:27
freed by thread T0 here:
in SvMemoryStream::FreeMemory() /tools/source/stream/stream.cxx:1694:9
in SvMemoryStream::ReAllocateMemory(long) /tools/source/stream/stream.cxx:1671:9
in SvMemoryStream::PutData(void const*, unsigned long) /tools/source/stream/stream.cxx:1569:22
in SvStream::WriteBytes(void const*, unsigned long) /tools/source/stream/stream.cxx:1195:26
in vcl::filter::PDFDocument::WriteCatalogObject(int, vcl::filter::PDFReferenceElement*&) /vcl/source/filter/ipdf/pdfdocument.cxx:577:27
Change-Id: I2613ed66cec600b7f44e575a56f6a97c0ff3053d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/199959
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
...contrary to what c511c65434 "tdf#146619 Use
more forward declarations in include/tools" apparently assumed, as seen at least
with recent Clang 23 trunk against recent libstdc++ 16 trunk,
> In file included from tools/source/generic/poly2.cxx:22:
> In file included from tools/inc/poly.h:22:
> In file included from ~/gcc/inst/lib/gcc/x86_64-pc-linux-gnu/16.0.1/../../../../include/c++/16.0.1/memory:80:
> ~/gcc/inst/lib/gcc/x86_64-pc-linux-gnu/16.0.1/../../../../include/c++/16.0.1/bits/unique_ptr.h:131:18: error: invalid application of 'sizeof' to an incomplete type 'Point'
> 131 | static_assert(sizeof(_Tp)>0,
> | ^~~~~~~~~~~
> ~/gcc/inst/lib/gcc/x86_64-pc-linux-gnu/16.0.1/../../../../include/c++/16.0.1/bits/unique_ptr.h:684:4: note: in instantiation of function template specialization 'std::default_delete<Point[]>::operator()<Point>' requested here
> 684 | get_deleter()(__ptr);
> | ^
> tools/inc/poly.h:33:21: note: in instantiation of member function 'std::unique_ptr<Point[]>::~unique_ptr' requested here
> 33 | ImplPolygon() : mnPoints(0) {}
> | ^
> include/tools/poly.hxx:60:7: note: forward declaration of 'Point'
> 60 | class Point;
> | ^
Change-Id: I0b96222dcec7e98b974151004248a91ba1854e60
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/198573
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@collabora.com>
...which helps avoid some supposedly spurious -Werror=free-nonheap-object seen
at least with recent GCC 16 trunk,
> In destructor ‘virtual SvLockBytes::~SvLockBytes()’,
> inlined from ‘void SvRefBase::ReleaseRef()’ at include/tools/ref.hxx:160:36,
> inlined from ‘tools::SvRef<T>::~SvRef() [with T = writerfilter::rtftok::RTFTokenizer]’ at include/tools/ref.hxx:56:46,
> inlined from ‘writerfilter::rtftok::RTFLookahead::~RTFLookahead()’ at sw/source/writerfilter/rtftok/rtflookahead.cxx:37:1:
> include/tools/stream.hxx:115:48: error: ‘void operator delete(void*, std::size_t)’ called on pointer ‘((tools::SvRef<writerfilter::rtftok::RTFTokenizer>*)this)[1].tools::SvRef<writerfilter::rtftok::RTFTokenizer>::pObj’ with nonzero offset 56 [-Werror=free-nonheap-object]
> 115 | virtual ~SvLockBytes() override { close(); }
> | ^
etc.
Change-Id: I26a599f0e3258e6bf6a4d6e63e559b41029862db
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/197842
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@collabora.com>
elioperdreau
Mike Kaganski