calc: jumbo sheets on windows (never gonna happen)

[Luboš Luňák]

On Friday 09 of October 2020, Michael Stahl wrote:
> On 09.10.20 11:10, Stephan Bergmann wrote:
> > On 09/10/2020 11:01, Michael Stahl wrote:
> >> POSIX provides ssize_t for this purpose but likely it doesn't exist on
> >> MSVC...

 That's not what (s)size_t is. Those are for representing size of in-memory 
objects, which I perceive as something slightly different. You could have a 
platform with 32bit size_t and 64bit coordinates.

> > 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.

 I'm afraid we'll end up needing to define it as a very generic type. If we go 
with row-heights-and-similar, such code shouldn't call any int/long code. But 
can we guarantee that? There's a good chance it'd cascade and spread all over 
the place.

 FWIW my personal opinion is that the normal type to use should be just 
plain 'int', unless there are special requirements. Sticking a specific 
precision all over the place is exactly how we've arrived to code full 
of 'sal_Int16' and 'sal_Int32'. But with our largest platform deciding that 
the native type on 64bit should be 32bit, the plain and simple 'int' indeed 
doesn't work out. 'loint', anyone :-/ ?

> 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...

 I'm not sure if that's me or you misunderstanding, but this is not about 
32bit Windows, it's about all Windows. Telling 90+% of our usebase to use 
their platform at their own risk is probably a really bad idea, even if that 
platform is Windows >:).

-- 
 Luboš Luňák
 l.lunak at collabora.com