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/47060Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>

Implement it as a user-defined Blob subtype.

Change-Id: Ia369b6858e7d9191f34032445c1003931273e926
Reviewed-on: https://gerrit.libreoffice.org/47098Reviewed-by: Tamás Bunth <btomi96@gmail.com>
Tested-by: Tamás Bunth <btomi96@gmail.com>

Change-Id: I0a8579406a70d2f63d96969c766e2a43d830ed6f
Reviewed-on: https://gerrit.libreoffice.org/47114Reviewed-by: Tamás Zolnai <tamas.zolnai@collabora.com>
Tested-by: Tamás Zolnai <tamas.zolnai@collabora.com>

We need to check read only mode similar to SidebarController::CreatePanels()
method. Otherwise SfxUnoPanels::getByName() creates an invalid panel.

Change-Id: Ib7801b81c95f3f505a06c00f749ba4ed5809bfe0
Reviewed-on: https://gerrit.libreoffice.org/47116Tested-by: Xisco Faulí <xiscofauli@libreoffice.org>
Reviewed-by: Tamás Zolnai <tamas.zolnai@collabora.com>

...after 6a312a4a "Prepare external/firebird for
sanitizers".  Doing `make check screenshot` on Linux with Clang
-fsanitize=undefined -fsanitize=local-bounds -fsanitize=nullability works now.

Patches that might be unwanted in non-UBSan builds are added to sanitizer.patch
while unproblematic ones are added to always-included ubsan.patch.

CppunitTest_dbaccess_firebird_test, e.g., shows that
comphelper::AsyncEventNotifierAutoJoin::onTerminated called base-class
osl::Thread::onTerminated (which does nothing, anyway) of an already destroyed
object, so just drop that.

Change-Id: If50f442ee6dbe590db843c38681d1c1cade8fa6a
Reviewed-on: https://gerrit.libreoffice.org/47122Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>

ImplFontCache::Invalidate deletes unused entries (with zero ref
count), and keeps other entries, but clears everything (including
still used fonts) from its instance list. In the same time, those
fonts' mpFontCache pointers kept pointing to this cache object.
External clients released font instance by calling its cache's
Release method; this itself allows for broken invariants that
cache's mnRef0Count is equal to number of unused font instances
in its list. Also, those fonts never got released, leaking because
ImplFontCache only ever deletes objects in its list.

