Hi, On Tuesday, 2013-01-15 14:16:42 +0100, Michael Stahl wrote:
> > * What about the associated type xub_StrLen ?
>
> good question... there is code that loops over the sal_Unicode UTF-16
> code units in the string (Note: those are not "characters"). since
> String has a maximum capacity of 2^16, and the xub_StrLen is a "short",
> and OUString of 2^31 the indexes in such loops most likely need to be
> adapted to sal_Int32.
Special care has to be taken of constant values STRING_NOTFOUND,
STRING_MATCH, STRING_LEN and STRING_MAXLEN that with a 16-bit xub_StrLen
do not match the then real world of 32-bit OUString offsets.
For example, a
if (String.Search(...) == STRING_NOTFOUND)
replaced with
if (OUString.indexOf(...) == STRING_NOTFOUND)
will not work.
Also loops and conditions that check STRING_MAXLEN will likely have to
be rewritten from unsigned 16-bit to signed 32-bit.
Additionally, an OUString's maximum capacity will be 2GB, so places that
chopped off String's data after an implicit STRING_MAXLEN now would
consume almost everything thrown at them which may have to be inspected.
A string length of several hundred MB usually is an error, unless proper
measurements have been taken.
Eike
--
LibreOffice Calc developer. Number formatter stricken i18n transpositionizer.
New GnuPG key 0x65632D3A : 2265 D7F3 A7B0 95CC 3918 630B 6A6C D5B7 6563 2D3A
Old GnuPG key 0x293C05FD : 997A 4C60 CE41 0149 0DB3 9E96 2F1A D073 293C 05FD
Support the FSFE, care about Free Software! https://fsfe.org/support/?erack
pgpTbL4QTo4hD.pgp
Description: PGP signature
_______________________________________________ LibreOffice mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/libreoffice
