Hi Andrew, On Tuesday, 2018-05-15 13:43:15 +0000, Andrew Pitonyak wrote:
> Last time I documented Strings and arrays, an array index was limited to > +/-32K and a string was similarly limited. > > I am now documenting them again and I am hoping that someone knows off hand > what the new limitations are so that I do not need to scour the code to find > out. My best guess is that this now uses a 32-bit long, so, +/- 2G. While internally an SbxArray can handle uint32 indices, there still are the same limitations. For example DimArray() is limited to uint16 dimensions. The Array() function could digest uint16 (=64K) elements, but storage index still uses a short int16. Most code has been untouched, there still may be some other places that access things through a short (int16) which limits the reliable size to 32K elements. For strings OUString is used, which theoretically can hold int32 (=2G) UTF-16 code points during runtime, so that's probably the most interesting change (well, at least compared to 6 years ago or so). BUT, probably for some (stream?) compatibility (or oversight?), for example the TypeLen() function still returns an int16 value because the result is stored as an int16 (while seeing that, I think it could be fixed). Also, for persistent storage UTF-16 may have to be converted to a different encoding, which may halve or third the theoretical capacity depending on the actual characters used. Hope that helps Eike -- LibreOffice Calc developer. Number formatter stricken i18n transpositionizer. GPG key 0x6A6CD5B765632D3A - 2265 D7F3 A7B0 95CC 3918 630B 6A6C D5B7 6563 2D3A Care about Free Software, support the FSFE https://fsfe.org/support/?erack
signature.asc
Description: PGP signature
_______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice
