STRING * n support in StarBasic
sbergman at redhat.com
Wed Oct 24 09:41:40 PDT 2012
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 ) );
> s.Expand( static_cast<xub_StrLen>( nOp1 ), ' ' );
> the problem is that SbxVariable is essentially an union which, since
> commit 4d949990ef1438fcae98262519c6af2b47e5ccf5
> Author: Mikhail Voytenko <mav at openoffice.org>
> 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.
> * just ignore the * n section and make all string variable, silently
> (my favored compromised)
> * whine on the STRING * n syntax
More information about the LibreOffice