Consider the code: Option Compatible Sub TestNonAscii Абв = 10 MsgBox абв End Sub The code uses a Cyrillic characters for the variable name "Абв", and it uses the same name with first character lowercase in the next MsgBox statement. It must output "10", but instead, it shows empty dialog. The problem is, the non-ASCII characters are not treated case-insensisively; in the code, there are "equalsIgnoreAsciiCase" calls on the result of SbxVariable::GetName left and right. Commit de81c2545aec06a1b269218b7d00656e97d8b66c introduced a cached transliterated case-insensitive name value, obtained using SbxVariable::GetName with SbxNameType::CaseInsensitive. So instead of those equalsIgnoreAsciiCase, in compatibility mode we should compare for equality, using the transliterated case-insensitive value.
The same is true for native non-ASCII names, using [name] syntax, that doesn't require 'Option Compatible': Sub TestNonAsciiNative [Абв] = 5 MsgBox [абв] End Sub
Confirmed in: Version: 7.4.0.0.alpha0+ (x64) / LibreOffice Community Build ID: a58701650c2dd7ad8514752d571aa2569690fe37 CPU threads: 6; OS: Windows 10.0 Build 19044; UI render: Skia/Vulkan; VCL: win Locale: de-DE (de_DE); UI: en-US Calc: CL
I have a prototype for this bug, but the naming conventions of the parser and the runtime confuses me. The parser uses bCompatible and bVBASupportOn [1], whereas the runtime just uses bCompatibility for the VBA runtime compatibility mode [2]. So the runtime has no information about Option Compatible to check in the comparision of the variable names [3]. So, should we rename the function in the runtime in order to get rid of that confusion? I'm not sure if it interferes in the image making process. [1] https://opengrok.libreoffice.org/xref/core/basic/source/inc/scanner.hxx?r=67c15910#61 [2] https://opengrok.libreoffice.org/xref/core/basic/source/inc/runtime.hxx?r=d1207a5f#179 [3] https://opengrok.libreoffice.org/xref/core/basic/source/sbx/sbxarray.cxx?r=8024118d#289
(In reply to Andreas Heinisch from comment #3) Given comment 1, I don't think that this bug needs any special handling wrt compatibility. The problem is comparison; and in all modes, we need to drop equalsIgnoreAsciiCase in favor of > aNameCI = SbGlobal::GetTransliteration().transliterate(rName, 0, rName.getLength()); > .... > && (rEntry.mpVar->GetName(SbxNameType::CaseInsensitive) == rNameCI)) or the like.
Ah ok, I thought this should happen only in with Option Compatible.
Andreas Heinisch committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/90d33f5945336fa46b7c02f425100af794768b15 tdf#148358 - Compare Non-ASCII variable names case-insensitive It will be available in 7.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.