I disentangled my previous patch and converted fprintf statements to
SAL_INFOs
Change-Id: I4b993e00f82bdf904586ab5e7c954c4ee3ff1bac
Reviewed-on: https://gerrit.libreoffice.org/22925
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Björn Michaelsen <bjoern.michaelsen@canonical.com>
I replaced OSL_DEBUG_LEVEL > 1 with OSL_DEBUG_LEVEL > 0
and made sure that it doesn't break the build
Change-Id: I9febeed949a24d7bc5afb13dedde03fd812b5b20
Reviewed-on: https://gerrit.libreoffice.org/23077
Reviewed-by: Björn Michaelsen <bjoern.michaelsen@canonical.com>
Tested-by: Björn Michaelsen <bjoern.michaelsen@canonical.com>
I removed the fprintf statements and replaced them with
SAL_WARN statements.
Change-Id: Id75e310e3a95b249fdf92a4dd5a9bcf1b7fb9be6
Reviewed-on: https://gerrit.libreoffice.org/22984
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: jan iversen <jani@documentfoundation.org>
...so no need to add dead log areas here (as questionably introduced with
f59136a2ed1e3eb01cc5b62c5a7da07c34cbdfae "tdf#91794 remove OSL_DEBUG_LEVEL > 1
conditionals")
Change-Id: Id0544a76f9c426bc06e327f0f2ec2d421da1fa50
...and where appropriate use CPPUNIT_ASSERT_EQUAL to have no need to always
print out certain values
Change-Id: Iad2ccb235b09852fffd3f010cf069c45b36e2d4b
stage 2 of replacing usage of various checks for the windows platform
with the compiler-defined '_WIN32' macro
In this stage we focus on replacing usage of the WIN macro
Change-Id: Ie8a4a63198a6de96bd158ecd707dadafb9c8ea84
Reviewed-on: https://gerrit.libreoffice.org/22393
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
stage 1 of replacing usage of various checks for the windows platform
with the compiler-defined '_WIN32' macro
Change-Id: Iece73abdee530937e0737190b1aa97a46cd3075f
Reviewed-on: https://gerrit.libreoffice.org/22390
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
...location." Caused many crashed during "make check", when aLocaleNames is a
sequence of 17 ("ar-SA", "ar-DZ", ...), but aLcoations merely a sequence of 2
(".../dict-ar/ar.aff", ".../dict-ar/ar.dic").
From comments further down below, it looks like aLocations will always contain
exactly two entries ("also both files have to be in the same directory and the
file names must only differ in the extension (.aff/.dic)"), and that all the
aLocaleNames members share the same set of aLocations ("Thus here we work-around
this by adding the same dictionary several times. Once for each of its supported
locales"), so that it would appear to be OK to just check once for the existenceof aLocations[0].
(There is a check for
if (aDictIt->aLocaleNames.getLength() > 0 &&
aDictIt->aLocations.getLength() > 0)
below, so it might be that these can be empty, or it might just be "defensive
programming." Play it safe, and check here that aLocations is not empty.)
Change-Id: I82bea6571983e397a9e164b294a5ba656b511a67
Find a few million mis-predicted branches (according to callgrind)
and annotate them. Mark string acquire/release as hot, and a number of
deprecated methods as cold.
Change-Id: I678b3981794221c97f9ebb70fd0161c0fda5dceb
...in LIBO_INTERNAL_ONLY, __cplusplus, non-MSVC case.
It turns out that sal_Unicode happens to not be mangled into any symbols that
make up the stable URE interface, so (for LIBO_INTERNAL_ONLY, at least) we are
free to replace the typedef to sal_uInt16 with a typedef to any integral type
layout-compatible with that. (sal_Unicode does appear in some symbols in sal's
PRIVATE_textenc.1 section, but that is private between the sal and sal_textenc
libraries, so changing those symbols does not require a change of SONAME.)
C++11 chart16_t is the obvious choice (and will ultimately allow using u"..."
to write literals of type array-of-sal_Unicode). Reportedly, char16_t is
supported since GCC 4.4 and Clang 2.9 but will only be available in MSVC 2015.
For plain C, we continue to use sal_uInt16. We could theoretically use C11
char16_t from <uchar.h>, but at least the Mac OS X 10.11 SDK still does not
offer that C11 header.
For MSVC, we continue to use wchar_t (which is actually unsigned short, due to
/Zc:wchar_t-) for now. Potential options there include dropping /Zc:wchar_t-
and using true wchar_t, or using C++11 char16_t once support for MSVC 2013 is
dropped.
Some code needed to be adapted that was written in a way assuming that
sal_Unicode is unsigned short (which indicates that changing sal_Unicode for
non-LIBO_INTERNAL_ONLY would be an ABI change). OUStringBuffer::append can now
differentiate between being called with sal_Unicode (to append a single
character) and erroneously being called with sal_uInt16 (intending to append a
number's textual representation, for which the sal_Int32 overload must be used
instead). Bugs found are 379fe0409e7973b36210cffa3dd1dfd4032f0ecc "Assume that
this code wants to append a number, not a character" and
dc148335a6a438848325f24c49198fba81043279 "Assume this wants to append the
numerical representation."
The GDB support for pretty-printing of sal_Unicode-related data in
solenv/gdb/libreoffice/sal.py can presumably be simplified now.
Change-Id: I445b3a80e65b7cb004d9e08b38bdc9ee93bc9401
Reviewed-on: https://gerrit.libreoffice.org/20036
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Stephan Bergmann <sbergman@redhat.com>
configure.ac was setting VERBOSE=YES/NO when really
we use verbose=t or verbose=
Change-Id: I47aee8d177cb2d788a62ecdbbb9cc3695c2bb299
Reviewed-on: https://gerrit.libreoffice.org/17634
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Norbert Thiebaud <nthiebaud@gmail.com>
Work in progress to allow integration of LO with
<https://wiki.gnome.org/Projects/FleetCommander>.
During configuration, dconf support is implicitly enabled when available on the
host (which is presumably only available on Linux). It is explicitly disabled
for TDF Linux builds for now, though, to avoid accidental dependencies of the
distributed installation sets on system dconf libraries.
A dconf layer is represented in the CONFIGURATION_LAYERS bootstrap variable with
type "dconf" and an empty URL. See the comment at the top of
configmgr/source/readdconflayer.cxx for the encoding of component-data in dconf.
All of this is still subject to change.
Change-Id: I2d08d81c8ea43ba4a99040a8882ae75b91bcfdb9
Reviewed-on: https://gerrit.libreoffice.org/16848
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...that should have been removed as part of
7196df7ac616be39689f21d8784fd78030868586 "tdf#43157: Enable format check in
sal_detail_logFormat"
Change-Id: I331359bfa0e7c678f662f3de63257ccc0b528484
With 64-bit MSVC, sizeof(long) is 4 but sizeof(void*) is 8, so this
would select sal_uInt64 but SAL_MAX_UINT32.
This should make sizeof(sal_Size) the same as sizeof(size_t) on all
supported platforms, but still sal_Size maps to different integer
type (long vs. int) than size_t on 32-bit.
Change-Id: I638aac6b502e624ed6b01f5921e20bc40f42480c
