Age | Commit message (Collapse) | Author |
|
Change-Id: I124dd9be0ca8ede61323dd77b737253c5af99ceb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95570
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
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>
|
|
to look for the
x.get() != null
pattern, which can be simplified to
x
I'll do the
x.get() == nullptr
pattern in a separate patch, to reduce the chances of a mistake
Change-Id: I45e0d178e75359857cdf50d712039cb526016555
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95354
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
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>
|
|
mostly to catch stuff from the flatten work, but I think this looks good
in general
Change-Id: I7be5b7bcf1f3d9f980c748ba20793965cef957e7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92493
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
...as discussed as an open TODO in the commit message of
fe6cce01c88d045a1fcf09acf049c34c22299b02 "Fix loplugin:simplifypointertobool for
libstdc++ std::shared_ptr". The necessary changes across the code base have
been done fully automatically with the rewriting plugin on Linux. (All those
changes apparently involve uses of macro arguments wrapped in parentheses in the
macro body, but always in conditionally-converted-to-bool contexts. In other
contexts, such automatic rewriting would add the "bool" to the macro body, which
would be wrong in general, but we apparently get away with that sloppy coding
for now.)
The parenExprs_ stack that fe6cce01c88d045a1fcf09acf049c34c22299b02 had
introduced to treat such (then-undetected, it had turned out) parenthesized
cases now turns out to not be needed after all.
Change-Id: I2021f61c2e2805be7e18b38edf8744d186cac3cb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95010
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
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>
|
|
Change-Id: Iab35a8b85b3ba1df791c774f40b037f9420a071a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86708
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
and
cid#1458017 silence Out-of-bounds write
Change-Id: I5411322bca523e5dc55b8df2e7d9261981f504da
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87703
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
cid#1458018 Untrusted loop bound
cid#1242844 Untrusted loop bound
Change-Id: I9062240290708f4b51b0ce42a30897b50d1a2677
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87702
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Ie5a381fc5e5b73490ab8b2036ef2a1164e475e8f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87557
Tested-by: Jenkins
Reviewed-by: Muhammet Kara <muhammet.kara@collabora.com>
|
|
"Find explicit casts from signed to unsigned integer in comparison against
unsigned integer, where the cast is presumably used to avoid warnings about
signed vs. unsigned comparisons, and could thus be replaced with
o3tl::make_unsigned for clairty." (compilerplugins/clang/unsignedcompare.cxx)
o3tl::make_unsigned requires its argument to be non-negative, and there is a
chance that some original code like
static_cast<sal_uInt32>(n) >= c
used the explicit cast to actually force a (potentially negative) value of
sal_Int32 to be interpreted as an unsigned sal_uInt32, rather than using the
cast to avoid a false "signed vs. unsigned comparison" warning in a case where
n is known to be non-negative. It appears that restricting this plugin to non-
equality comparisons (<, >, <=, >=) and excluding equality comparisons (==, !=)
is a useful heuristic to avoid such false positives. The only remainging false
positive I found was 0288c8ffecff4956a52b9147d441979941e8b87f "Rephrase cast
from sal_Int32 to sal_uInt32".
But which of course does not mean that there were no further false positivies
that I missed. So this commit may accidentally introduce some false hits of the
assert in o3tl::make_unsigned. At least, it passed a full (Linux ASan+UBSan
--enable-dbgutil) `make check && make screenshot`.
It is by design that o3tl::make_unsigned only accepts signed integer parameter
types (and is not defined as a nop for unsigned ones), to avoid unnecessary uses
which would in general be suspicious. But the STATIC_ARRAY_SELECT macro in
include/oox/helper/helper.hxx is used with both signed and unsigned types, so
needs a little oox::detail::make_unsigned helper function for now. (The
ultimate fix being to get rid of the macro in the first place.)
Change-Id: Ia4adc9f44c70ad1dfd608784cac39ee922c32175
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87556
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
found by my new aggressive unused var plugin. these are unused return
values from function calls
Change-Id: I3359c583f535828f192cb833762dfedc008d82f0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87439
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I067ea2f3cb651fdc5c3d1a09b0c55583618b9d1f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87355
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ice7c0ecc8ee05a5c3b0af458ceeee8191bdde322
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86752
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I01c4bfadfabce128f1e28b0c871da1722b865b6f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86377
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
This is checked several lines below, with much stricter range.
Change-Id: I3bfaf71f9e40dd1af089ed1ac238bc2939d0fc3a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86392
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: Ideb61209e8795865bce6e0b1d667b34f8a8db4d9
Reviewed-on: https://gerrit.libreoffice.org/85713
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|