Age | Commit message (Collapse) | Author | Files | Lines |
|
Combine everything related to a certificate in a new struct X509Data.
The CertDigest is not actually written in the X509Data element but in
xades:Cert, so try to find the matching entry in
XSecController::setX509CertDigest().
There was a confusing interaction with PGP signatures, where ouGpgKeyID
was used for import, but export wrote the value from ouCertDigest
instead - this needed fixing.
The main point of this is enforcing a constraint from xmldsig-core 4.5.4:
All certificates appearing in an X509Data element MUST relate to the
validation key by either containing it or being part of a certification
chain that terminates in a certificate containing the validation key.
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111254
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
(cherry picked from commit 9e82509b09f5fe2eb77bcdb8fd193c71923abb67)
xmlsecurity: improve handling of multiple certificates per X509Data
It turns out that an X509Data element can contain an arbitrary number of
each of its child elements.
How exactly certificates of an issuer chain may or should be distributed
across multiple X509Data elements isn't terribly obvious.
One thing that is clear is that any element that refers to or contains
one particular certificate has to be a child of the same X509Data
element, although in no particular order, so try to match the 2 such
elements that the parser supports in XSecController::setX509Data().
Presumably the only way it makes sense to have multiple signing
certificates is if they all contain the same key but are signed by
different CAs. This case isn't handled currently; CheckX509Data() will
complain there's not a single chain and validation of the certificates
will fail.
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111500
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
(cherry picked from commit 5af5ea893bcb8a8eb472ac11133da10e5a604e66)
xmlsecurity: add EqualDistinguishedNames()
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111545
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
(cherry picked from commit 1d3da3486d827dd5e7a3bf1c7a533f5aa9860e42)
xmlsecurity: avoid exception in DigitalSignaturesDialog::getCertificate()
Fallback to PGP if there's no X509 signing certificate because
CheckX509Data() failed prevents the dialog from popping up.
To avoid confusing the user in this situation, the dialog should
show no certificate, which is already the case.
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111664
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
(cherry picked from commit 90b725675c2964f4a151d802d9afedd8bc2ae1a7)
xmlsecurity: fix crash in DocumentDigitalSignatures::isAuthorTrusted()
If the argument is null.
This function also should use EqualDistinguishedNames().
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111667
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
(cherry picked from commit ca98e505cd69bf95d8ddb9387cf3f8e03ae4577d)
Change-Id: I9633a980b0c18d58dfce24fc59396a833498a77d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111910
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I5681249808cf623d3b7df09988f285268ea8d85f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104255
Tested-by: Jenkins
Reviewed-by: Eike Rathke <erack@redhat.com>
(cherry picked from commit 18f8a7056ac7b4677f4d99aac24ed2db44010140)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108730
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
This reverts commit da5c289a9cae5d914937f235694fd5b0cb92547f.
Change-Id: Ic6a77ec2cd3b502fb4e94159a0424340850590df
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103665
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
(cherry picked from commit 0b3ff97d7d5a1e8471e494f4141165364203c192)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103792
Reviewed-by: Michael Stahl <michael.stahl@cib.de>
|
|
probably since...
commit a573b8b21688d9681f4fa129ec37cf89954e9d1c
Date: Sat May 21 16:14:56 2011 -0430
Replace List for std::vector in SfxStringListItem.
Change-Id: I7060b5693ba08fa5f70cc5cb3ae1b7a4722a31a7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103340
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
|
|
Goes from more than 30s to less than 1s on my pc.
We were getting stuck inside the loop in sw::UndoManager::AddUndoAction,
because the RemoveOldestUndoAction was continually doing nothing because
it was hitting the
if ( IsInListAction()
{
assert(!"SfxUndoManager::RemoveOldestUndoActions: cannot remove a
not-yet-closed list action!");
return;
}
code.
Which means that there is some bug here, but I'm not sure what. We are
deep inside the delete logic at that point, and it doesn't seem
unreasonable to opportunistically delete some of the UNDO list at that
point.
So the real fix is just the conversion from a while loop to an if-check.
Change-Id: Ie2707009dd6574b996421f67d952ab9fdaaaf6aa
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102378
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
(cherry picked from commit da5c289a9cae5d914937f235694fd5b0cb92547f)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102313
Tested-by: Jenkins
|
|
Change-Id: Ie624b324822495192edc65d046945eb92356550b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100192
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins
(cherry picked from commit 1616b53292cdc22c04d07bb21e71bf43dcd22299)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100211
Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
|
|
1 .
1 .2
1 . 2
1. 2
. 2
. 2
are not numbers. But
.2
is.
Change-Id: Ie2e0775852e13eee733d0fed3399cbd3d065d9fe
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97895
Tested-by: Jenkins
Reviewed-by: Eike Rathke <erack@redhat.com>
(cherry picked from commit 7186541219599e1b51ad35601c2cd015a329f360)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98074
|
|
Skip *one* of them under the condition that a month name was
actually recognized.
A horrible implementation of
commit b00fc9462d26083b6d09f72ea44abb1e11546b63
CommitDate: Wed Sep 15 11:54:10 2010 +0200
sc-date-fix.diff: Parse 'june-2007' as June 1 2007 in en-US locales
Change-Id: I0800c4f0b33aa1413bde558d710fe467e4380262
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97903
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins
(cherry picked from commit 348e78b8ccd04b59140c7f83504c7823b2ffbe8c)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98072
|
|
... to accept minutes or seconds >59
Prepare SvNumInputOptions as enum class in case further options
would be needed for anything else.
Change-Id: Ie9ae62adf68f9948e23f55ac32c09a6b992a36e2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97784
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins
(cherry picked from commit 75230de70fece41986b5ad96bc959e6b1640003c)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97792
Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
|
|
Defer moving around the vector by tagging the last bit in the pointer.
This takes the undo operation from 10s to 8s on my machine.
Also re-organise the fields a little to improve packing.
Also add some design notes
Change-Id: I38fa9156705c00bb9f64e2fc59ea862eba522942
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97424
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
(cherry picked from commit bde0cc68bd6443c97b4ca061ed7132f478959281)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97571
|
|
Optimize also maDestructedListeners (often just one item). Optimize
also small vectors if there's just one item unsorted. Keep the index
of the first unsorted item in maListeners, so that it's cheap
to find out where the unsorted part starts.
This now improves tdf#132454 to 20s.
Change-Id: I21a69b440c27a2e31e74fd13b9263f54af12e320
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97198
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
(cherry picked from commit b0e0ba28dcb69b6d042107f24c961b444eb6793e)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97143
Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
|
|
A common case is just one unsorted item at the end, in that case
it's even more efficient to simply insert it in the right place.
This further improves the tdf#132454 undo operation 36s->27s.
Change-Id: I29db80fb8292e827b655000cddc462cf87cb485d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97088
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
Tested-by: Jenkins
(cherry picked from commit 845646ebda70078a7b5264d985583aa6c221db10)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97058
Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
|
|
New items are only appended, so it's wasteful to std::sort() the whole
container, just sort the unsorted part (often just one item) and then
merge.
Change-Id: I20b73730700c279e8f844c0b7a392a8f372a22da
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97019
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
(cherry picked from commit 07cda8035c34ca9f8ac3ba911a2b691349665fc7)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97050
|
|
Use Add/Delete decimal to change precision of time and duration
Apply only to 100th second
Change-Id: I2ff1b01db7ee67645511fcf7ea6bf65055e92a8c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94765
Tested-by: Jenkins
Reviewed-by: Eike Rathke <erack@redhat.com>
(cherry picked from commit 1861363d623963461905f42aa0b9dc2301f2eaaa)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/96349
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
regression from
commit 3581f1d71ae0d431ba28c0f3b7b263ff6212ce7b
optimize SharedStringPool::purge() and fix tests
which results in us potentially de-referencing an already de-allocated
OUString object in the first loop in purge().
So switch to a different strategy, which only needs one data structure,
instead of two.
Change-Id: Iaac6beda48459643afdb7b14ce7d39d68a93339c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95226
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
(cherry picked from commit 5af636c5021ecf7fba8f5f34cc6af929f1e04b4c)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/96180
|
|
with a slightly dodgy fix.
regression from
commit 3581f1d71ae0d431ba28c0f3b7b263ff6212ce7b
optimize SharedStringPool::purge() and fix tests
It's not ideal - we no longer have a way of purging uppercase keys that
are longer in use.
But that doesn't cost much memory, because we are sharing those strings.
We could potentially identify them with extra book-keeping in either
intern() or purge(), but since this class is performance-sensitive, best
just to sacrifice some space in the map.
Change-Id: I85a469448f5b36b1b6889da60280edd56bbcb083
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95432
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
(cherry picked from commit 4aa6ae8ba911bd3420d3b74c085aa69d87339f4d)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95426
|
|
which were checking the wrong thing - we don't care
about the input strings to intern(), we care
about which SharedString objects are still alive.
Change-Id: Ia35a173a02a24efb335268dcae4078a956d11098
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95177
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
(cherry picked from commit 3581f1d71ae0d431ba28c0f3b7b263ff6212ce7b)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95319
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I44b332e840a5e3084c0c16fe05f0918e42217c13
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94821
Tested-by: Julien Nabet <serval2412@yahoo.fr>
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Remapping NatNum-DBNum in Korean for compatibility tdf#130193
Unlike Japanese and Chinese[Simplified, Traditional] environment on Excel, In Korean Situation, Excel exist DBNum1~4.
I checked DBNum1~4 series on Excel 2016 in Korean Environment.
DBNum1 1234567890 一十二億三千四百五十六万七千八百九十
DBNum2 1234567890 壹拾貳億參阡四百伍拾六萬七阡八百九拾
DBNum3 1234567890 十2億3千4百5十6万7千8百9十
DBNum4 1234567890 일십이억삼천사백오십육만칠천팔백구십
Also, I checked Korean Number to Strings on LibreOffice.
[natnum1] 1234567890 一二三四五六七八九〇
[natnum2] 1234567890 壹貳參四伍六七八九零
[natnum3] 1234567890 1234567890
[natnum4] 1234567890 一十二億三千四百五十六万七千八百九十
[natnum5] 1234567890 壹拾貳億參阡四佰伍拾六萬七阡八佰九拾
[natnum6] 1234567890 1십2억3천4백5십6만7천8백9십
[natnum7] 1234567890 十二億三千四百五十六万七千八百九十
[natnum8] 1234567890 拾貳億參阡四佰伍拾六萬七阡八佰九拾
[natnum9] 1234567890 일이삼사오육칠팔구영
[natnum10] 1234567890 일십이억삼천사백오십육만칠천팔백구십
[natnum11] 1234567890 십이억삼천사백오십육만칠천팔백구십
I also checked Korean billion units test.
[natnum1] 123456789012 一二三四五六七八九〇一二
[natnum2] 123456789012 壹貳參四五六七八九零壹貳
[natnum3] 123456789012 123456789012
[natnum4] 123456789012 一千二百三十四億五千六百七十八万九千一十二
[natnum5] 123456789012 壹仟貳佰參拾四億五仟六佰七拾八萬九仟壹拾貳
[natnum6] 123456789012 1천2백3십4억5천6백7십8만9천1십2
[natnum7] 123456789012 千二百三十四億五千六百七十八万九千十二
[natnum8] 123456789012 仟貳佰參拾四億五仟六佰七拾八萬九仟拾貳
[natnum9] 123456789012 일이삼사오육칠팔구영일이
[natnum10] 123456789012 일천이백삼십사억오천육백칠십팔만구천일십이
[natnum11] 123456789012 천이백삼십사억오천육백칠십팔만구천십이
As a result,
1. from DBNum to NatNum (import):
- DBNum1 -> NatNum4 (Korean Hanja text 한자숫자)
- DBNum2 -> NatNum5 (Korean Upper Hanja text 갖은자)
- DBNum3 -> NatNum6 (fullwidth Arabic digits with Korean hanja unit of Numbering)
- DBNum4 -> NatNum10 (Korean Hangul text)
I found the Bug for NatNum6 (I'll change Korean Hangul to Hanja for compatibility)
2. From NatNum to DBNum
- NatNum1 -> DBNum1
- NatNum2 -> DBNum2
- NatNum3 -> DBNum3
- NatNum4 -> DBNum1
- NatNum5 -> DBNum2
- NatNum6 -> DBNum3
- NatNum7 -> DBNum1
- NatNum8 -> DBNum2
- NatNum9 -> DBNum4
- NatNum10 -> DBNum4
- NatNum11 -> DBNum4
By the way, I change test cases for Korean.
It is included in svl/qa/unit/svl.cxx
It solves the issue tdf#130140
Also, It related the issue tdf#130077
Change-Id: Idb7f3defc5f19e3edc4c179b0a081d2abe8ee3a2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94747
Tested-by: Jenkins
Reviewed-by: Eike Rathke <erack@redhat.com>
|
|
remap NatNum - DBNum in Japanese/Chinese to improve
Excel interoprability
from DBNum to NatNum (import) in ja/zh:
- DBNum1 -> NatNum4 (modern long Kanji text)
- DBNum2 -> NatNum5 (traditional long Kanji text)
- DBNum3 -> NatNum3 (fullwidth Arabic digits)
from NatNum to DBNum (export) in ja:
- NatNum1 -> DBNum1
- NatNum2 -> DBNum2
- NatNum3 -> DBNum3
- NatNum4 -> DBNum1
- NatNum5 -> DBNum2
- NatNum6 -> DBNum3
- NatNum7 -> DBNum1
- NatNum8 -> DBNum2
- NatNum9 -> (DBNum0, as Arabic)
in zh, nothing change about export.
It also partially solves the issue tdf#130140
(about Japanese, not Korean)
To do this, more data-drivened MapDBNumToNatNum() and
MapNatNumToDBNum() in svl/source/numbers/zformat.cxx
By mapping "NatNum - DBNum" to a table using map and array, it
makes the specification for each language more understandable
The new test cases are also included in svl/qa/unit/svl.cxx
Change-Id: I34a70d970ef2e46c1b3db5db1c397ab89c056191
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94376
Tested-by: Jenkins
Reviewed-by: Eike Rathke <erack@redhat.com>
|
|
With Add/Delete decimal place, insert percent char
and string text between number and '%'
Change-Id: I4a97e4361228020803810692d7977e5806baf180
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94757
Tested-by: Jenkins
Reviewed-by: Eike Rathke <erack@redhat.com>
|
|
Change-Id: Idddba2f3fd05265b08dbc88edb6152d34a166052
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94730
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
This popped up when attempting to replace the zh-CN keyword
'General' with '常规' for tdf#88233, which led to
CppunitTest_sc_subsequent_export_test failing for
ScExportTest::testNatNumInNumberFormatXLSX with
- Expected: [DBNum2][$-804]General;[RED][DBNum2][$-804]General
- Actual : [$-1F000804]ge\ner"al";[RED][$-1F000804]ge\ner"al"
The reason was that from the English format string loaded from .xlsx
[DBNum2][$-804]General;[RED][DBNum2][$-804]General
the resulting zh-CN format was
[DBNum2]General;[RED][DBNum2][$-804]General
like before, which when reparsed in a zh-CN locale now without the
'General' keyword first led to
[DBNum2]GEnERal;[RED][DBNum2][$-804]GEnERal
with GE and ER calendar keywords, which then is exported correctly as
[$-1F000804]ge\ner"al";[RED][$-1F000804]ge\ner"al"
So when detecting the "format belongs to another locale" condition
also switch the target locale of the ongoing conversion, which
results in the then correct
[DBNum2]常规;[RED][DBNum2][$-804]常规
exported as
[DBNum2][$-804]General;[RED][DBNum2][$-804]General
again.
Such could had happened with any format code using a [$-...]
locale modifier if keywords differ between originating and target
locale, but cases seem to be not that widespread.
Change-Id: Ib4d444a4085ace251d03e87498eb0f4871eadc8d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94313
Tested-by: Jenkins
Reviewed-by: Eike Rathke <erack@redhat.com>
|
|
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: I8dc11da4e1de5c2e2831ac85dff0daeac0e0ce95
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93744
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
and so SetSearchMask which doesn't have any effect anymore
Change-Id: I0b7f402ce0317971d5196fc448fe2945a6a292f5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93393
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
surely the current searchmask should have no effect on the remove seeing as a
new style is going to be created unilaterally
Change-Id: I4a8d05be26a3a2711ae6f377f034a9155100e831
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93496
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I19ee6a916017cb49092a2b74bc2bfd9b99b8c72d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93489
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
if there isn't one we shouldn't need to create one to invalidate it
Change-Id: Ia936f71c18c45d8e08f013ffa143c196109495ed
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93471
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I7bc570899170b7a21e4d54e58d7a8ada0f79b918
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93469
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Ic7da569f9133d31783c238d7ca4a4cc1ae0244f8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93468
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I36655b65ca00e5f7b8779a28d4a1778c8e35dc4e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93461
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
and use CreateIterator to make it explicit what is being counted
Change-Id: I8d76aef601533960a23c056b83a48c4f130bbe75
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93446
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Turns out we can save about 500Mb of preprocessor input if we use
rtl_math_approxEqual from rtl/math.h instead of its C++ wrapper
rtl::math::approxEqual from rtl/math.hxx
and manage the fallout accordingly.
Before:
bin/includebloat.awk | head
sum total bytes included (excluding system headers): 19017296671
After:
$ bin/includebloat.awk | head
sum total bytes included (excluding system headers): 18535432672
Change-Id: I1691171f3a309405a7099882ad9989d147f59118
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92508
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
and update pches accordingly
Change-Id: I411712532fd85961bffe6678416fcdc1d9c7f53d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92617
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
In preparation of further detailed handling.
Change-Id: I9e4d916de031b742d0af1025b945b7608fed8266
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92462
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins
|
|
Change-Id: I979faf4c476a7de91a0b6e06dd8717cee25525f1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92313
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>
|
|
Change-Id: Iba46fbe8559211403118a23cd198a2217b333a81
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90900
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
|
|
Change-Id: I91235eee8c6a9d4a59c1933527b49141f64cd91b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90478
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
This reverts commit 5181253946ca1877cc42050452aa6d733d6da3f1.
Change-Id: I30e30aae45c33824c0df823a9fad710faa81ea3c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90453
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ifa76e004128223460945d58d1c59c4e23db0f108
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90370
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
... representation of given decimal.
Use dtoa.c from https://www.netlib.org/fp/dtoa.c to build a custom
static library that doesn't use current locale (unlike strtod from
stdlib.h). This is the implementation used by e.g. python and nss
(search for "dtoa.c" under UnpackedTarball).
To avoid name clash with the standard strtod, rename the function
to strtod_nolocale.
Size of buffer on stack in ImpSvNumberInputScan::StringToDouble is
256 characters. Logging function usage in make check, of ~124 600
invocations, the longest string was 14 characters, average being
2.1 characters. So heap allocation is unlikely in scenarios with
intensive function usage.
After std::from_chars is available in baseline compilers, external
library can be dropped, and call to strtod_nolocale replaced with
the standard function.
The artifact at https://dev-www.libreoffice.org/src/dtoa-20180411.tgz
is created with
mkdir dtoa && mkdir dtoa/src && wget https://www.netlib.org/fp/dtoa.c -O dtoa/src/dtoa.c && \
printf 'd8bab255476f39ea495c8c8ed164f9077da926e6ca7afb9ad3c56d337c4484fe dtoa/src/dtoa.c' | sha256sum -c && \
tar -c --owner=0 --group=0 --mode=go=r,u=rw --mtime='Wed, 11 Apr 2018 15:59:39 GMT' dtoa/src/dtoa.c | gzip -n > dtoa-20180411.tgz && \
printf '0082d0684f7db6f62361b76c4b7faba19e0c7ce5cb8e36c4b65fea8281e711b4 dtoa-20180411.tgz' | sha256sum -c
(where the date "Wed, 11 Apr 2018 15:59:39 GMT" is from
`wget -S https://www.netlib.org/fp/dtoa.c`
"Last-Modified: Wed, 11 Apr 2018 15:59:39 GMT" header).
Change-Id: Ia61b7678e257c4bc1ff193f3f856d611aa5c1a21
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88854
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
In LOK we use one language identifier for both - UI language and
the locale used. This is a problem when we determine that we a
language for UI is not available and fall-back to the default
"en-US" langauge, which also changes the locale. This introduces
a separate variable that stores the language tag for the locale
independently to the language.
Another problem is that in some cases we don't reset the staticly
initialized data, when the new document is loaded, which is on
the other hand used to define which currency symbol is used as
SYSTEM locale. That can in some cases select the wrong currency
symbol even when we changed the locale to something else. This fix
introduces a reset function, which is triggered on every document
load.
Change-Id: I55c7f467600a832895f94346f8bf11a6ef6a1e49
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89320
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Andras Timar <andras.timar@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89343
Tested-by: Jenkins
|
|
Add a predefined NF_DATETIME_SYS_DDMMYYYY_HHMM format code with
formatindex="50" to all locale data files, which shifts all
reserved area internally generated built-in formats up by one.
Reserved area was filled already so that boundary has to be
increased as well. Add some flexibility for future additions by
setting the new boundary to 65, free first format index to be used
by additional locale data formats is 66 now. Adapt all locales to
the new boundary.
The existing predefined NF_DATETIME_SYSTEM_SHORT_HHMM format code
with formatindex="46" mostly was and is used with 2-digit years
(stemming back from the old binary format and Excel
compatibility), some locales that don't use 2-digit years at all
already defined it to 4-digit years. Keep those but move the
default="true" attribute (if so) to the new "50" format.
Modify populating the format list such that resulting duplicates
will be suppressed there as well.
Also try to match the new format in ODF import if a long year was
requested with date+time.
Finally set the new format as default for all *_IT locales. In
future changing the default date+time format to 4-digit year is
just a matter of moving the default="true" attribute to the new
format.
Change-Id: Ib16aa9fda0e71b2d03f78e3dd013785de03cd288
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89265
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins
|
|
JunitTest and PythonTest modules check for these themself.
Change-Id: Ia453bc99571738b01cc8f161f346cb6c37b2e429
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88832
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
Change-Id: I9a7c98b656c1f9270de5b13f7022d5930a665a4b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88760
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: Ibc231308d0fc93085933ae7d80dc8c4b2699fe02
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88204
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
show Korean Dangi Calendar format
Ref1: MSDN - Calendar IDs
5 : CAL_KOREA
https://docs.microsoft.com/en-us/windows/desktop/Intl/calendar-identifiers
Ref2: stackoverflow
https://stackoverflow.com/questions/54134729/what-does-the-130000-in-excel-locale-code-130000-mean
Change-Id: Ia1f367bfd5c13f29054064d89be847bbf249c0d0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87689
Tested-by: Jenkins
Reviewed-by: Eike Rathke <erack@redhat.com>
|
|
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>
|