STRING * n support in StarBasic

[Stephan Bergmann]

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 <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.

Stephan

> OR
> * just ignore the * n section and make all string variable, silently
> (my favored compromised)
> OR
> * whine on the STRING * n syntax