fast_float implements C++17 from_chars for floating-point types, which
is still unavailable even in the latest versions of compilers e.g. for
macOS. It is maintained, unlike dtoa; it is said to be adopted as the
from_chars implementation for gcc. It is header-only, which simplifies
many things.
Change-Id: I6b597d4d35a076930e6e35f4f8cff3ca84f48ba1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/191248
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
A number of places that #include <Carbon/Carbon.h> don't actually
need it, but want CoreFoundation or other includes instead. We're
trying to get rid of Carbon so let's make it clearer what really
needs it still.
Change-Id: Ief60b4324dccd936aa7def3ea2c685c393f9050a
Signed-off-by: Dan Williams <dan@ioncontrol.co>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/191030
Reviewed-by: Patrick Luby <guibomacdev@gmail.com>
Tested-by: Jenkins
This is a combined cherry-pick of the 10 commits
34f1a750a128e02aa3191e36a2c0b28371e96287 "sal: initial osl::File sand-boxing
commit for Unix.", 55243a397add76fcff8c67284ba57205a1512ca5 "lok: import allowed
paths from the SAL_ALLOWED_PATHS.", 148915ef6d4bfc38deb6d98fb14429d7e6e27129
"sal: osl::File allow to create files in sandbox",
479e2f5cb69ceef2ef6832630a342d7673d6782a "unconditionally include vector",
f04d38d5a88f422b80d2a37d1a1252ce59c4f892 "Fix SDK build",
52e0838a8f35837a92e7b0277544995e477fe8b6 "sal: fix various clang loplugin
warnings", 3ed325340d14cb28602fb03eb6a46b37cdb8bb99 "[loplugin:unreffun]",
242ccc31d5a2c8be900828523de145e173900514 "Avoid extending the sal UNO API",
3c633a88c5212d8dd665d7bcb9678fa1eac1464f "Stick to sal_uInt32 for
osl_File_OpenFlags", and f4d48ac9cdb822e2c2d3fc1f239fe0958f608cc2 "Fix linking
new CppunitTest_sal_osl_file_details on macOS/Windows".
Co-authored-by: Andras Timar <andras.timar@collabora.com>
Co-authored-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Co-authored-by: Michael Meeks <michael.meeks@collabora.com>
Co-authored-by: Mike Kaganski <mike.kaganski@collabora.com>
Co-authored-by: Miklos Vajna <vmiklos@collabora.com>
Co-authored-by: Szymon Kłos <szymon.klos@collabora.com>
Change-Id: I5220bef367350d8fac8c25d7f40988664b9a8bd5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/187411
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@collabora.com>
... using a static thread_local variable, as already was used on Windows;
this replaces the non-Windows implementation based on pthread_setspecific
and friends.
Change-Id: Iba42510dea90a9e7d1983ba4af674667055f6dfc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/147624
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
And not just Android. Hardcoded to return "/instdir" to match what is
in the emscripten_fs_image.
Change-Id: I26d4ec5e02ec9900e35ca47f1565a13ad2b723b6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144849
Tested-by: Jenkins
Reviewed-by: Tor Lillqvist <tml@collabora.com>
This header-only library is accurate in decimal representation of
doubles; provides API that allows to create custom representation
- so it's possible to use custom decimal separators and grouping.
This allows to unify all corner cases: integers, numbers close to
DBL_MAX, up-rounding to the next decade.
Note that Dragonbox creates the shortest decimal representation
of the number, that is unambiguously convertible back to the same
number; thus it may hide trailing digits that are unneeded for
such conversion.
The functional changes are minimal, and beneficial:
1. Rounding numbers close to DBL_MAX now takes into account the
bEraseTrailingDecZeros argument, as it should, allowing to have
"1.8E+308" for rounding DBL_MAX to 2 decimals without trailing
zeroes, instead of previous "1.80E+308".
2. Incorrect rounding is fixed in some cases, e.g. 9.9999999999999929
rounded to 10 previously using rtl_math_DecimalPlaces_Max.
3. Representing the number in the shortest way may change display
of some printed numbers. E.g., 5th greatest double is represented
as "1.797693134862315E+308" instead of a bit longer, but giving
the same double on roundtrip, "1.7976931348623149E+308". This would
generally look better for some numbers similar to the famous 0.1,
where users would likely expect more "round" representation where
it's unambiguous (but we still truncate to 15 significant decimals
anyway - so there's no point in pretending to provide exact digits
for actual binary representation).
These are reflected in the unit tests affected by the change.
Change-Id: I05e20274a30eec499593ee3e9ec070e1269232a2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129948
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Drop Build prefix and settle on Lib and Exe prefixes. Also add a
note about the "else" part of the condition and fix offenders.
While at it, define COND_LIB_SAL_TEXTENC to be used by sal to
prevent diverting coditions in build and cxx code.
Change-Id: I944587ca1ccbe46b765d1a631a7214c8126fe951
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128136
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
Improve robustness by testing explicitly; instead of assuming based on
the OS, test first the libc and then test for libexecinfo.
The assumption was wrong for FreeBSD (included since 2017) and for
musl-based systems (not in libc).
Also, remove INCLUDE_BACKTRACE and clean up a bit.
Ref: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220271
Change-Id: Ib4b7fd4fe2cdf5f76babe47a21bd2990fcf42649
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127538
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
That flag is only supported by clang-cl, not by MSVC, and
c7c9f3f57a "use clang-cl's -Zc:dllexportInlines-
for clang-cl builds" apparently naively assumed that it would work to build LO
with clang-cl and that flag without actually trying it out, and
1040228c35 "My clang-cl build does not work with
-Zc:dllexportInlines-" effectively disabled it completely.
The way to avoid unresolved external symbols during linking of URE libraries
(see the 1040228c35 commit message) is apparently
to also build libraries that the URE libraries depend on with the flag, hence
the change from gb_Library_set_is_ure_library to
gb_Library_set_is_ure_library_or_dependency. For now, I only marked those
additional libraries (unoil and xmlreader) that actually caused issues when
linking the URE libraries.
Change-Id: I3a85c73246250981cd86b7ee41f87b41f393a4b1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126012
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
Tested-by: Jenkins
This is clang-cl's equivalent of -fvisibility-inlines-hidden,
and it seems to be also sort of the equivalent of MSVC's
-Zc:inline. So it saves build time and disk space.
Clang docs say that this is binary compatible in only one
direction, so our public C++ code shouldn't be using this,
as external C++ code could try to use exported inlines
that are no longer there.
Change-Id: Ie6217808f8ee4a15344183abfc65038e1558d1b0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122352
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
They compute the same thing, only zlib can do it four bytes at once.
Since crc32() is used when loading documents, with larger documents
this is a difference than can be measured (not much, but a couple
percent of loading time). And we already depend on zlib anyway.
Change-Id: I65c5a1f050af717a5a2d6e334e216d42c4e4dbbb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110651
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
_CRT_NON_CONFORMING_SWPRINTFS is unconditionally defined in
solenv/gbuild/platform/com_MSC_defs.mk, anyway
Change-Id: I43eabc460dfe3ec9e86ec255f0b100eb22166864
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101696
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Size of buffer on stack is 256 characters. Logging function usage
in make check, of >1 100 000 invocations, the longest string was
80 characters, average being 4.6 characters. So heap allocation
is unlikely in scenarios with intensive function usage.
Several existing unit tests had to be fixed. Usually, the change
is either minimal or getting closer to what Excel returns (for
Calc tests). But in case of AMORDEGRC, I had to change rate value
passed to the function from 0.3 to 0.31. It's because the closest
double value for 0.3 is 0.29999999999999999, which is a bit less
than 0.3; multiplied by 1.5, this gives 0.44999999999999996, and
then rounding the result of multiplication of the latter by cost
gave the result 1 less than before, when 0.3 was imported as
0.30000000000000004. Now the function returns a value 1 less than
Excel for that set of arguments. I don't see how to fix that.
Having rate slightly different gives consistent result between
Calc and Excel.
Change-Id: Icae5ce374fe0c31a1aa10cee815e65ef0014f382
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89422
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
After 1928ced074 "Blind fix for Android", tb24
still fails with
> Linking obj/local/armeabi-v7a/liblo-native-code.so
> /home/android/lo/master-android-arm/instdir/program/libsofficeapp.a(sofficemain.o):sofficemain.cxx:function soffice_main: error: undefined reference to ´sal_detail_initialize´
> clang++: error: linker command failed with exit code 1 (use -v to see invocation)
Lets see if including sal/osl/unx/salinit.cxx in ANDROID/iOS builds works (even
if the contents is not normally used there, including it should be harmless).
Change-Id: Ifa38af8f5217a17d3ac74851b46bdb3b50cd4efd
Reviewed-on: https://gerrit.libreoffice.org/78325
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...that involves adding a second, one-off special meaning to the existing
sal_detail_initialize function. This at least gets rid of the
"osl_getExecutableFile contains 'soffice' substring" guesswork (and of the
osl_systemPathGetFileNameOrLastDirectoryPart call there, which is what I'm
actually after, for a different change to come).
Change-Id: I4dd6eef1fd0411bf66943ffea415876c92d08526
Reviewed-on: https://gerrit.libreoffice.org/78291
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Building against libstdc++ effectively always requires -pthread anyway (as
various standard C++ headers require it, see the comment added to
solenv/gbuild/platform/unxgcc.mk), so many explicit uses of -pthread/-lpthread
can be removed.
Doing a (partial) test build on Linux with Clang -stdlib=libc++ suggests that
libc++ indeed doesn't need -pthread as libstdc++ does.
The remaining uses of -pthread/-lpthread are mostly in configure.ac for the
various BSDs (which somebody else might want to clean up now), and related to
external projects. I tried to be careful to remove -pthread/-lpthread from
makefiles only when C++ object files are involved (so -pthread will now be
included on the link command line by default).
Change-Id: I936e082839cb9a434bd273ce5a1f187a4245dfa1
Reviewed-on: https://gerrit.libreoffice.org/71291
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
We don't need the dynamic load complexity for these now with baseline
Windows version being Windows 7 SP1. Stuff used only for compatibility
with older versions was dumped.
Change-Id: I810f271796cfd875cfa18a3081c9ad444fe57b3e
Reviewed-on: https://gerrit.libreoffice.org/70321
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
This gets rid of the horrible hack in gbuild.mk to accomodate the
case-incorrect iOS platform makefiles that cannot be renamed without
upsetting git on file systems that sadly lack the case sensitivity
feature.
Keep the macro defined to IOS though.
Change-Id: I1022bfef4900da00e75fc1ccce786b20f8673234
Reviewed-on: https://gerrit.libreoffice.org/62705
Tested-by: Jenkins
Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Tested-by: Tor Lillqvist <tml@collabora.com>
...with new configuration option --enable-cipher-openssl-backend
rtl/cipher.h (which is part of the stable URE interface) offers functionality to
en-/decrypt data with Blowfish in ECB, CBC, and streaming CFB mode, and with RC4
(aka ARCFOUR; which is a stream cipher). LO itself only uses Blowfish CFB and
RC4, so only those are wired to OpenSSL for now, for simplicity. Using Blowfish
ECB and CBC, or Blowfish CFB in DirectionBoth mode would cause failures for now
(cf. sal/qa/rtl/cipher/rtl_cipher.cxx); the assumption is that no external code
actually makes use of this functionality.
Using NSS instead of OpenSSL could be an alternative, but there appears to be no
support in NSS for Blowfish in streaming CFB mode, only CKM_BLOWFISH_CBC for
CBC mode.
Change-Id: I0bc042961539ed46844c96cb1c808209578528a0
Reviewed-on: https://gerrit.libreoffice.org/59428
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
ever since commit bc6a5d8e79
Date: Wed Nov 15 16:52:44 2017 +0530
Disable custom allocator
which makes FORCE_SYSALLOC redundant
which makes SYS_ALLOC redundant
Change-Id: I42e1d651473e7601e2280d9fb0662c89808c88f6
Reviewed-on: https://gerrit.libreoffice.org/58263
Tested-by: Jenkins
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
LibreOffice uses its low-level API to look up files inside the app
bundle thousands of times, all the time, and especially when starting
something. Both when the process starts, and when a specific aspects
of the application starts (like after typing a first character into a
Writer document in a session). Having all those, too, go through this
alias (bookmark) resolve dance is just insane. There won't be any
aliases (bookmarks) there.
This shaves almost a second from the delay after typing the first
character into a Writer document in a session. There is still a
noticeable delay left, though, likely mostly caused by Python
(Lightproof) initialisation slowness. (It's cross-platform.)
I would say that it is a bit questionable whether the
macxp_resolveAlias() functionality is worth it at all, even.
Change-Id: I2461141c6b58738befd0db4902eb25e63b788b79
When it was originally added to --with-alloc (tcmalloc:
f63ffaf366,
54efc5ed83,
0abd71b441708b6d4246 "INTEGRATION: CWS configure14: #i59160#
allow usage of tcmalloc and system-malloc"; jemalloc:
826a90d68a "configure25: #i111045# jemalloc"), the
old build system's solenv/inc/unxlng*.mk added corresponding -l switches to
linker command lines, but it appears that was never carried over into the new
build system.
And even if the AC_CHECL_LIB calls in configure.ac prior to
e612f026de "Ensure AC_CHECK_LIB/AC_SEARCH_LIBS do
not poison LIBS" would have extended LIBS with the correpsonding -l switches,
there appears to be no mechanism in the new build system that would have
depended on letting that have any effect on which alloc lib to link against.
So the only remaining effect of --with-alloc={tcmalloc,jemalloc} is to set
FORCE_SYSALLOC in Library_sal.mk, same as --with-alloc=system does. So whoever
still uses the former configure switches should just switch to the latter.
(Also adapt the documentation of --with-alloc to reality, "internal" instead of
"oo".)
Change-Id: Iac0e302c5f9602daf5f8452a0fc1887dc55ee27b
Reviewed-on: https://gerrit.libreoffice.org/47178
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...and fix any ensuing errors/warnings, but no further C++'ification. Not sure
whether any parts of dllentry.c would need to be extern "C", so leaving that one
alone for now.
TODO: Put definition of _CRT_RAND_S into bin/update_pch, so it doesn't get
removed again from sal/inc/pch/precompiled_sal.hxx. (For the surrounding #ifndef
see 244d22a3d2 "Work around -Werror,-Wunused-macros
with clang-cl".)
Change-Id: I2ada3717845eb0be0c559465d68e00e3a7720156
Reviewed-on: https://gerrit.libreoffice.org/34860
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Stephan Bergmann <sbergman@redhat.com>
Currently LFS_CFLAGS are only used in a handful of libraries but there's
no obvious reason why it can't just be set everywhere.
Also set it in windows.mk, i have no idea if it's needed for MinGW
(certainly not for MSVC).
Change-Id: I5f62e3011c2089abbf5539fc54c7ff10e07b1599
remove <boost/noncopyable.hpp> in pch and
remove boost from makefile if it was the only boost entry.
Change-Id: Icb945ae59c137571f4f63807601738eea5c3e831
Reviewed-on: https://gerrit.libreoffice.org/24061
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
...in certain Windows build environments (whatever it is exactly that causes
some Windows builds to fail with "error C3861: 'InetPtonW': identifier not
found" while others succeed). Unclear what the original reason was for setting
_WIN32_WINNT here, but removing it hopefully does not break anything.
Change-Id: I83222ad010d428cf2b9c447760ea47381552d04a
The ../../../program/ links in the URE jar Class-Paths are a temporary kludge
(and juh.jar had lacked adaption for Mac OS X).
Change-Id: I2542d8a582866485dd61c05df3fc6b4b39a8403d
shlok3640