[Info-vax] 64-bit file sizes, was: Re: scp or sftp: file is "raw", needs to be parsed - possible to work around that?

[Stephen Hoffman]

On 2021-05-20 17:59:33 +0000, Simon Clubley said:

> It's also possible that when using higher-level languages such as C 
> with the C APIs they may just do what Linux does and just call 
> different versions in the glibc stat() call depending on whether you 
> are working with 32-bit or 64-bit variables.

I'd expect we'll see 32-bit values exposed in existing apps, 
discussions of C large-file support aside. Very few folks use 
large-file support.

> That might not work however due to the fact that you can have both 
> 32-bit and 64-bit pointers in the same image on VMS, unlike the either 
> 32-bit or 64-bit pointers seen in Linux binaries.

There is 32-bit virtual addressing for memory, and 32-bit storage 
addressing that's centrally involved here.

Apple deprecated the 32-bit virtual addressing APIs some years back, 
and removed those APIs with the previous macOS release.

macOS has had large-file support for many years, though. Linux too has 
had large-file support for a number of years.

It's been OpenVMS that's been limited to 32-bit 2 TiB storage 
addressing for ~twenty years.

> Also, will there need to be another version of RMS indexed files to 
> handle the larger file sizes ?

There are 32-bit LBNs in various parts of RMS and its APIs, and in the 
IO$_ACPCONTROL interface, and in the $qio interface, yes.

I'd expect to find 32-bit LBNs in the BASIC RTL, given BASIC wasn't 
updated for 64-bit addressing. Also in some (most?) storage-related 
add-on device drivers, too.

VSI will probably put together some 64-bit LBN migration documentation, 
but work on that is probably at least a year away and probably further.



-- 
Pure Personal Opinion | HoffmanLabs LLC