[M3devel] 64bit file sizes now?

[Tony Hosking]

On 11 Jan 2010, at 22:02, Jay K wrote:

> So.. LONGINT as I understand will remain roughly as it was, except VAL(expr, INTEGER) is how you convert expr to INTEGER, instead of ORD(expire).

That's what I think makes most sense.

>  And this is already in place.

Yes, it's in place.

> ?
>  
> So I should go ahead and update File.i3/Status/size and Rd/Wr/Index/Seek/Length to all be LONGINT, "whatever the consequences"? The consequences are roughly the first diff I sent out, with the caveats that I used ORD() instead of VAL(,INTEGER), and a few packages were left to fix. It is mechanical and simple and predictable, just tedious and ugly.
> Most Rd/Wr users are limited to INTEGER "sizes" anyway, but a few might gain capacity.
> Classic simple example is the mklib and libdump code, they read the entire file into memory and then deal with that.

If the use-case is typically INTEGER then perhaps we need to think of alternatives using abstraction?

>  I can send the diffs ahead of time, but there's really no choices left as to what they'll look like, it is forced by the limited capability of LONGINT.
> Had they used LONGINT in the first place, of course, there'd be no diff at this time, the ugliness would have been builtin from the start.

When they originally wrote it large file sizes were only proposed not implemented.  I don't think C even had long long then.  (Yes, I am showing my age! -- we are talking almost 20 years ago now!)  If they had used LONGINT from the start then folks would have not had any ugliness because all would have used LONGINT.    Now, to save some hassles in future, perhaps we need a better abstraction!  Let's ponder that before you propagate your changes.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100111/f34e80d9/attachment-0002.html>