cppu::UnoType<sal_uInt8> corresponds to UNO boolean, so its use made the
unsigned values be converted to a true/false in Any; and additionally,
using such a boolean Any, even having a 'true' value, as a parameter to
a double argument would make operator >>=(const Any &, double &) return
false, giving the resulting double equal to 0.
The wrong conversion of UShorts and ULongs to cppu::UnoType<sal_uInt8>
(aka TypeClass_BOOLEAN) was introduced in commit
11f9aa4fcb
Author Andreas Bregas <ab@openoffice.org>
Date Thu May 10 14:22:42 2001 +0000
#79615# sbxToUnoValue(): Choose smallest possible type for numeric values
Treating of unsigned Basic Byte as a signed cppu::UnoType<sal_Int8> (aka
TypeClass_BYTE) was already introduced in
commit c25ec0608a
Author Jens-Heiner Rechtien <hr@openoffice.org>
Date Mon Sep 18 15:18:56 2000 +0000
initial import
Then, in commit 553cf2a834
Author Andreas Bregas <ab@openoffice.org>
Date Fri Jun 08 14:59:57 2001 +0000
#87927# Map TypeClass_BYTE to SbxINTEGER instead of SbxBYTE because of signed/unsigned problem
an attempt was made to handle obviously this same problem, changing the
corresponding UNO type to TypeClass_SHORT. But it seems that it created
problems when passing arrays of Byte through UNO to COM, where it needed
to convert to a safearray, so this decision was reverted in commit
dd6ba6b64a
Author Mikhail Voytenko <mav@openoffice.org>
Date Thu Jul 08 21:33:48 2010 +0200
mib17: #162917# let basic byte use one byte, let olebridge convert sequence to safearray correctly
This change tries to avoid the problem that caused the latter revert,
by only treating Bytes as UNO shorts in getUnoTypeForSbxValue, where
scalar Byte values are considered, keeping old handling for arrays.
Change-Id: I805108743376e2fc27dd21a27c31759b76dc0d09
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/136526
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Moves the custom cleanup logic to overridden SbxMethod::Clear, to simplify
the cleanup code and make sure it restores empty Variant correctly.
Change-Id: I01fa0529acd9ac787ffcda60fd6836ade4afdcb1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/136108
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
...like my local ASan+UBSan build, which now happened to fail once with
> Failed: TestReplacePerformance (t = 60 s)
> Tests passed: 0
> Tests failed: 1
when the machine was under load during a parallelizing `make check`, following
up on 3564b5c6e9 "Adapt test to slow builds"
Change-Id: I8f0c8f7e6e145b6d5009f48d2af865ea5caab375
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132335
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
First, the integer function result is returned in a 64-bit register (RAX),
and truncation it to sal_Int32 breaks any pointer return value.
Second, using explicit (not vararg) first function double argument would
pass it through XMM0, without also copying it to RCX (which is guaranteed
for varargs).
Ref: https://docs.microsoft.com/en-us/cpp/build/x64-calling-convention
Change-Id: I08212c44d8690d6910068b13c16af2ce899c94f2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129808
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
...like my local ASan+UBSan build, which kept failing with
> Failed: TestReplacePerformance (t = 35 s)
> Tests passed: 0
> Tests failed: 1
when the machine was under load during a parallelizing `make check`
Change-Id: I59c81a61a29df7165f6fad33e3fe3da975f05ed2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129237
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
I hope that this performance test is OK. I chose 20 s threshold, as
it works much faster on my system (under 4 s); it shouldn't be much
slower elsewhere; and both the original bug, and the regression that
followed the initial fix, made it execute orders of magnitute slower
(I expect hours on fast systems).
Change-Id: I75ee4c60e562473fe70a203faa94b48c5fbfb4fe
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129203
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
If you want to keep the string to floating point conversion semantics
in BASIC as they were in LibreOffice 6, you can either set the
LIBREOFFICE6FLOATINGPOINTMODE environment variable to some non-empty
value, or set the org.openoffice.Office.Scripting/Basic/Compatibility/
UseLibreOffice6FloatingPointConversion flag in the Expert
Configuration. (Or use a registry modification file with that effect.)
Adapt the relevant unit test accordingly. Thanks to Mike Kaganski for
showing how to access the setting in the LibreOffice registry from
Basic.
Change-Id: I13d6d5d834e1bb81ef8df489db2b1da79f01dfc5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125756
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
If a name is ending with an underscore at the end of the line, it won't
be recognized correctly and it will be wrongly interpreted as the
respective name without the underscore at the end. Instead of changing
the macro source, use a flag in order to correclty identify the line end.
Change-Id: I6f933d7382b510bffed3e2692d32c232b7084624
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123833
Tested-by: Jenkins
Reviewed-by: Andreas Heinisch <andreas.heinisch@yahoo.de>
Don't assign a missing optional variable to a property and don't allow
the computation/comparision including missing optional attributes.
In the previous cases a ERRCODE_BASIC_NOT_OPTIONAL is raised.
Change-Id: Iab391286fcace16c271ae511304075e2a0c5c651
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121794
Tested-by: Jenkins
Reviewed-by: Andreas Heinisch <andreas.heinisch@yahoo.de>
In addtion, fixed a crash if the start position is greater than the
length of the string being searched.
Change-Id: I9bcda1131324bdfac6957018e91b3a36dd2dc3d6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118996
Tested-by: Jenkins
Reviewed-by: Andreas Heinisch <andreas.heinisch@yahoo.de>
In the old algorithm, some special unicode characters lead to a
malfunction of basic's replace function. For instance, replacing a
German ß to uppercase in the insensitive case will lead to SS, breaking
the replace positions.
Change-Id: I4e6f6e5fba3d560b8cfd0786fa2439ed5174a928
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118760
Tested-by: Jenkins
Reviewed-by: Andreas Heinisch <andreas.heinisch@yahoo.de>
This also fix the problem of basic_coverage tests not showing
the results when they were failing, since doUnitTest
returned a Integer
Change-Id: I637cd4cfaa34047bc99bfe6e0930f2945f1a9315
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118234
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
It seems that, for some reason, the comparison operators for
strings in basic were swapped in the code that evaluates
string comparisons at compile-time. This is what caused
bug #142180. This commit simply swaps the operators and
should fix the bug.
Change-Id: I14f90db8598f2f7f8b709e26902986e1f64af576
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115983
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
(regression from commit I8dbfdf4bb2eceac0b5afbddd3f35e1dcde2db68b
"tdf#84435: Mod operator does not deal with decimals as described in help").
Change-Id: I74b231d3814148579a3be0a92b7602fa4387281f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113571
Tested-by: Jenkins
Reviewed-by: Andreas Heinisch <andreas.heinisch@yahoo.de>
