...as flagged by -fsanitize=undefined. But is it really undefined?
[conv.double] "If the source value is between two adjacent destination values,
the result of the conversion is an implementation-defined choice of either of
those values." So if the double is between std::numeric_limits<float>::max()
and std::numeric_limits<float>::infinity()...
Change-Id: I6389c8ac4a922991e240638d231dd2a39e173882
remove obsoleted sal-module-internal custom STL allocator
The SAL module avoided the heavy dependency on the stlport4-libraries by using
a custom allocator for its internal STL containers. With stlport4 removed these
dependencies are gone and the SAL-internal custom allocator is obsoleted.
(cherry picked from commit c6e0325df6efce45dbb2616a32b7745c449c6c58)
Conflicts:
include/osl/diagnose.hxx
include/rtl/allocator.hxx
sal/osl/w32/procimpl.cxx
sal/qa/osl/process/osl_process.cxx
sal/rtl/bootstrap.cxx
sal/rtl/source/hash.cxx
sal/rtl/source/unload.cxx
Change-Id: I8515382828eda36aba1fec5f23e0f2a89aef7a33
...which updates RFC 2396, removes the requirement that the base URI's path
starts with a slash, and clarifies how to treat excess "." and ".." segments.
This nicely allows handling of those odd vnd.sun.star.Package URLs as intended
now, so that making <foo> absolute relative to base URL
<vnd.sun.star.Package:Pictures/bar> yields <vnd.sun.star.Package:Pictures/foo>
instead of provoking a MalformedUriException.
Change-Id: Ice84303a57698a2c05d3a45541fe78b67450fa3c
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
This reverts commit 56ff07a795aca516106bfde80cb32860065690a6, the correct fix is
d19598b56c8bec688d1944cd167f32a369344100 "Adapt ImplicitBoolConversion to 32-bit
builds (where sal_Int32 is long)."
3af99e4d59d89c343965a928681a30f36b1007d2 "convert equalsAsciiL calls to
startsWith calls" should rather have converted to oprator ==.
Change-Id: Id4a8836c5d6d570e54661c40be7214632e202b21
A final pass through the code, converting code to use the new
OUString and OString methods that can detect string literals.
Change-Id: Ifa6382335e5650a1c67e52006b26354e0692c710
Convert code like:
aStr.equalsAsciiL( RTL_CONSTASCII_STRINGPARAM( "ActiveConnection" ) )
to
aStr.startsWith( "ActiveConnection" )
which compiles down to the same machine code.
Change-Id: Id4b0c5e0f9afe716a468d3afc70374699848dc33
Document the "calling" macros for the strtmpl.cxx template file.
And remove unnecessary use of those macros in the calling file.
Change-Id: I20e0dd74150773363b9fb557884b84692ce22f11
Reviewed-on: https://gerrit.libreoffice.org/6504
Reviewed-by: Michael Stahl <mstahl@redhat.com>
Tested-by: Michael Stahl <mstahl@redhat.com>
This was the wrong way to fix the problem. The root cause was a static
initialiser in the OpenCL code, and that code should not even have been
built for iOS.
This reverts commit 261f1439e5516f6d60317a675d261af330a9a74c.
