| Age | Commit message (Collapse) | Author |
|---|
|
Change-Id: Ie2a6b5e71f76ff2900ff078fcc098e66927458ef
|
|
8f8bc0dcf3bc253ae49159d52db049767f476ced "Move string hash function into String
class" had introduced a new getHash64 that, besides returning sal_uInt64 instead
of just sal_Int32, didn't do sampling of only a handful of characters, but
always computed the hash over all characters (as the usage in SfxItemSet and
SdPage appears to require for either performance or approximated correctness).
However, it would be advantageous to keep the stable URE interface as small as
possible. Now, O(1) sampling was apparently considered state of the art when
the rtl string classes were first created, closely copying java.lang.String,
which at that time demanded sampling for hashCode(), too---but never sampling
more than 15 characters, with the obvious (in hindsight, at least) performance
catastrophes, so they changed it to O(n) somewhere along the way.
Based on that, this commit changes the existing hash functions to not do
sampling any more, and removes the newly introduced -64 variants again. (Where
the extended value range of sal_uInt64 compared to sal_Int32 was hopefully not
vital to the existing uses.)
The old implementation used sampling only for strings of length >= 256, so I did
a "make check" build with an instrumented hash function that flagged all uses
with inputs of length >= 256, and grepped workdir/{Cppunit,Junit,Python}Test for
hits. Of the 2849 hits encountered, 2845 where in the range from 256 to 295
characters, and only the remaining four where of 2472 characters. Those four
were from CppunitTest_sc_subsequent_filters_test, importing long text into a
cell, causing ScDocumentImport::setStringCell to call
svl::SharedStringPool::intern, which internally uses an unordered_set. These
results appear to justify the change.
Change-Id: I78fcc3b0f07389bdf36a21701b95a1ff0a0d970f
|
|
Change-Id: I071a931660dafc1ee5950da527b042fb175255b8
|
|
hashCode() seems to do sampling while creating the hash.
hashCode64() will not.
Change-Id: Id30f5a2a774cf5244dbc00da9649e95a532484be
|
|
Change-Id: I266d5cf5b98827617f7ed65c94a772e28808f386
|
|
It is probably best to base the functions on Unicode code points instead of
scalar values, now that they are also used from sal/rtl/strtmpl.cxx with UTF-16
code units and with arbitrary bytes (with values assumed to be a superset of
ASCII, though). Rename compareAsciiIgnoreCase to compareIgnoreAsciiCase. Also,
the corresponding tools::INetMIME functions can be removed completely; no need
to keep them around as deprecated.
Change-Id: I8d322177f4909e70a946e8186e3e0f7fa6d9a43e
|
|
Also remove all others implementations.
Change-Id: I1dc108a9103f087bd8ce591dff2ac5dd254746f8
Signed-off-by: Stephan Bergmann <sbergman@redhat.com>
|
|
as flagged by Clang -fsanitize=undefined
Change-Id: Iff1aa4473d960009890b923fba734257ecd8b3ef
|
|
...as its assert requires that both input characters are ASCII, which need not
be the case in these compareIgnoreAsciiCase functions. (Even if they take one
literal argument that must be strictly ASCII, the other argument can be an
arbitrary Unicode string in the case of OUString or an arbitrary 8-bit string in
the case of OString).
The logically correct version of rtl::compareAsciiIgnoreCase would arguably be
one that requires its two arguments to be valid UTF-32 code units, but that
could not be used in these places either, as for OUString they operate on
individual UTF-16 code units.
rtl::compareAsciiIgnoreCase likely makes less sense after all than assumed in
c8e39e66528affb66f1ae121fa36dd4ab31a9b0b "Introduce rtl::compareIgnoreCase and
deprecate rtl/character.hxx equivalents," which this commit partly reverts.
Change-Id: Ib2eed3a1896e83d9c66b0479a03f9ec51e1c4dc0
|
|
Change-Id: Id90935fd2b0f904f89477792edc8140cfc31e91f
Reviewed-on: https://gerrit.libreoffice.org/5412
Reviewed-by: Petr Mladek <pmladek@suse.cz>
Tested-by: Petr Mladek <pmladek@suse.cz>
|
|
...which has become necessary since bd60d41176da540b01d7583cfe00637431967f39
"Handle oveflow in O(U)String::toInt() functions" reduces values in the range
(SAL_MAX_INT32 .. SAL_MAX_UINT32] to zero, but some calls of toInt32(16) relied
on getting a correct (unsigned) value for the whole input range ["0" ..
"FFFFFFFF"] (see libreoffice-4-1 commit 9bf6c83367cedb7be81bf67f30d2147d26c7a8c3
"Revert overflow checks in O[U]String::toInt{32,64} again").
Audited all uses of toInt32/64 with non-decimal radix. (There is still a TODO
comment in oox/source/helper/attributelist.cxx, and
stoc/source/typeconv/convert.cxx will still need some love and test code.)
Change-Id: Iadaca1c0e41dab553687d0ce41c20c10cd657a95
|
|
Change-Id: I43262c984c311fcb1e1a9eca9b4dec4092351dea
|
|
...for negative integers in < C++11? Rather unlikely, but lets see...
Change-Id: I9abfcbf2c0e409fab4c77b62e5f734d3c2cc2719
|
|
Return 0 when overflow.
The base idea in unsigned case is checking wheather
(Max-nDigit)/nRadix < n
But for efficency, take out nDiv = Max/nRadix from loop
and corrigate it with -1 if needed.
In signed case use minimum value if the number is negativ.
Change-Id: I5b77580adbf12421b6c4b785ba9bc2a080accba2
Signed-off-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Iaefddeb816d36d4a07234d903fafab3d6b83e1d2
Reviewed-on: https://gerrit.libreoffice.org/2952
Reviewed-by: Thomas Arnhold <thomas@arnhold.org>
Reviewed-by: Thorsten Behrens <tbehrens@suse.com>
Tested-by: Thorsten Behrens <tbehrens@suse.com>
|
|
Change-Id: I03de46fb6c095bb176fd25fc5f803be6d2d89bcf
|
