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>
Change lowercase ß U+00DF LATIN SMALL LETTER SHARP S from
LowerToUpper, ToUpper: SS
ToTitle: Ss
FullFolding: ss
to
LowerToUpper, ToUpper: ẞ U+1E9E
ToTitle: ẞ U+1E9E
FullFolding: ss
Add uppercase ẞ U+1E9E LATIN CAPITAL LETTER SHARP S
UpperToLower, ToLower: ß U+00DF
FullFolding: ss
Adjust BASIC Collection test to new reality.
Change-Id: I198e06985b81a71e5de94bf7fab7a0dbaf10baef
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124988
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins
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>
In addition, create a meaningful error message and don't create and
artificial error message if there exists a custom one.
Change-Id: I682e497ee3fdfe4da80fb17ab41c1b4cf90eb2cb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122206
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 order to support the correct data type of numeric constants,
booleans, and default values for strings, the strategy to transport the
data type character to the runtime has been changed.
The type character will be added after the literal and the string
termination symbol in order to keep compatibility. This allows to
retrieve the correct type in StepLOADNC and in StepPARAM.
Any legacy written images are still possible to process, since if there
is a suffix type character where the data type character was directly
written after the numeric constant, it will be processed in StepLOADNC.
Without this fix, an optional parameter of type Variant, would still
include the suffixe type character, and will not be converted to the
correct type in StepPARAM.
Change-Id: I86c8192c6dc28457053fa7b23a073420e45407b2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119945
Tested-by: Jenkins
Reviewed-by: Andreas Heinisch <andreas.heinisch@yahoo.de>