Age | Commit message (Collapse) | Author |
|
Location:
if (nDecPlaces == 0)
{
switch (eMode)
{
case rtl_math_RoundingMode_Corrected:
return std::round(fValue);
Because the functions are the same as the following
related codes, they are respectively:
if (nDecPlaces >= 0
&& (fValue >= 0x1p52
|| isRepresentableInteger(fValue)))
return fOrigValue;
as well as:
if (fValue < 0x1p52)
{
switch(eMode)
{
case rtl_math_RoundingMode_Corrected:
fValue = rtl::math::approxFloor(fValue + 0.5);
break;
:
:
:
Because some double-precision floating point
numbers cause std::round(fValue) and rtl::math::approxFloor(fValue + 0.5)
to produce different results.
For example, enter 10614.4999999999876 in Calc's
A1 cell (or any operation that will produce a long
decimal number such as .499999999999xyz after the
decimal point).
We expected it to be 10614.4999999999876, but it
was automatically rounded to 10614.5 (note: this
result is also the result of ubiquitous handheld
computers, OpenOffice.org and Excel)
Then, entering =ROUND(A1,0) in B1, we will see 10614,
A1 and B1 clearly don't meet expectations. (My boss
or tax collector might be unhappy :-p)
Although A1's 10614.4999999999876 is still faithfully
recorded, the rendering of 10614.5 is confusing.
Now, there are two views:
1. According to the established convention, B2
displays the expected answer 10615.
or
2. True to the laws of mathematics, A1 displays
10614.4999999999876 or at least 10614.49
Although the second point of view is correct (and I
completely agree with it), when opening
spreadsheets generated by other software (such as
OpenOffice.org or Excel), the results will be different,
which people do not like to see.
So when nDecPlaces == 0 is removed, use
std::round(fValue) and let the existing code below it do the rounding:
if (fValue < 0x1p52)
{
switch(eMode)
{
case rtl_math_RoundingMode_Corrected:
fValue = rtl::math::approxFloor(fValue + 0.5);
This is consistent with the first point.
By the way, in nDecPlaces == 0
case rtl_math_RoundingMode_HalfEven:
This piece of code can be checked to see if it is really
necessary, because rtl_math_round() also has the same purpose code.
If it is not needed, the entire nDecPlaces == 0 can be removed.
Co-authored-by: Firefly <firefly@ossii.com.tw>
Co-authored-by: Franklin Weng <franklin@goodhorse.idv.tw>
Change-Id: If32cdb18c70ec0025c83ba25a99e5d135d66aec9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159193
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
This prevents a console window flashing briefly on Windows, when
runnung the test.
Was this way since commit d011896d755252105c740f23f31ed43de64f7c98
(INTEGRATION: CWS sal04 (1.1.2); FILE ADDED, 2003-09-29).
Change-Id: I7fb7bb067786d3ad33f9ba831e3b454c91a35e2a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162296
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: I859138dee575ef7fd76db28b619c673782914782
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161235
Tested-by: Jenkins
Reviewed-by: Gabor Kelemen <kelemeng@ubuntu.com>
|
|
Change-Id: Ieca8096e2af9615fa4c34557a47bc13ee5c23936
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160105
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
|
|
Change-Id: Ic8a02784acb9f8981249689541bb6cba1b7fbfb7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159682
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I2a72422a6c8185d17876daac41a86137048b034c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159627
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: I7a928a2385286f6d1ab3887c8d315af3f47c052d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159135
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
<https://lists.freedesktop.org/archives/libreoffice/2023-November/091151.html>
"CppunitTest_stoc_uriproc failed on Windows" reports that
translateToExternal("file:///abc/%feef") produces an empty string (indicating
failure) instead of "file:///abc/%FEef" (as expected in
stoc/test/uriproc/test_uriproc.cxx) when osl_getThreadTextEncoding() is Shift
JIS.
This was due to how the call to rtl::Uri::encode in
Translator::translateToExternal (in
stoc/source/uriproc/ExternalUriReferenceTranslator.cxx) behaved: It internally
interpreted its input "%FE" as the single-byte Shift JIS character 0xFE. Which
gets mapped to U+2122 as an extension (see "APPLE additions over SJIS, we
convert this like Apple, because I think, this gives better result, then [sic]
we take a replacement char" in sal/textenc/tcvtjp6.tab) in readUcs4, but which
in turn doesn't get mapped back to any Shift JIS character in writeEscapeChar.
Translator::translateToExternal is the only user of
rtl_UriEncodeStrictKeepEscapes, as introduced by
6ff5d3341dbc5df3f0cb5368ccb0e1089338916c "INTEGRATION: CWS c07v013_SRC680
(1.4.40); FILE MERGED: 2007/06/21 13:00:56 sb 1.4.40.1: #b6550116# Made
XExternalUriReferenceTranslator.translateToExternal more robust when the input
URL contains spurious non--UTF-8 octets like %FE (which are now copied verbatim,
instead of signalling error)."
To make the claim true that such "spurious non--UTF-8 octets like %FE" are
always "copied verbatim", regardless of text encoding being used, repurpose
rtl_UriEncodeStrictKeepEscapes to always treat any escape sequences that are
present as (potentially broken) UTF-8.
Change-Id: I0fa0b14d3e3d44e4b5514e1b73c84c407a947ce9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158888
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: If4a7951fd3f9f7f2e081e6b8ba482566260c3235
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158209
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...now that warning about O[U]String vars that could be O[U]StringLiteral is no
longer useful
Change-Id: I389e72038171f28482049b41f6224257dd11f452
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157992
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
It had been missed by 31cd6fd0f3c856a81a03d0229de1c4d10442844f "Make
OStringLiteral ctor non-explicit", and now prevented u8"..."_ostr from
compiling.
Change-Id: Ifb214fba0957b0d26b11daae6190ffa9d21713f0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157823
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...that have been made unused by 7ef3d937415185ef66e32dd3043783eddcd03db5
"loplugin:ostr: Rewrite some uses of O[U]String to use ""_ostr/u""_ustr
literals". (And which means we can remove the relevant code from that plugin
again.)
(This also found a handful of remaining uses that had been hard for the plugin
to discover, along the lines of
> std::map<OUString, int> m = {{u"foo", 0}};
being represented by a
> DeclStmt 0xdaca578 <line:103:5, col:50>
> `-VarDecl 0xdac9150 <col:5, col:49> col:29 s11 'std::map<OUString, int>':'std::map<rtl::OUString, int>' cinit destroyed
> `-ExprWithCleanups 0xdaca548 <col:35, col:49> 'std::map<OUString, int>':'std::map<rtl::OUString, int>'
> `-CXXConstructExpr 0xdaca508 <col:35, col:49> 'std::map<OUString, int>':'std::map<rtl::OUString, int>' 'void (initializer_list<value_type>, const std::less<rtl::OUString> &, const allocator_type &)' list std::initializer_list
> |-CXXStdInitializerListExpr 0xdaca480 <col:35, col:49> 'initializer_list<value_type>':'std::initializer_list<std::pair<const rtl::OUString, int>>'
> | `-MaterializeTemporaryExpr 0xdaca468 <col:35, col:49> 'const std::pair<const rtl::OUString, int>[1]' xvalue
> | `-CXXBindTemporaryExpr 0xdaca448 <col:35, col:49> 'const std::pair<const rtl::OUString, int>[1]' (CXXTemporary 0xdaca448)
> | `-InitListExpr 0xdac9df0 <col:35, col:49> 'const std::pair<const rtl::OUString, int>[1]'
> | `-CXXConstructExpr 0xdaca408 <col:36, col:48> 'const std::pair<const rtl::OUString, int>' 'void (const char16_t (&)[4], int &&) noexcept(_S_nothrow_constructible<const char16_t (&)[4], int>())' list
> | |-StringLiteral 0xdac91b8 <col:38> 'const char16_t[4]' lvalue u"foo"
> | `-MaterializeTemporaryExpr 0xdaca3f0 <col:46> 'int' xvalue
> | `-IntegerLiteral 0xdac91d8 <col:46> 'int' 0
> |-CXXDefaultArgExpr 0xdaca498 <<invalid sloc>> 'const std::less<rtl::OUString>':'const std::less<rtl::OUString>' lvalue
> `-CXXDefaultArgExpr 0xdaca4b8 <<invalid sloc>> 'const allocator_type':'const std::allocator<std::pair<const rtl::OUString, int>>' lvalue
Clang AST.)
Change-Id: I496fe9d4d5e1a033cb7b27b4e04b303f8ddbed4a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157756
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I2d09b2b83e1b50493ec88d0b2c323a83c0c86395
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157647
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Jenkins
|
|
...after 1eef07805021b7ca26a1a8894809b6d995747ba1 "Bump baseline to C++20".
Which revealed that at least for VS 2019 16.11.30 (but not for at least VS 2022
17.7.4), in /clr mode (e.g., when compiling
cli_ure/source/climaker/climaker_app.cxx), the -std:c++20 is effectively
ignored, and compilation of such source files failed with
> include\rtl/string.hxx(191): error C2955: 'rtl::OStringLiteral': use of class template requires template argument list
> include\rtl/string.hxx(88): note: see declaration of 'rtl::OStringLiteral'
> include\rtl/string.hxx(191): error C7592: a non-type template-parameter of type 'rtl::OStringLiteral' requires at least '/std:c++20'
> include\rtl/string.hxx(397): error C2955: 'rtl::OStringLiteral': use of class template requires template argument list
> include\rtl/string.hxx(88): note: see declaration of 'rtl::OStringLiteral'
etc. To work around that, keep the 27d1f3ac016d77d3c907cebedca558308f366855
"O[U]String literals (unusable for now, C++20 only)" functionality disabled when
compiling /clr sources (i.e., where _MANAGED is defined) for that old compiler.
Change-Id: If62ceef5f8e55a828b880f197111fe387e4953fe
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157205
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...after 6ef2d358ac053ce0f6de9cf0f8f25e8bae66d441 "Adapt Clang and GCC minimum
version checks"
Change-Id: Ib25fbb76211d1bda1d230de771f207960e645421
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157204
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...after 6ef2d358ac053ce0f6de9cf0f8f25e8bae66d441 "Adapt Clang and GCC minimum
version checks"
Change-Id: I5f3bcda2ce8e0e093af3bdd9d2cca741a5b95306
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157202
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
also drop now-unused osl_Condition_Const.h
Change-Id: I40beb5b1ad49c126a126bb444d5f66703664d56d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155820
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Change-Id: I8fae71e5053950441a2e0920590264c2cb858924
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155546
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Seems like it was committed accidentally
Change-Id: Idc086b7b92ef9c4a8b3bafa2114b7da3e8d42618
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155350
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
|
|
It only contained a single define used in a single file
Change-Id: If9f16ab13bb28d2923b97390f1acb013101d0a09
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155349
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
See patch set 2 of <https://gerrit.libreoffice.org/c/core/+/155121/2> "Bump
baseline to C++20" for how that would affect us here,
> /opt/rh/gcc-toolset-12/root/usr/lib/gcc/x86_64-redhat-linux/12/../../../../include/c++/12/bits/basic_string.h:620: error: undefined reference to 'void std::__cxx11::basic_string<char16_t, std::char_traits<char16_t>, std::allocator<char16_t> >::_M_construct<char16_t const*>(char16_t const*, char16_t const*, std::forward_iterator_tag)'
> clang-12: error: linker command failed with exit code 1 (use -v to see invocation)
> make[1]: *** [/home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_clang_dbgutil_64/solenv/gbuild/LinkTarget.mk:841: /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_clang_dbgutil_64/workdir/LinkTarget/CppunitTest/libtest_sal_rtl.so] Error 1
(<https://ci.libreoffice.org/job/gerrit_linux_clang_dbgutil/145874/>)
Change-Id: Ibda1a5687a16e45aa0e77958f2bf547766cb0f48
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155343
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I36bc86fcffc3c10fe44e60d779c9aa48eeed00f2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154749
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...added by 6fce450b8a66d7e98a4d39528f8591184277e9fa "Introduce "..."_tstr as a
companion to "..."_ostr/u"..."_ustr in template code"
Change-Id: I779cf8e586b2a57aadfe9e57a546ee613bb505e3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155093
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...like
> *path = "/";
in
> template<typename T> oslFileError getSystemPathFromFileUrl(
> OUString const & url, T * path, bool resolveHome)
in sal/osl/unx/file_url.cxx, where T is either OString or OUString. That can
now be replaced with
> *path = "/"_tstr;
and for OString it will be a no-cost constexpr operation, while for OUString it
will still construct the OUString instance at runtime (as did the original code
for both OString and OUString).
(This change required moving the definition of rtl::detail::OStringHolder
around in include/rtl/string.hxx. For consistency, I similarly moved around the
definition of rtl::detail::OUStringHolder in include/rtl/ustring.hxx, too.)
Change-Id: I7fb3a81b438f98c609684f7e70b7a60068d32fdb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154748
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Since 27d1f3ac016d77d3c907cebedca558308f366855 "O[U]String literals (unusable
for now, C++20 only)",
<https://developercommunity.visualstudio.com/t/Using-same-string-literal-suffix-for-cha/10416970>
"Using same string literal suffix for char and char16_t string overloads causes
'no matching overloaded function found'" caused --with-latest-c++ builds to fail
with
> sal/qa/rtl/strings/test_oustring_stringliterals.cxx(432): error C2672: '""_ostr': no matching overloaded function found
> include\rtl/ustring.hxx(3604): note: could be 'rtlunittest::OUString operator ""_ostr(void)'
> include\rtl/string.hxx(2402): note: or 'rtlunittest::OString operator ""_ostr(void)'
> sal/qa/rtl/strings/test_oustring_stringliterals.cxx(432): error C2672: 'CppUnit::assertEquals': no matching overloaded function found
> workdir\UnpackedTarball\cppunit\include\cppunit/TestAssert.h(161): note: could be 'void CppUnit::assertEquals(const T &,const T &,CppUnit::SourceLine,const std::string &)'
> sal/qa/rtl/strings/test_oustring_stringliterals.cxx(432): note: 'void CppUnit::assertEquals(const T &,const T &,CppUnit::SourceLine,const std::string &)': expects 4 arguments - 3 provided
etc. So help MSVC along by renaming from u"..."_ostr to u"..."_ustr for now.
Change-Id: Iad401f0681ac9326b7c57259c5483263ddfbfd4e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154634
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I0ecd1a8b60a01aefdf0139e3777dc006532764fd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154434
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
OUStringLiteral should be declared constexpr, to enforce
that it is initialised at compile-time and not runtime.
This seems to make a different at least on Visual Studio
Change-Id: I1698f5fa22ddb480347c2f4d444530c2e0e88d92
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153499
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
A bunch of range based loop changes in various qa
sections that also take out about 1% of SAL_N_ELEMENTS
Change-Id: I8ef000e9aa400cd8363b48f6175f6ab258cefbd9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152422
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Indeed, the cDecSeparator and cGroupSeparator require that the buffer
uses the proper character type, otherwise it won't be possible to use
Unicode separators in rtl_math_doubleToUString.
Change-Id: Id26bed72776475c1be5b092e3ffcff0e75ffe557
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151451
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
They use rtl_(u)str_valueOf(Float|Double), to fill the buffer, and
the latter use doubleToString, which creates an rtl_(u)String, copies
to the buffer, and releases the rtl_(u)String.
So instead just use the rtl_(u)String from rtl_math_doubleTo(U)String
directly. Even when the end result is not needed as O(U)String, this
would avoid an extra copy step. Also, this avoids separate
LIBO_INTERNAL_ONLY implementations.
Change-Id: Ib1d9ecebd7876dfff7dc758f89ee4c1536647a50
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150150
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: I059f0324597a90aee01c95170a48ac5578f3caee
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150037
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: I184fa0e4e45662e0fac86076d1c8733a0465bb56
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149978
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: Ib98b507db9305ed20e3000f7f457a135a3bb3836
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/148936
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins
|
|
...not the whole CppUnit::assetion_traits<T> classes (where applicable). That
avoids spelling out the (identical) equals member functions, and also leaves
around the less and lessEqual member functions, in case they want to be used
after all.
Change-Id: I18f8d6cff0353921ced4952b33a0c85ff8292923
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/147165
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
As discussed in the mailing list thread starting at
<https://lists.freedesktop.org/archives/libreoffice/2023-January/089808.html>
"Plan to remove dead C++ UNO bridge implementations (bridges/source/cpp_uno/*)",
the bridge implementation at bridges/source/cpp_uno/gcc3_aix_powerpc is
apparently dead and should thus be removed. However, that was the only bridge
implementation for AIX, which implies that support for the AIX platform as a
whole is dead and should thus be removed.
Change-Id: I96de3f7f97d4fd770ff78256f0ea435383688be9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146057
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
After 6d6a143913603b040c10a5db83c2103557899011 "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
433ab39b2175bdadb4916373cd2dc8e1aabc08a5 "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>
|
|
Change-Id: I668a8b4c6ce3458baa6975161be7ed0cb160968f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142331
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>
|
|
...as referenced e.g. at
<https://docs.microsoft.com/en-us/previous-versions/visualstudio/foxpro/aa975345(v=vs.71)>
"Code Pages Supported by Visual FoxPro". That source lists those two encodings
with "code page" values 895 and 620, resp. (which might be what we call "Windows
code pages" in include/rtl/tencinfo.h) and "code page identifier" values 0x68
and 0x69, reps. (which might be what we call "Windows charsets" in
include/rtl/tencinfo.h. But I deliberately left these two new
RTL_TEXTENCODING_* values without any mappings to such Windows codepages etc.,
as I didn't find any authoritative sources. What I used is the information
available at <https://en.wikipedia.org/wiki/Kamenick%C3%BD_encoding> and
<https://en.wikipedia.org/wiki/Mazovia_encoding>.
(And while at it, I also updated the instructions what to do "Whenever some
encoding is added here" in include/rtl/textenc.h.)
This commit is building on some prior, abandoned work by Julien Nabet at
<https://gerrit.libreoffice.org/c/core/+/139819> "tdf#150877: DBF Mazovia
encoding (0x69)".
Change-Id: Iae8af4ebab8915411499ae7ef951339b335aa857
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140014
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Revert the changes in rtl unit tests.
Add some new unit tests to demonstrate the behavior of std
functions is same as rtl functions.
Change-Id: I12603e2502b8d0951ff5e1650dc8fa193d67c856
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138696
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I6bcb33d51c3974d0e8905e1ffeac556a99870aab
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138294
Tested-by: Jenkins
Reviewed-by: Eike Rathke <erack@redhat.com>
|
|
Change-Id: I7c0be7b435d6b5f97bdd40484023584146638d70
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134506
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I280bcc522f3cd375b5f94e644b76bc5f95899324
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133574
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
|
|
Change-Id: I114bec72cb933238675e539a8388a607226827cd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133455
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Regression introduced into LIBO_INTERNAL_ONLY code with
1da69081732c8a429840edaaf10cfb789ea68df8 "add string_view variants of methods to
O[U]StringBuffer".
And add some tests. Assigning an OStringChar to an OStringBuffer also uses the
std::string_view assignment operator, so also test that with testOStringChar,
even though there it is relatively likely that the OStringChar temporary is
followed by null bytes, which could make the test happen to erroneously succeed.
But at least tools like ASan or Valgrind could catch that. On the other hand,
assigning an OUStringChar to an OUStringBuffer does not use the
std::u16string_view assignment operator (and rather uses a
ConstCharArrayDetector-based one, which was similarly broken and has been fixed
in b66387574ef9c83cbfff622468496b6f0ac4d571 "Fix -Werror=array-bounds"), so
there's no test for that here.
Change-Id: I7cf10ee5ce0e4280a91d116cd82d4871a0f44af6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132363
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
> In file included from svtools/source/svrtf/parrtf.cxx:28:
> In member function ‘typename rtl::libreoffice_internal::ConstCharArrayDetector<T, rtl::OUStringBuffer&>::TypeUtf16 rtl::OUStringBuffer::operator=(T&) [with T = const rtl::OUStringChar_]’,
> inlined from ‘virtual int SvRTFParser::GetNextToken_()’ at svtools/source/svrtf/parrtf.cxx:183:94:
> include/rtl/ustrbuf.hxx:352:20: error: array subscript ‘unsigned int[0]’ is partly outside array bounds of ‘rtl::OUStringChar [1]’ {aka ‘const rtl::OUStringChar_ [1]’} [-Werror=array-bounds]
> 352 | std::memcpy(
> | ~~~~~~~~~~~^
> 353 | pData->buffer,
> | ~~~~~~~~~~~~~~
> 354 | libreoffice_internal::ConstCharArrayDetector<T>::toPointer(literal),
> | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 355 | (n + 1) * sizeof (sal_Unicode)); //TODO: check for overflow
> | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> svtools/source/svrtf/parrtf.cxx: In member function ‘virtual int SvRTFParser::GetNextToken_()’:
> svtools/source/svrtf/parrtf.cxx:183:94: note: object ‘<anonymous>’ of size 2
> 183 | aToken = OUStringChar( static_cast<sal_Unicode>(nTokenValue) );
> | ^
as seen with recent GCC 12 trunk in an --enable-optimized build.
And add a test, even though it is relatively likely that the OUStringChar
temporary is followed by null bytes, which would make the test happen to
erroneously succeed. But at least tools like ASan or Valgrind could catch that.
(For the corresponding OStringChar and OStringBuffer scenario, this issue does
not arise, as OStringChar is not covered by ConstCharArrayDetector, so the
correpsonding OStringBuffer assignment operator is OK memcpy'ing n+1 elements.
There /are/ similar issues with string_view assignment operators for both
O[U]StringBuffer, which will be addressed in a later commit.)
Change-Id: Ia131d763aa5f8df45b9625f296408cc935df96ac
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132354
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...once we have a C++20 baseline, which would render uses of the consteval
O[U]StringLiteral ctors ill-formed if we accidentally failed to write to all of
buffer's elements. This had been broken (and the TODO comments had become
misleading) with 21584b304b21bfe6b99b6f29018c6b754ea28fc0 "make
OUString(OUStringLiteral) constructor constexpr" and
bca539e889d40e06cb3275442622cb075b2484a2 "make OString(OStringLiteral)
constructor constexpr".
Also add corresponding test code.
Change-Id: I2bc680282c717d403a681ff4b9396580c8382de1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132275
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Ifb282ae907495ab21f3a91b1cae1c34443cb3626
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132018
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
The documented precondition is that index must not be greater than
the length of string. Just assert that, and fix the found misuse.
The added test is for in-place replacement, just in case.
Change-Id: I3c545a6f0bf913fe93e2bef83ce733359c193065
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131232
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
|
|
It should not attempt to dereference pointers when nIndex is negative.
Properly handle too large nIndex.
Also it is not necessary to parse the string when nToken is negative.
Related to commit be281db569bafaac379feb604c39e220f51b18c4
Author Rüdiger Timm <rt@openoffice.org>
Date Mon Sep 20 07:43:20 2004 +0000
INTEGRATION: CWS ause011 (1.18.22); FILE MERGED
2004/08/18 11:47:54 sb 1.18.22.1: #i33153# Made getToken more robust.
Change-Id: I6fc77a5b70308ccca08cb2132bd78d024bd7e3e0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131221
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|