Re: STRING * n support in StarBasic

On 25/10/12 01:17, Norbert Thiebaud wrote:
> On Wed, Oct 24, 2012 at 6:41 PM, Stephan Bergmann <sbergman@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;
> }