...after 6fce450b8a "Introduce "..."_tstr as a
companion to "..."_ostr/u"..."_ustr in template code" had introduced it for
exactly this piece of code
Change-Id: I767a9f39456d6c58c5ac0478110a0c66434b0e54
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/196626
Reviewed-by: Stephan Bergmann <stephan.bergmann@collabora.com>
Tested-by: Jenkins
so I can more readily distinguish between functions that are actually in
the OSL API and functions that are not
Change-Id: Ie113c30ea15d05457633396d56bca08057e38b60
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134800
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
...to make those char class array initializations more readable. (Making the
corresponding variables constexpr is mostly done so that failures in the
provided `unencoded` arguments, like non-ASCII characters or duplicate
character typos, would lead to compile-time errors also for !HAVE_CPP_CONSTEVAL.
And assigning to a sal_Bool std::array needs another hack to avoid false
loplugin:implicitboolconversion warnings.)
Change-Id: Ieb8827f69f55f1212a9428817d5331fcb18ef1d8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133058
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...which was already obsolete at least back in
84c4489cb7 "#104563#moved parts of file.c into
separate files" (where the hack had already been commented out) and should have
been removed in e7982510d2 "osl: cleanup
file_url.cxx" (which removed the commented-out code)
Change-Id: I9fed1c594ff5180979bab7f3f8d7808c941a4ea8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114330
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Similiar to afc41a467f ,
don't call getaddrinfo in getLocalHostname which calls DNS.
This causes a lag when creating the lockfile on opening a document
if the network is flaky/disabled.
See tdf#97931 and tdf#47179 for some problems caused by this.
For the one case where it is expected to call DNS, add a separate function
to restore the old behavior.
The (semantic) [API CHANGE] is in osl_getLocalHostname,
it does no longer return a FQDN.
Change-Id: I43455715a474ff6770351d1ce007c28aeb08f32e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107554
Tested-by: Jenkins
Reviewed-by: Samuel Mehrbrodt <samuel.mehrbrodt@allotropia.de>
"Find explicit casts from signed to unsigned integer in comparison against
unsigned integer, where the cast is presumably used to avoid warnings about
signed vs. unsigned comparisons, and could thus be replaced with
o3tl::make_unsigned for clairty." (compilerplugins/clang/unsignedcompare.cxx)
o3tl::make_unsigned requires its argument to be non-negative, and there is a
chance that some original code like
static_cast<sal_uInt32>(n) >= c
used the explicit cast to actually force a (potentially negative) value of
sal_Int32 to be interpreted as an unsigned sal_uInt32, rather than using the
cast to avoid a false "signed vs. unsigned comparison" warning in a case where
n is known to be non-negative. It appears that restricting this plugin to non-
equality comparisons (<, >, <=, >=) and excluding equality comparisons (==, !=)
is a useful heuristic to avoid such false positives. The only remainging false
positive I found was 0288c8ffec "Rephrase cast
from sal_Int32 to sal_uInt32".
But which of course does not mean that there were no further false positivies
that I missed. So this commit may accidentally introduce some false hits of the
assert in o3tl::make_unsigned. At least, it passed a full (Linux ASan+UBSan
--enable-dbgutil) `make check && make screenshot`.
It is by design that o3tl::make_unsigned only accepts signed integer parameter
types (and is not defined as a nop for unsigned ones), to avoid unnecessary uses
which would in general be suspicious. But the STATIC_ARRAY_SELECT macro in
include/oox/helper/helper.hxx is used with both signed and unsigned types, so
needs a little oox::detail::make_unsigned helper function for now. (The
ultimate fix being to get rid of the macro in the first place.)
Change-Id: Ia4adc9f44c70ad1dfd608784cac39ee922c32175
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87556
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
found by the simple expidient of putting asserts in
the resize routine. Where an explicit const size is used,
I started with 32 and kept doubling until that site
did not need resizing anymore.
Change-Id: I998787edc940d0a3ba23b5ac37131ab9ecd300f4
Reviewed-on: https://gerrit.libreoffice.org/81138
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
The idea is to internally in sal/osl/unx/ use OString instead of OUString to
represent pathnames, so that the OString carries the actual bytes that make up
the pathname. At the boundary of translating between pathname OStrings and file
URL OUStrings, translate sequences of bytes that are valid according to
osl_getThreadTextEncoding() into UTF-8 and translate other bytes into individual
(percent-encoded) bytes in the file URL.
This change required duplicating some of the internal functionality in
sal/osl/unx/ for both OString and OUString, and to make part of sal/rtl/uri.cxx
accessible from sal/osl/unx/ via new sal/inc/uri_internal.hxx.
Change-Id: Id1ebaebe9e7f2d21f350f6b1a07849edee54331f
Reviewed-on: https://gerrit.libreoffice.org/78798
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...where <hostname> matches whatever osl_getLocalHostname reports. (And, for
simplicity, don't support variations where e.g. one of the two FQDNs has an
optional final dot while the other has not.)
(It is not clear to me whether a similar change should also be done for the
Windows-specific code in sal/osl/w32/file_url.cxx. On Windows, file URLs with a
host component are generally interpreted as UNC pathnames, and in some local
test on a Windows 8 machine whose hostname is reported as "win8", passing a URL
like <file://win8/Users/me/Documents/...> (i.e., without a C: drive letter) to
LO already worked to access files on the default drive C: at least.)
Change-Id: I7a69b6d4ca76a71223def7b90d7c3b8b731ee86d
Reviewed-on: https://gerrit.libreoffice.org/67437
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
run it against sal,cppu,cppuhelper
I had to run this multiple times to catch all the cases in each module,
and it requires some hand-tweaking of the resulting output - clang-tidy
is not very good about cleaning up trailing spaces, and aligning
things nicely.
Change-Id: I00336345f5f036e12422b98d66526509380c497a
Reviewed-on: https://gerrit.libreoffice.org/36194
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
As per sberg' suggestion
Limit it to == and !=, because some people like the flow of inequalities
like: "0 < a && a < 42"
The changes to sal/ were made using the rewriter.
The rewriter still has one bug, in pipe.cxx, it managed to pick up
some random piece of macro. No idea why.
Change-Id: I01305f9c5396a4b6c7421d6e92f1b4b529388e82
Reviewed-on: https://gerrit.libreoffice.org/30962
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
...escaping from main or being unexpected, in various places, which started when
62dbe2e6eb "Clean up osl_getSystemPathFromFileURL
implementation" made osl_getSystemPathFromFileURL (indirectly) call
rtl_uString_newConcatAsciiL, which can throw std::length_error.
There is no ideal fix for this. "The distinguishing characteristic of logic
errors [i.e., incl. std::length_error] is that they are due to errors in the
internal logic of the program. In theory, they are preventable."
([std.exceptions]) That means that throwing a logic error is more akin to
raising an assert than to throwing some other kind or exception that is intended
to be handled by the program. Which in turn means that it would generally be
more useful to cause such errors to cause calls to std::abort (and produce a
core/backtrace), than to catch and try to somehow handle them. But there
appears to be no way to tell Coverity not to emit warnings about uncaught logic
errors, and it tends to emit quite a number of them for each signle "root
cause," so be pragmatic for now and catch it close to the root.
Change-Id: Iee71f50e3304954e9e88f326e0fa2167b6051ca2
(i.e., starting with an authority component); treating input starting with a
single slash (i.e., starting with an absolute path component) as a relative URL
instead of as an absolute pathname would cause e.g. CppunitTest_sal_osl_file to
fail
Change-Id: Ie340881974c5e9451ab7e0a9bfb21176b8f5666d
Andrea Gelmini