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
Attachment:
pgpYNVsG2sQbL.pgp
Description: PGP signature