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>
Because I want to make more symbols private, but that runs into a
problem with the special symbol "typeinfo for Foo" which is required for
dynamic_cast.
For clang, we can use SAL_DLLPUBLIC_RTTI to make just that magic
"typeinfo for Foo" symbol visible.
But for gcc, we are left with no option but to make the whole class
visible via <MODULE>_DLLPUBLIC.
(I have a feature request logged against gcc to support something like
that at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113958)
But I also don't want to use <MODULE>_DLLPUBLIC, since that blocks
progress of reducing symbol visibility for platforms other than gcc.
So map SAL_DLLPUBLIC_RTTI to visiblity:default for gcc, which means that
only gcc suffers the negative affects of not having that annotation.
However, that runs into the problem that gcc does not like
visibility:default in a couple of places, so I have to introduce some
extra preprocessor stuff.
Change-Id: Ib4fc5c1d2a1f8cf87d5159a4b5684137ec061605
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164356
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
This effectively reverts 271a663d2f "rtl: support
start/stop threads around pre-init" again, now that
df6ba65046 "Remove 'officially dead now' rtl_cache
slab allocator mechanism" removed the wsupdate thread.
(rtl_alloc_preInit is an internal-use-only C function, so changing its arguments
doesn't affect URE compatibility.)
Change-Id: Ie9bce86377f9520e2600e4111ac525dddace10f8
Reviewed-on: https://gerrit.libreoffice.org/58443
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...after <https://gerrit.libreoffice.org/#/c/58263/> "the custom SAL allocator
is no longer used" got merged. According to my July 31, 2018 comment there:
"However, [...] this change is effectively a final coffin nail for the
'rtl_cache' mechanism. It could be argued that the alleged benefits of that
mechanism (if it were still working) might be real (at least on some platforms;
which would need measurements), and that it should be made working again (by
reverting the effects of both ce906b8096 'skip
tricky allocators on G_SLICE=always-malloc' and
bc6a5d8e79 'Disable custom allocator' on
rtl_cache_alloc/free again). But it could just as well be argued that the
'rtl_cache' mechanism is effectively gone for long enough now (since end of
November, 2017, with bc6a5d8e79 'Disable custom
allocator') without any (apparent) negative consequences, so that it can be
removed for good with this change."
Change-Id: I8c1e45d494fc22555a9e675ab27be9e6e404abde
Reviewed-on: https://gerrit.libreoffice.org/58369
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
rtl_arena_create's quantum_cache_max parameter (when non-zero) would have
allowed an rtl_arena to internally use an rtl_cache for chunk allocation. (And
none of the LO-internal uses of rtl_arena_create makes use of that.)
However, with the combination of old ce906b8096
"skip tricky allocators on G_SLICE=always-malloc" and recent
bc6a5d8e79 "Disable custom allocator", rtl_cache
unconditionally just uses malloc/free now, so the rtl_arena_create
quantum_cache_max feature has effectively become irrelevant. As those changes
appear to have no negative consequences overall (and help remove quite a chunk
of no-longer used code), leave it at that and officially abandon the
quantum_cache_max feature.
Change-Id: I7d186a4a1589db6a73059c2be164aa81d81aef47
Reviewed-on: https://gerrit.libreoffice.org/54388
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Stephan Bergmann <sbergman@redhat.com>
This is necessary to avoid having extra threads
while forking. After forking, the second stage
of pre-init is started and so we start the stopped
rtl threads.
The comment for rtl_alloc_preInit_phase_t has
more details.
Change-Id: I1a3f7be74d4b04d0b2fc4a72b02124c2faa3c047
Reviewed-on: https://gerrit.libreoffice.org/47060
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Change these back to consistently use the "..." form to include other UNO API
include files, for the benefit of external users of this API.
Change-Id: I9c9188e895eb3495e20a71ad44abfa2f6061fa94
...by adding some further SAL_DLLPUBLIC_RTTI type annotations (cf.
b4f6b26b5a "SAL_DLLPUBLIC_RTTI for proper RTTI
visibility for LLVM") and by making sure relevant function types do not use
incomplete types in their parameter and return types (which would make the RTTI
hidden).
Change-Id: Id7aadcbc0704b9759968ae36266fc9ce11a2e340
