On 10/24/2012 05:58 PM, Norbert Thiebaud wrote:
I'm been hacking around basic/* on things related to String -> OUString...and I found this: void SbiRuntime::StepPAD( sal_uInt32 nOp1 ) { SbxVariable* p = GetTOS(); String& s = (String&)(const String&) *p; if( s.Len() > nOp1 ) s.Erase( static_cast<xub_StrLen>( nOp1 ) ); else s.Expand( static_cast<xub_StrLen>( nOp1 ), ' ' ); } the problem is that SbxVariable is essentially an union which, since commit 4d949990ef1438fcae98262519c6af2b47e5ccf5 Author: Mikhail Voytenko <[email protected]> Date: Fri Aug 13 13:28:45 2010 +0200 mib18: #163225# support long strings in basic doe snot know String anymore but OUString. iow the code above is very likely to break badly if executed.
Devilishly, it should actually happen to work just fine, as tools String and rtl::OUString are layout-compatible.
otoh. that function is invoked via _PAD which itself is invoked in case of Dim foo STRING * 100 i.e a fixed sized string, a syntax that has been dropped with VB 6.0. (end-of-life 2005, extented eol 2008) So the question is: * should we try to fix the support for that (note: these fixed string _are_ 64K limited by spec, whereas the 'normal' variable string are 2G limited, so dropping the support for fixed string will make things easier to get rid of xub_StrLen as uint16_t) : bonus point ignore the old spec 64K limit and allow 2G fixed string
But the fix would simply be switching the implementation of SbiRuntime::StepPAD (and possibly more) to properly use the SbxVarialbe's OUString, and nothing more, or what am I missing? So I fail to see how that relates to getting rid of xub_StrLen.
Stephan
OR * just ignore the * n section and make all string variable, silently (my favored compromised) OR * whine on the STRING * n syntax
_______________________________________________ LibreOffice mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/libreoffice
