[Libreoffice-bugs] [Bug 133889] New: Invoking a Basic routine with ByRef Long or Double parameter does not return modified value

[bugzilla-daemon at bugs.documentfoundation.org]

https://bugs.documentfoundation.org/show_bug.cgi?id=133889

            Bug ID: 133889
           Summary: Invoking a Basic routine with ByRef Long or Double
                    parameter does not return modified value
           Product: LibreOffice
           Version: Inherited From OOo
          Hardware: All
                OS: All
            Status: UNCONFIRMED
          Severity: normal
          Priority: medium
         Component: BASIC
          Assignee: libreoffice-bugs at lists.freedesktop.org
          Reporter: mikekaganski at hotmail.com
                CC: andreas.heinisch at yahoo.de

This is one of two related bug reports (the other is bug 133887); attachment
161869 contains the tests for both. Please run TestByRefFromInvoke, and only
check last two lines of output (OutputByRef3 and OutputByRef4) for the purposes
of this bug.

If there is a routine with a ByRef parameter (i.e., inout parameter), invoking
it using XScript::invoke [1] requires passing *in* values through the first
array (sequence), and getting their modified *out* values in the last passed
array. This bug is for explicit Long and Double parameters:

> Sub Foo(v As Long) ' default ByRef
>     v = 100000
> End Sub

> Sub TestInvoke
>     oScript = thisComponent.getScriptProvider().getScript("vnd.sun.star.script:Standard.Module1.Foo?language=Basic&location=document")
>     oScript.invoke(Array(0&), aOutInd, aOutArr)
>     MsgBox aOutArr(0) & " " & TypeName(aOutArr(0))
> End Sub

TestInvoke above passes "0&" (i.e., an explicit Long value) as initial value of
the variable passed to the Foo, and expects to get the modified value in the
aOutArr(0) - i.e., it should output "100000 Long".

However, the actual returned value is 0 of type *Integer*. It is possible to
get the correct result by modifying the value passed to invoke call like this:

>     oScript.invoke(Array(200000), aOutInd, aOutArr)

So it is not enough to pass an explicitly-typed long value; it turns into a
smaller type if its value fits that smaller value.

The conversion was introduced in
https://git.libreoffice.org/core/+/11f9aa4fcb2ad0a5fada8561c7041e7f25a059fc,
and was made conditional (dependent on VBASupport) in
https://git.libreoffice.org/core/+/9cdb73ff28c4cd6380412468f34ff10e46292a07.
The reason for the conversion is expressed as "Choose "smallest" represention
for int values because up cast is allowed, downcast not". I *suppose* that the
idea was that it's possible to call some UNO API like this:

> Dim n As Long
> n = 1
> oSomeObject.AMethodExpecting16BitValue(n)

... which would fail if value of n would be passed as 32-bit integer to the
method. Thus, I suppose that removal of the conversion could be an incompatible
change breaking infinite number of existing macros (so unacceptable; yet, I
don't have a proof of this suspicion). I also don't know if it's possible to
find a proper condition to disallow downcasting for the purposes of ByRef
parameters.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice-bugs/attachments/20200611/f2a3da1f/attachment-0001.htm>