Age | Commit message (Collapse) | Author | Files | Lines |
|
with expressions like !(a && b)
Change-Id: Id2acec2a8d0eaaa8e5e37dbd2cae7281be36572e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100040
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
This reverts commit 58a96d3ccedbade4f1a8bfbbc4b7d8f1615cfc69.
Change-Id: I9d0459c10ece1d4a8e9efeae611cf29d15ca0885
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99893
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
See tdf#74608 for motivation.
Change-Id: If1512d63fd1089f6f8486e32106c68f495a1f3df
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99424
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
See tdf#74608 for motivation.
Change-Id: I17627bdd2f4f595343ad9bf524dc57cd03170b2a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98921
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
More fixing of 353d4528b8ad8ab, that I didn't get quite right
in 08161f853571e3. There must be one final processDeflated()
call that has isDeflaterFinished() return true, so that
encrypting is finalized properly.
Change-Id: Id15190cc467a801ccc57e1efe802cdd8fc618a71
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98878
Tested-by: Luboš Luňák <l.lunak@collabora.com>
Reviewed-by: Luboš Luňák <l.lunak@collabora.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
353d4528b8ad8abca9a13f3016632e42bab7afde 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>
|
|
Change-Id: I75602277a5a26b012a12f2c4f4b7ff5bb663b0b9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98474
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Ie183cb0d374e8d9a02891a765f46583f7cc1c345
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97618
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
which is both more compact code, and more efficient, since the insert
method can do smarter resizing
Change-Id: I17f226660f87cdf002edccc29b4af8fd59a25f91
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/96948
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I10f55bff4619fe7c1cab378aa00d96cf31d0fcd8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95511
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.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>
|
|
Change-Id: Idddba2f3fd05265b08dbc88edb6152d34a166052
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94730
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
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
0b7c3b7d9fa71f59eed75c3e80e5e12245c5e1c5 "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>
|
|
Import was implemented with a7bf6488ebb544e1efaed0a1e53073df9cc2064d
but it doesn't correspond to the schema so see previous commit.
Change-Id: Ic19db07da20e88d6533509217a70983938e61beb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93088
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@cib.de>
|
|
This was supposed to be implemented by commit
a7bf6488ebb544e1efaed0a1e53073df9cc2064d
"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>
|
|
Change-Id: Iff68e8f379614a6ab6a6e0d1bad18e70bc76d76a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91907
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I9956f715e00a0c2814b79617f37dd0c09f049ad0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93858
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I83a61da7dda6c72552eecd377f1c3744c92a797e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92909
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Ib2dd157d43c4387eda009475311761fe2eb627cb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92241
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I4d81c7c1d241e51565d7cbc6549ac586136f0c86
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91616
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Found by:
run-clang-tidy-10 -checks=-*,misc-unused-using-decls
Change-Id: I3e95791e223ef01e140a6217e29a9efae428a784
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90876
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
This reverts commit 31138ff7729cbf179079a5e635d3a823e2971f08.
Now that we know that making fields has negative side effects
like disabling assignment operator generation.
Change-Id: I3f1ae65532f441c8be5ebca5866b8a1e1c69318c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90363
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
With --enable-pch=full there's not much difference between a "public"
header in <module>/inc and a private one in <module>/src/somewhere/inc .
And since the script searches recursively, this apparently helps to
find even more headers for lower pch levels.
Change-Id: I8483d0aa5b4fea5a59107c20a8aa5f1ef694af0a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87799
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
Change-Id: Ie5a381fc5e5b73490ab8b2036ef2a1164e475e8f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87557
Tested-by: Jenkins
Reviewed-by: Muhammet Kara <muhammet.kara@collabora.com>
|
|
found by my new loplugin:unusedvariableplus
Change-Id: Ic3f55f492d43a53d8850a97d44059ff127fd69a2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87573
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ib2465f040f12413560b2cec1c742cf3558461309
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87404
Tested-by: Jenkins
Reviewed-by: Muhammet Kara <muhammet.kara@collabora.com>
|
|
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>
|
|
mostly to make the job of my very aggressive unused local vars plugin
easier
Change-Id: Ifc21a920841f8589f8b7e10de39dba6622a5d501
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87399
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I2908abc13f16b0011fcb326e8405080cc30df74a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86684
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>
|
|
This reverts commit 0b8ae8725083eb0526a262d434cc06fb3f3e7336.
A better fix will follow this patch.
Change-Id: I4ff8d71bf2401bae2e2071c369e3746b8b7c72bb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86595
Tested-by: Jenkins
Reviewed-by: Dennis Francis <dennis.francis@collabora.com>
|
|
Change-Id: I1c1e7b42211c51f572698efd3135e388f8fb2979
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86648
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I5eb9c58f511a6ded473eb3fb998fd21584c227d8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86607
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.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>
|
|
Change-Id: Icc7f2a32696c30317c1ee77ef39d682d5f5a80b9
Reviewed-on: https://gerrit.libreoffice.org/85512
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
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>
|
|
Change-Id: I77e28f02516ab25ff6680970dc13d52cfa90eac1
Reviewed-on: https://gerrit.libreoffice.org/83620
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
...following up on 314f15bff08b76bf96acf99141776ef64d2f1355 "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>
|
|
E.g. #ifdef LIBO_INTERNAL_ONLY is always true for code that builds
with our PCHs.
Change-Id: I3cf311ea3621b909105754cfea2cb0116b8b67f5
Reviewed-on: https://gerrit.libreoffice.org/80961
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
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>
|
|
which defeat the *StringConcat optimisation.
Also make StringConcat conversions treat a nullptr as an empty string,
to match the O*String(char*) constructors.
Change-Id: If45f5b4b6a535c97bfeeacd9ec472a7603a52e5b
Reviewed-on: https://gerrit.libreoffice.org/80724
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I1f8b626ae99bca6e31e7c4aa9c8a1fc016b76e5c
Reviewed-on: https://gerrit.libreoffice.org/79890
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I17f06c9415b9d43b6d8896360e07216c2856367a
Reviewed-on: https://gerrit.libreoffice.org/79627
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I7b3a22584bb2e4d501f509ffcd80929feed23a4c
Reviewed-on: https://gerrit.libreoffice.org/79360
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
Change-Id: Ibc1b7393a8e65bf23c78fdb9da78c6b73b544cf3
Reviewed-on: https://gerrit.libreoffice.org/78793
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|