V1024 The 'aIfstream' stream is checked for EOF before reading from it, but is not checked after reading. Potential use of invalid data.
Change-Id: I253513c47ec1482882bbfb1c6e32e25c15ace99c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/175475
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Jenkins
V1024 The 'aInput' stream is checked for EOF before reading from it, but is not checked after reading. Potential use of invalid data.
Change-Id: Ie0c6d1928dad804b21d3c9920cc1de8035ea0367
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/175476
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Jenkins
V1024 The 'aStream' stream is checked for EOF before reading from it, but is not checked after reading. Potential use of invalid data.
Change-Id: I4f7b10bc896d13a31a97ed0dbacd413de990eb89
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/175363
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
will be included when using --with-lang=ALL in non-release configuration
(i.e. tinderbox provided daily builds), but not when using
--enable-release-build.
Change the way how configure fetches the list of all supported languages
from a fancy sed call to running make with a dummy-recipe.
Change-Id: I8bbea5fd95d37eac5bbce2e55ae34830b0ab4ebb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168334
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
Tested-by: Jenkins
that can be initialised at compile-time instead of runtime
Change-Id: I08d516fdc13a3a79f93c079f89ac44cbc7a1ed71
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153620
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
For similar code sequences that can be improved.
Also move containsComment from collapseif plugin code to
plugin.cxx so we can use it from stringadd.
Change-Id: Ie07d9aedf2c31cb0b2080e1b8584294d7046a8e1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149217
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
...which caused `make translations` fail for me with
> [POT] pot.done
> dyld[96290]: Library not loaded: @__VIA_LIBRARY_PATH__/libuno_sal.dylib.3
> Referenced from: <CD4F28D6-E3BE-3126-B861-C90BF3E14492> .../workdir/LinkTarget/Executable/cfgex
> Reason: tried: '/System/Volumes/Preboot/Cryptexes/OS@__VIA_LIBRARY_PATH__/libuno_sal.dylib.3' (no such file), '/usr/local/lib/libuno_sal.dylib.3' (no such file), '/usr/lib/libuno_sal.dylib.3' (no such file, not in dyld cache)
> Error: Failed to execute .../workdir/LinkTarget/Executable/cfgex -i .../connectivity/registry/ado/org/openoffice/Office/DataAccess/Drivers.xcu -o .../workdir//pot/connectivity/registry/ado/org/openoffice/Office/DataAccess.pot
(This is the opposite case to 17cfd43e28 "Avoid
external processes picking up instdir/program/libxml2.so.2". Here, the
executables called from Executable_localize are LO-internal executables that
need the libraries in instdir/. There, the scripts called from
Executable_localize in turn only call external tools that shall not accidentally
pick up LO-internal libraries from instdir/.)
Change-Id: Ib1aa240ee47a21d14ec0463fee85bebe82453cee
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143118
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...which is a problem in ASan builds, as seen with a failing `make check`:
> xgettext: symbol lookup error: .../instdir/program/libxml2.so.2: undefined symbol: __asan_init
> xgettext: symbol lookup error: .../instdir/program/libxml2.so.2: undefined symbol: __asan_init
> xgettext: symbol lookup error: .../instdir/program/libxml2.so.2: undefined symbol: __asan_init
> xgettext: symbol lookup error: .../instdir/program/libxml2.so.2: undefined symbol: __asan_init
> xgettext: symbol lookup error: .../instdir/program/libxml2.so.2: undefined symbol: __asan_init
> Traceback (most recent call last):
> File ".../solenv/bin/uiex", line 25, in <module>
> input = check_output(["xgettext", "--add-comments", "--no-wrap", ifile, "-o", "-"], encoding="UTF-8")
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> File "/usr/lib64/python3.11/subprocess.py", line 465, in check_output
> return run(*popenargs, stdout=PIPE, timeout=timeout, check=True,
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> File "/usr/lib64/python3.11/subprocess.py", line 569, in run
> raise CalledProcessError(retcode, process.args,
> subprocess.CalledProcessError: Command '['xgettext', '--add-comments', '--no-wrap', '.../basctl/uiconfig/basicide/ui/basicmacrodialog.ui', '-o', '-']' returned non-zero exit status 127.
> Error: Failed to execute .../solenv/bin/uiex -i .../basctl/uiconfig/basicide/ui/basicmacrodialog.ui -o .../workdir//pot/basctl/messages.pot
The solution is similar to e854abe076 "Avoid
external processes picking up instdir/program/libnspr4.so" used in various
tests. And as Executable_localize appears to only be called in that one place
in the recipe of `make translations`, for simplicity make the library path
override a required fourth argument for that executable.
Change-Id: Ia6326ac0bb12ea75a8b3df51f7fbf12b88aca634
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142999
Tested-by: Jenkins
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
This is apparently some very old, very poor XML parsing code full of
questionable design decisions. The silliness of pushing onto the opened-element
stack also entities that don't have a closing tag (but which cannot easily be
changed, see the added comment about CfgStack::GetAccessPath) caused consistent
memory leaks when Executable_cfgex is executed during the build. While those
leaks are harmless, they might cause people to nevertheless try to clean them up
in various ways (see the abandoned
<https://gerrit.libreoffice.org/c/core/+/142718> "asan: fix leak in
ExecuteAnalyzedToken/Push"), so just clean up those broken-by-design excess
aStack elements.
Change-Id: I849109906c6b102d9aa90300c2bada360c727d4d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143001
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
> l10ntools/source/xmlparse.cxx:491:51: runtime error: downcast of address 0x603000000610 which does not point to an object of type 'XMLParentNode'
> 0x603000000610: note: object is of type 'XMLDefault'
> 00 00 00 00 30 44 a7 dd a0 55 00 00 00 05 10 6e a4 7f 00 00 80 00 00 00 60 60 00 00 00 00 00 00
> ^~~~~~~~~~~~~~~~~~~~~~~
> vptr for 'XMLDefault'
> #0 in XMLFile::CheckExportStatus(XMLParentNode*) at l10ntools/source/xmlparse.cxx:491:51
> #1 in XMLFile::CheckExportStatus(XMLParentNode*) at l10ntools/source/xmlparse.cxx:481:9
> #2 in HelpParser::CreatePO(rtl::OString const&, rtl::OString const&, XMLFile*, std::basic_string_view<char, std::char_traits<char>>) at l10ntools/source/helpmerge.cxx:91:20
> #3 in sal_main_with_args(int, char**) at l10ntools/source/helpex.cxx:124:17
> #4 in main at l10ntools/source/helpex.cxx:47:1
and
> l10ntools/source/xmlparse.cxx:523:44: runtime error: downcast of address 0x6030000007c0 which does not point to an object of type 'XMLParentNode'
> 0x6030000007c0: note: object is of type 'XMLData'
> 00 00 00 00 e0 53 d5 c0 46 56 00 00 d0 00 00 00 40 60 00 00 f0 07 00 00 30 60 00 00 00 00 00 00
> ^~~~~~~~~~~~~~~~~~~~~~~
> vptr for 'XMLData'
> #0 in XMLFile::CheckExportStatus(XMLParentNode*) at l10ntools/source/xmlparse.cxx:523:44
> #1 in XMLFile::CheckExportStatus(XMLParentNode*) at l10ntools/source/xmlparse.cxx:492:80
> #2 in XMLFile::CheckExportStatus(XMLParentNode*) at l10ntools/source/xmlparse.cxx:481:9
> #3 in HelpParser::CreatePO(rtl::OString const&, rtl::OString const&, XMLFile*, std::basic_string_view<char, std::char_traits<char>>) at l10ntools/source/helpmerge.cxx:91:20
> #4 in sal_main_with_args(int, char**) at l10ntools/source/helpex.cxx:124:17
> #5 in main at l10ntools/source/helpex.cxx:47:1
and
> l10ntools/source/xmlparse.cxx:526:48: runtime error: downcast of address 0x603000000820 which does not point to an object of type 'XMLParentNode'
> 0x603000000820: note: object is of type 'XMLComment'
> 00 00 00 00 28 06 92 a9 17 56 00 00 d0 00 00 00 40 60 00 00 40 00 00 00 20 61 00 00 00 00 00 00
> ^~~~~~~~~~~~~~~~~~~~~~~
> vptr for 'XMLComment'
> #0 in XMLFile::CheckExportStatus(XMLParentNode*) at l10ntools/source/xmlparse.cxx:523:44
> #1 in XMLFile::CheckExportStatus(XMLParentNode*) at l10ntools/source/xmlparse.cxx:492:80
> #2 in XMLFile::CheckExportStatus(XMLParentNode*) at l10ntools/source/xmlparse.cxx:481:9
> #3 in HelpParser::CreatePO(rtl::OString const&, rtl::OString const&, XMLFile*, std::basic_string_view<char, std::char_traits<char>>) at l10ntools/source/helpmerge.cxx:91:20
> #4 in sal_main_with_args(int, char**) at l10ntools/source/helpex.cxx:124:17
> #5 in main at l10ntools/source/helpex.cxx:47:1
Change-Id: I1e2c6bf802aa03b5b1eb21532e98fa22d966e683
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143000
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
After 6d6a143913 "Address some of the sprintf in
vcl/source/fontsubset/cff.cxx", --with-latest-c++ builds that pick up a C++23
compiler that implements
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2266r1.html> "P2266R1:
Simpler implicit move" started to fail with something like
> vcl/source/fontsubset/cff.cxx:2061:16: error: no viable conversion from returned value of type 'char[64]' to function return type 'OString'
> return aDefaultGlyphName;
> ^~~~~~~~~~~~~~~~~
[...]
> include/rtl/string.hxx:313:5: note: candidate constructor [with T = char[64]] not viable: expects an lvalue for 1st argument
> OString( T& value, typename libreoffice_internal::NonConstCharArrayDetector< T, libreoffice_internal::Dummy >::Type = libreoffice_internal::Dummy() )
> ^
etc. So I figured there should be something better than
433ab39b21 "Adapt implicit OString return value
construction to C++23 P2266R1" (which this commit reverts, modulo its conflicts
in comphelper/source/xml/xmltools.cxx and
sc/source/filter/xcl97/XclExpChangeTrack.cxx) to address the underlying issue in
a way that keeps code that works up to C++20 also working in C++23.
(The fix is only relevant for non-explicit constructors that involve
NonConstCharArrayDetector and non-const lvalue references, not for other
functions involving those. OUString has a similar constructor but which is
explicit, and OUStringBuffer doesn't have any similar constructors at all, so
this only affects OString and OStringBuffer constructors.)
Change-Id: I31cf16b9507899f5999243f8467dfa24bc94c5ac
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142455
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
And use an overloaded helper function with a better (?) unified name
to show that the result is not an O(U)String.
Change-Id: I8956338b05d02bf46a6185828130ea8ef145d46b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141203
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
in the conversion in
commit 74957c7d2f
Author: Noel Grandin <noel.grandin@collabora.co.uk>
Date: Wed Apr 13 13:54:22 2022 +0200
use more string_view in l10ntools
where the prior code might have been relying on the -1 returned by
indexOf and lastIndexOd
Change-Id: Ief5dedccbaf4e14e5f59aa3c2f7481ff0bb7e2e8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133027
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
for which we have o3tl:: equivalents
Change-Id: I4670fd8b703ac47214be213f41e88d1c6ede7032
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132913
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
look for call sequences that can use string_view and the new o3tl
functions in o3tl/string_view.hxx
Also add a few more wrappers to said #include file
Change-Id: I05d8752cc67a7b55b0b57e8eed803bd06bfcd9ea
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132840
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
found by tweaking the loplugin:stringview and making it whitelist
getLength
Change-Id: Ic15d3703d1fb07658e99e1db1c89e2fa5bc70c19
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132771
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
since we now have o3tl versions of those that work on
string_view.
Also improve those o3tl functions to support both string_view
and u16string_view
Change-Id: Iacab2996becec62aa78a5597c52d983bb784749a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132755
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
for which we add a new o3tl::trim method
Change-Id: I9d37b6264eea106aa2f3502bd24b8cccf7850938
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132658
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
.. and lastIndexOf, which convert to find and rfind
Change-Id: I6c4156cf904774c0d867f85a4c2785dba7593f62
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132445
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
...instead of causing use-after-free of pMergeEntrys, which would be destroyed
during the (non-adding) emplace call but would still be used in the following
if/else block (see the commit message of
c6e2052b6f "Update git submodules: Fix duplicate
key typo")
Change-Id: Iac8d67e61aba0144d3d5807f478c7b330d7c4c81
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130235
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
look for
#define FOO "foo"
that can be converted into OUStringLiteral.
This is the first pass of this plugin, only doing those #define which
are local to a single compilation unit.
Change-Id: Ic8610e29ec42c36d03db5014a93c244315d5bbea
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124962
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
...for LIBO_INTERNAL_ONLY, instead of having them as additional overloads. That
way, loplugin:bufferadd and loplugin:stringviewparam found many further
opportunities for simplification (all addressed here). Some notes:
* There is no longer an implicit conversion from O[U]String to O[U]StringBuffer
(as that goes via user-defined conversions through string_view now), which was
most noticeable in copy initializations like
OStringBuffer buf = someStr;
that had to be changed to direct initialization,
OStringBuffer buf(someStr);
But then again, it wasn't too many places that were affected and I think we can
live with that.
* I made the O[U]StringBuffer ctors taking string_view non-explicit, mainly to
get them in line with their counterparts taking O[U]String.
* I added an OUStringBuffer::lastIndexOf string_view overload that was missing
(relative to OUStringBuffer::indexOf).
* loplugin:stringconstant needed some addition to keep the
compilerplugins/clang/test/stringconstant.cxx checks related to
OStringBuffer::append and OStringBuffer::insert working.
* loplugin:stringviewparam no longer needs the special O[U]StringBuffer-related
code that had been introduced in 1250aecd71
"loplugin:stringviewparam extend to new.."
Change-Id: Ib1bb8c4632d99b744e742605a9fef6eae959fd72
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122904
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...compared to a full-blown O[U]String, for temporary objects holding an
O[U]StringConcat result that can then be used as a std::[u16]string_view.
It's instructive to see how some invocations of operator ==, operator !=, and
O[U]StringBuffer::insert with an O[U]StringConcat argument required implicit
materialization of an O[U]String temporary, and how that expensive operation has
now been made explicit with the explicit O[U]StringConcatenation ctor.
(The additional operator == and operator != overloads are necessary because the
overloads taking two std::[u16]string_view parameters wouldn't even be found
here with ADL. And the OUString-related ones would cause ambiguities in at
least sal/qa/rtl/strings/test_oustring_stringliterals.cxx built with
RTL_STRING_UNITTEST, so have simply been disabled for that special test-code
case.)
Change-Id: Id29799fa8da21a09ff9794cbc7cc9b366e6803b8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122890
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
