Add new methods "subView" to O(U)String to return substring views
of the underlying data.
Add a clang plugin to warn when replacing existing calls to copy()
would be better to use subView().
Change-Id: I03a5732431ce60808946f2ce2c923b22845689ca
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105420
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
+ rename OWeakStorRefList_Impl to OWeakStorRefVector_Impl
to make it more explicit
Change-Id: I231c9e582cbfb4670835fe1ef0ce41692ad8dcb3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103501
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
do more like
commit 121771e37f
Date: Mon Sep 21 09:17:54 2020 +0200
Make some OUStringLiteral vars constexpr
cause coverity can live with that
Change-Id: I9efd7f848289c4865997a44c6780373068422227
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103147
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
This is a prerequisite for making conversion from OUStringLiteral to OUString
more efficient at least for C++20 (by replacing its internals with a constexpr-
generated sal_uString-compatible layout with a SAL_STRING_STATIC_FLAG refCount,
conditionally for C++20 for now).
For a configure-wise bare-bones build on Linux, size reported by `du -bs
instdir` grew by 118792 bytes from 1155636636 to 1155755428.
In most places just a u"..." string literal prefix had to be added. In some
places
char const a[] = "...";
variables have been changed to char16_t, and a few places required even further
changes to code (which prompted the addition of include/o3tl/string_view.hxx
helper function o3tl::equalsIgnoreAsciiCase and the additional
OUString::createFromAscii overload).
For all uses of macros expanding to string literals, the relevant uses have been
rewritten as
u"" MACRO
instead of changing the macro definitions. It should be possible to change at
least some of those macro definitions (and drop the u"" from their call sites)
in follow-up commits.
Change-Id: Iec4ef1a057d412d22443312d40c6a8a290dc6144
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101483
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
This reverts commit 50fd69dfe2.
now that...
commit 986bd28388
Date: Thu Aug 6 10:50:47 2020 +0100
ofz#24641 libc++abi __cxa_exception has grown another member
solved the substantial problem
Change-Id: I38734d99a2c8d9e272547ea657555eb4b59a5052
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100974
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
ZipOutputEntryBase::processDeflated() was calling isDeflaterFinished()
to find out whether to finalize and dispose m_xCipherContext.
With ZipOutputEntryParallel this was always true, so the context
was disposed after the first call. That was originally correct, because
originally processDeflated() was called just once at the very end, but
353d4528b8 changed to calling it several
times.
Change-Id: I1e4a0c887e4ba7ac7b20fa315169eaa911335fde
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98625
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
Do not throw an exception if there are encryption parameters,
but they are not supported in current output format. Invalid or
unsupported encryption then fails higher up the stack.
Change-Id: I21e4cf2f73d7c218ab5444b2016e838695163ca3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/84435
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
META-INF/manifest.xml[8,137]: Error: element "manifest:start-key-generation" was found where no element may occur
The problem is that in the schema, manifest:start-key-generation
precedes key-derivation but LO writes it in swapped order.
This is apparently a workaround for a bug in OOo < 3.2 ODF import and
specific to ODF >= 1.2 because the element didn't exist in ODF 1.1; as
it turns out we don't care about OOo < 3.4 being able to load encrypted
ODF 1.2 documents anway since commit
0b7c3b7d9f "tdf#114939 officecfg,sfx2:
always use AES/SHA256 in ODF 1.2".
Change-Id: I3b62e3eba719f13e39fb24bf9792f764b24ccaeb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94413
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@cib.de>
This was supposed to be implemented by commit
a7bf6488eb
"ODF1.3: import new OpenPGP encryption markup"
but it turns out that the ODF 1.3 cs01 schema differs from the
implementation:
in ODF 1.3 cs01 we have
<manifest:encrypted-key>
<manifest:encryption-method .../>
<manifest:keyinfo>
<manifest:PGPData>
</manifest:PGPData>
</manifest:keyinfo>
<manifest:CipherData>
</manifest:CipherData>
</manifest:encrypted-key>
whereas the implementation expects
<manifest:keyinfo>
<manifest:encrypted-key>
<manifest:encryption-method .../>
<manifest:PGPData>
</manifest:PGPData>
<manifest:CipherData>
</manifest:CipherData>
</manifest:encrypted-key>
</manifest:keyinfo>
Ideally the inner manifest:keyinfo should be manifest:KeyInfo but
not sure if that really matters.
Change-Id: I407321c857e7b3ed9f4d04568ca2ea116764b3da
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94309
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@cib.de>
found by a more aggressive variant of loplugin:unusedvariables.
This is my first pass, committing the simplest and most obviously
unnecessary vars
Change-Id: I9676a6e39a101937097788548764506c93811c57
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87414
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
In this approach the input stream is read one batch (of constant size)
at a time and each batch is compressed by ThreadedDeflater. After
we are done with a batch, the deflated buffer is processed straightaway
(directed to file backed storage).
Change-Id: I2d42f86cf5898e4d746836d94bf6009a8d3b0230
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86596
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
required to carry it out will cause a breach of addressable memory
limit. This can happen in 32bit OSes, where the physical memory limit is
more than the process addressable memory limit. For example in Win32,
a process can address only upto 2GB.
More specifically, avoid using ZipOutputEntryParallel
which rougly needs twice the memory compared to its counterparts.
Change-Id: I4d1abbf75e928188bcf806fcf1e5872b1e51b502
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/84394
Tested-by: Jenkins
Reviewed-by: Dennis Francis <dennis.francis@collabora.com>
The autorecovery data is stored in ODF, regardless of the original
document format. When restoring, type detection generates ODF data,
which is stored in the media descriptor attached to document, even
after real filter was restored (see AutoRecovery::implts_openDocs).
If real filter is not ODF, then at the save time, it doesn't find
necessary information in encryption data, and makes not encrypted
package.
This patch adds both MS binary data, and OOXML data, to existing
ODF data for recovered password-protected documents (regardless of
their real filter).
TODO: only add required information to encryption data: pass real
filter name to DocPasswordHelper::requestAndVerifyDocPassword from
AutoRecovery::implts_openDocs.
Change-Id: I4749c5ec028ca61bddf7cd77bc5969a97b1de199
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86201
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
I end up with something that fails in the fuzzing setup but which
cannot be used as a testcase in a normal build
Change-Id: I20c73aa009fdc289d95d34a8adf8ddd5882f6694
Reviewed-on: https://gerrit.libreoffice.org/84013
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
...that trigger -Werror,-Wdeprecated-copy ("definition of implicit copy
{constructor, assignment operator} for ... is deprecated beause it has a
user-declared copy {assignment operator, constructor}") new in recent Clang 10
trunk (and which apparently warns about more cases then its GCC counterpart, for
which we already adapted the code in the past, see e.g. the various
"-Werror=deprecated-copy (GCC trunk towards GCC 9)" commits)
Change-Id: Ie37bd820e6c0c05c74e1a862bb1d4ead5fb7cc9c
Reviewed-on: https://gerrit.libreoffice.org/83698
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...following up on 314f15bff0 "Extend
loplugin:external to warn about enums".
Cases where free functions were moved into an unnamed namespace along with a
class, to not break ADL, are in:
filter/source/svg/svgexport.cxx
sc/source/filter/excel/xelink.cxx
sc/source/filter/excel/xilink.cxx
svx/source/sdr/contact/viewobjectcontactofunocontrol.cxx
All other free functions mentioning moved classes appear to be harmless and not
give rise to (silent, even) ADL breakage. (One remaining TODO in
compilerplugins/clang/external.cxx is that derived classes are not covered by
computeAffectedTypes, even though they could also be affected by ADL-breakage---
but don't seem to be in any acutal case across the code base.)
For friend declarations using elaborate type specifiers, like
class C1 {};
class C2 { friend class C1; };
* If C2 (but not C1) is moved into an unnamed namespace, the friend declaration
must be changed to not use an elaborate type specifier (i.e., "friend C1;"; see
C++17 [namespace.memdef]/3: "If the name in a friend declaration is neither
qualified nor a template-id and the declaration is a function or an
elaborated-type-specifier, the lookup to determine whether the entity has been
previously declared shall not consider any scopes outside the innermost
enclosing namespace.")
* If C1 (but not C2) is moved into an unnamed namespace, the friend declaration
must be changed too, see <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71882>
"elaborated-type-specifier friend not looked up in unnamed namespace".
Apart from that, to keep changes simple and mostly mechanical (which should help
avoid regressions), out-of-line definitions of class members have been left in
the enclosing (named) namespace. But explicit specializations of class
templates had to be moved into the unnamed namespace to appease
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92598> "explicit specialization of
template from unnamed namespace using unqualified-id in enclosing namespace".
Also, accompanying declarations (of e.g. typedefs or static variables) that
could arguably be moved into the unnamed namespace too have been left alone.
And in some cases, mention of affected types in blacklists in other loplugins
needed to be adapted.
And sc/qa/unit/mark_test.cxx uses a hack of including other .cxx, one of which
is sc/source/core/data/segmenttree.cxx where e.g. ScFlatUInt16SegmentsImpl is
not moved into an unnamed namespace (because it is declared in
sc/inc/segmenttree.hxx), but its base ScFlatSegmentsImpl is. GCC warns about
such combinations with enabled-by-default -Wsubobject-linkage, but "The compiler
doesn’t give this warning for types defined in the main .C file, as those are
unlikely to have multiple definitions."
(<https://gcc.gnu.org/onlinedocs/gcc-9.2.0/gcc/Warning-Options.html>) The
warned-about classes also don't have multiple definitions in the given test, so
disable the warning when including the .cxx.
Change-Id: Ib694094c0d8168be68f8fe90dfd0acbb66a3f1e4
Reviewed-on: https://gerrit.libreoffice.org/83239
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
As the SID_ENCRYPTIONDATA and SID_PASSWORD are used for setting
password together, EncryptionData should be removed only
when Password was set (reset of Password protection for the document).
Elsewhere EncryptionData should remain as is, while it could
contain encryption data used for opened document.
Change-Id: I46b757af81e68ad4781e83b1a0e0b6da3a5e13e1
Change-Id: I1213ec55d6dc42f062930467976de45c73152f0b
Reviewed-on: https://gerrit.libreoffice.org/82616
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
Tested-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
I started with 32 and kept doubling the size until the site
did not need re-alloc, but clamped it at 512 (e.g. in emfio/).
Change-Id: Ib7caf35a1b7e42b0e4ed8aa812493449e3eefc8f
Reviewed-on: https://gerrit.libreoffice.org/81540
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
It started out as a wrapper around character literals, but has by now become a
wrapper around arbitrary single characters. Besides updating the documentation,
this change is a mechanical
for i in $(git grep -Fl OUStringLiteral1); do sed -i -e s/OUStringLiteral1/OUStringChar/g "$i"; done
Change-Id: I1b9eaa4b3fbc9025ce4a4bffea3db1c16188b76f
Reviewed-on: https://gerrit.libreoffice.org/80892
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
look for OUStringBuffer append sequences that can be turned
into creating an OUString with + operations
Change-Id: Ica840dc096000307b4a105fb4d9ec7588a15ade6
Reviewed-on: https://gerrit.libreoffice.org/80809
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Noel