STRING * n support in StarBasic

[Michael Stahl]

On 25/10/12 01:17, Norbert Thiebaud wrote:
> On Wed, Oct 24, 2012 at 6:41 PM, Stephan Bergmann <sbergman at redhat.com> wrote:
>> Devilishly, it should actually happen to work just fine, as tools String and
>> rtl::OUString are layout-compatible.
> 
> humm... pretty scary... wonder how many other bug are accidentally hidden ?
> 
>>
>> 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.
> 
> One issue is that String already enforce the 64K limit (despite
> internally using a int32 for the len), whereas OUString, obviously
> does not... should we bother enforcing that limit ? including
> maintaining a distinction between 'variable-len' (Basic) String and
> 'fixed-len' String (which is not going to be trivial since they are
> represented by the same kind of object)

if we simply replace the existing String uses with OUString we don't
have to worry about that any more :)

> while on the topic of magic c++ trick:
> 
> does
> 
> OUString* a = get_some_OUString_pointer()
> 
> *a = a->copy(0,5);
> 
> leak or not ?

no leak because OUString::operator= should decrement the ref-count of
"this" after incrementing the ref-count of the parameter (implementation
is rtl_uString_assign):

> void SAL_CALL IMPL_RTL_STRINGNAME( assign )( IMPL_RTL_STRINGDATA** ppThis,
>                                              IMPL_RTL_STRINGDATA* pStr )
>     SAL_THROW_EXTERN_C()
> {
>     /* must be done at first, if pStr == *ppThis */
>     IMPL_RTL_AQUIRE( pStr );
> 
>     if ( *ppThis )
>         IMPL_RTL_STRINGNAME( release )( *ppThis );
> 
>     *ppThis = pStr;
> }