On 09.10.20 11:10, Stephan Bergmann wrote:
On 09/10/2020 11:01, Michael Stahl wrote:
On 08.10.20 21:13, Noel Grandin wrote:
As some point we are going to have to deal with this "long" stuff, it
really is not a great thing to have one 64-bit platform operating at
half the bit-size of the other platform.
Here is one option:
(a) create some new typedef, something like the old sal_Long, aliased
to "long"
(b) replace "long" with typedef in stages (so no functional change).
(c) switch the typedef of sal_Long to point to sal_Int64 and fix
fallout.
Then rolling back (even if temporarily) is easy and the "flag day" is
a 2 line change.
POSIX provides ssize_t for this purpose but likely it doesn't exist on
MSVC...
Would that be a useful abstraction for "accumulat[ing] things like
row-heights and other things", or would a more explicit "must be at
least 64-bit wide" type be more appropriate there.
afaik the only relevant 32-bit platform left is Windows, and it's
already rather restricted with big files because of how it handles
embedded objects; you'll run out of VM at ~250 math formulas iirc, due
to wasteful implementation of native OLE.
so we could use a platform-dependent type for this and say, use 32-bit
platform at your own risk...
_______________________________________________
LibreOffice mailing list
LibreOffice@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/libreoffice
