Description: In the macro below, we define the optional parameter 'length' as type Integer with default value 32. Yet the msgbox appears saying "Huh - why is length not of type integer????" and the debugger indicates Variant/String value "32"? Then we get type error on the following line to calc the value of msb as length is (somehow?) a Variant/String. How is this possible? Option Compatible 'Needed for the default value assignment in the function definition on the next line Function BitShiftWithWrapAround(cell as Double,shift As Integer, Optional length As Integer=32) CompatibilityMode(True) 'This line makes no difference Dim result as Double result = cell ' Before the next line executes, debugger shows length as "<missing parameter>", type String - huh? if not (typename(length)="Integer") then ' Yet here the type magically becomes Variant/String and the value suddenly becomes "32" as a string msgbox "Huh - why is length not of type integer????" end if ' Even stranger, now the type suddenly becomes Integer, value 32 msb = 2^(length-1) ' Remainder not included in this bug report- we don't make it past the line above UNLESS the ' if - end if secton immediately above it is included. ' To make this function run we need a return value. Just return the msb for now until this bug is sorted. return msb end Function Now for the really crazy part - if we remove the section: if not typename... msgbox ... end if ..then we get an LO macro error on the msb = ... line like so: Inadmissible value or data type. Data type mismatch. This is crazy - testing the typename changes the type???? Not testing it doesn't??? That reeks of side effects. Steps to Reproduce: 1. Create macro - cut and paste from "Option Compatible" to "end Function" 2. Put a formula in a cell '=BitShiftWithWrapAround(2025167957,-1)' 3. Observe how the msgbox appears, and note the function still works. 4. Remove (or comment out) the 3 lines immediately before msb= 5. Repeat step 2. 6. Observe how an LO Macro error occurs, totally breaking the macro. Actual Results: Inadmissible value or data type. Data type mismatch. Expected Results: Function should return 4050335914 (=2025167957 >> 1 with wraparound) We didn't include the code to do this because we cannot get past the type mismatch error without including unnecesary code before it, which appears to produce a side effect. Reproducible: Always User Profile Reset: No Additional Info: Version: 4.2.8.2 Build ID: 420m0(Build:2)
Created attachment 143313 [details] Reproducible document Run Main(). Expected Result:7 Actual Result:6
I can confirm this. Tested with Windows 8 LibreOffice info: Versión: 6.0.4.2 Id. de compilación: 9b0d9b32d5dcda91d2f1a96dc04c645c450872bf Subprocs. CPU: 2; SO: Windows 6.3; Repres. IU: predet.; Configuración regional: es-ES (es_ES); Calc: CL
Also reproduced in LibreOffice 3.3.0 OOO330m19 (Build:6) tag libreoffice-3.3.0.4 @Stephan, @Eike, I thought you could be interested in this issue...
quite unsure, but possible source code pointer? https://opengrok.libreoffice.org/xref/core/basic/source/runtime/runtime.cxx?r=2fbd7d24#4040
https://opengrok.libreoffice.org/xref/core/basic/source/comp/dim.cxx?r=9e6ca513#947
https://opengrok.libreoffice.org/xref/core/basic/source/runtime/runtime.cxx?r=2fbd7d24#4044 -p = new SbxVariable(); +p = new SbxVariable(pParam-> eType);
Submission done. https://gerrit.libreoffice.org/#/c/77684/
Tomoyuki Kubota committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/+/ff6383face219970a0435b008a0439643a61043e%5E%21 tdf#118544 set correct type for optional parameter It will be available in 6.4.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.