What is worse, sometimes font caches get deleted after invalidation
(see OutputDevice::ImplClearFontData). As the instance list of the
cache is empty at the point of delete, the cache destructor doesn't
delete those fonts that were orphaned at the moment of invalidation
(those fonts are still used by some client objects, so deleting
them is clearly wrong). But since the font instances still have
cache pointer referring the already deleted cache, releasing the
instances (by calling deleted cache's Release member function)
must lead do some weird results.

This patch moves the Acquire/Release to LogicalFontInstance, which
now checks if its cache pointer is valid, and if it is, the cache
is used to do the work (as before); otherwise, the font handles
its lifetime itself, and deletes itself when its reference counter
is zero. The cache invalidation clears the cache pointer of the
still-used instances.

Change-Id: I29811272dda814cbc81f14668d63e385ce772332
Reviewed-on: https://gerrit.libreoffice.org/47111Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>

Change-Id: I209c6d62c2e5cfbc6a35da406bc59fc155787ec9
Reviewed-on: https://gerrit.libreoffice.org/47127Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Julien Nabet <serval2412@yahoo.fr>

Change-Id: I6aba5b79e588f28529052ddb30ad51807d73cfe5
Reviewed-on: https://gerrit.libreoffice.org/47120Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>

Change-Id: I435524d1852a6691b382b93c9b6d2a7705938cd7
Reviewed-on: https://gerrit.libreoffice.org/47130Reviewed-by: Tamás Bunth <btomi96@gmail.com>
Tested-by: Tamás Bunth <btomi96@gmail.com>

Create a more effective implementation of XClob::length() and
XClob::getSubString() methods, where string is read segment-by-segment
instead of reading the whole underlying blob. That way it is possible to
handle big texts which would not fit into memory.

Also allow reading Clob data from a resultset with getString() and
writing it in a prepared statement with setString().

Implement XPreparedStatement::setClob(). Also implement a private
version of setClob() for creating a clob from OUString:

Allow the creation of a clob column with GUI by adding a new type in
ODataBaseMetaData::getTypeInfo().

Change-Id: Ibcbbdd80e8eed5e2a3fe55b0fa196401f1bcbcdf
Reviewed-on: https://gerrit.libreoffice.org/47093Reviewed-by: Tamás Bunth <btomi96@gmail.com>
Tested-by: Tamás Bunth <btomi96@gmail.com>

Change-Id: I9a1b3aa9bde855577078fe0db2e31a9c160031d7
Reviewed-on: https://gerrit.libreoffice.org/47092Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Tamás Bunth <btomi96@gmail.com>

There is no explicit binary type in Firebird. It can be accomplished
using the CHAR type with a special character set, which tells the
database that it is binary data and there is no collation. (called
OCTETS).

Because of that, we also need the character set to decide the exact
column type.

And also refactor some parts of the driver:
- Create class to determine internal type from firebird type, subtype,
scale and character set.
- Use internal type (DataType::XXX) in XDatabaseMetaData::getTypeInfo()
indirectly. (We want to return a Firebird type for each internal type,
not in the opposite direction.

Change-Id: Ica56a84d89253e11936e7012086fe1d9f61a65f0
Reviewed-on: https://gerrit.libreoffice.org/47091Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Tamás Bunth <btomi96@gmail.com>

Change-Id: Icec98d35c2f60adf4a31e492c6cb708e82e47a58
Reviewed-on: https://gerrit.libreoffice.org/47080Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Julien Nabet <serval2412@yahoo.fr>

Just in case we are called by code not checking our DatabaseMetadata
to learn we don't support multiple resultsets.

Change-Id: I6d8c5f4ef04bcd9ec8b66a83881607281e125b7b
Reviewed-on: https://gerrit.libreoffice.org/47117Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>

the previous test didn't make any sense:
 * if xMeta.is(), then the test evaluated to false
 * if !xMeta.is(), then it called supportsMultipleResultSets
   (or supportsBatchUpdates, respectively) on a NULL pointer,
   which guaranteed a segfault / assert.

Change-Id: I6d6b93350557936b924a286732ae6d4f5ab2ce56
Reviewed-on: https://gerrit.libreoffice.org/47118Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>

and perhaps avoid memory leaks (see https://bugs.documentfoundation.org/show_bug.cgi?id=114457)

Change-Id: Ib413b0bf6cc65a2696e3429965a67899b7b72d73
Reviewed-on: https://gerrit.libreoffice.org/47094Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>

Change-Id: Ib16168c0b87c99bceae3970b739aaba1667b154b
Reviewed-on: https://gerrit.libreoffice.org/47115Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>

Change-Id: I93b3e2dde7be65d2077e386b8f80ae7c3576c788
Reviewed-on: https://gerrit.libreoffice.org/47102Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Tamás Zolnai <tamas.zolnai@collabora.com>

When inserting a new document into current position we need to
concat to lists into one.

Added unit test.

Change-Id: I10689256e0ffc5cf93722b1d45f09f610211b14a
Reviewed-on: https://gerrit.libreoffice.org/46978Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>

Change-Id: Ib61656913df673ebfde61e2c921f84cb81195a3b
Reviewed-on: https://gerrit.libreoffice.org/46974Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Katarina Behrens <Katarina.Behrens@cib.de>

Change-Id: Icebbbb392d9187a11837b72116c00036247e9b74
Reviewed-on: https://gerrit.libreoffice.org/47104Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Julien Nabet <serval2412@yahoo.fr>

Change-Id: Idc2b686f754afe4708c15fefcda44b7c7742a2e9
Reviewed-on: https://gerrit.libreoffice.org/47097Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: andreas_kainz <kainz.a@gmail.com>

Change-Id: I7bd257734a302ad00acf4336f4b478d6af4bc304
Reviewed-on: https://gerrit.libreoffice.org/47100Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>

Change-Id: I89a24fa3ce4034ef207233b96c5e26a7b7787444
Reviewed-on: https://gerrit.libreoffice.org/47096Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>

Project: help  dfdc1f55f63d4497e6bd5fa5793ba8b57d6a78fc

tdf#112755 reorder modules in new help (II)

reorder modules in Index

Change-Id: Ib226a7c243e682e4e2a98d6d48ae1d9b1e3cace1
Reviewed-on: https://gerrit.libreoffice.org/47095Reviewed-by: Olivier Hallot <olivier.hallot@libreoffice.org>
Tested-by: Olivier Hallot <olivier.hallot@libreoffice.org>

We need to export 0 padding explicitely to DOCX file.

Change-Id: I7126cfd1dbf4ebd1fb5e09c3642e0da159488258
Reviewed-on: https://gerrit.libreoffice.org/47090Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Tamás Zolnai <tamas.zolnai@collabora.com>

Change-Id: I74e065b8ba00dc80559bb64cf1bdefa5f9f5b480

Change-Id: I25df3a06afa5e1eb2fa282f2be2ae1ea69aa0ab5
Reviewed-on: https://gerrit.libreoffice.org/47077Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>

Change-Id: I5725602be8a3da8e58a6885f64a7b720061c11ce
Reviewed-on: https://gerrit.libreoffice.org/47085Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>

Change-Id: Ied4f0a548b303aac86052df58f9a81fddeab7b06
Reviewed-on: https://gerrit.libreoffice.org/47086Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>

Change-Id: Ia917b70712717387aa8d7a17334efd41931bdb88
Reviewed-on: https://gerrit.libreoffice.org/47087Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>

Change-Id: I1617900cd2df096d46a2cba75ef2fe1373c0ab63
Reviewed-on: https://gerrit.libreoffice.org/46948Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>

Change-Id: I640bf41ad073fcf1d5b8fcc55c63558f208db73d

Change-Id: Icede71af1edfc0671f5b0bc0dbfd3cfc6af79fcd

Change-Id: I2b420141b5986b1d23460d5432c1b7051b11663e

Change-Id: I4a0e55818ad8e2f61845484a71b6283e0a7c326a

Change-Id: I09ce2859f7bda468399629fda1336788ed65bcb2

Change-Id: Ia6ee42c799e566ad837e89d6456c50c7217da1eb

After emplace_back there are at least 2 elements, and GetPrevPos
would point to previous back().
Commit 5e913234 removed
a possible modification of such data, so this operation is now
pointless.

Change-Id: Ia5bec5e9b16e9dc9f34c7cf1dbb8e3f17510d83b

Change-Id: Id86d66738da2f6e4b86d4a4ee8da54940c751787