Alan Coopersmith <Alan.Coopersmith at sun.com> wrote:
> Richard L. Hamilton wrote:
> >> I can think of three main categories of capacity limits on 32-bit that
> >> might
> >> be higher on 64-bit:
> >> * file size max of 2GB
> >> * register size and usage
> >> * available address space, and therefore amount that can be mmap()'d
> >> at once
> >> (Also, IIRC stdio is supposed to handle > 256 file pointers on 64-bit.)
>
> Yes, the 256 FILE stdio limit is lifted in 64-bit. The other main
> advantage I'm aware of is 64-bit time_t, so you can work with timestamps
> outside the 1970-2038 range, which there is no way to do in 32-bit (the
> large file compilation flags only raised the sizes to 64-bit, not the
> timestamps).
The main problem with the Solaris largefile compile environment is that it
forgot to include time stamps. It would be simple to add another
gettimeofday().... and time_t implementation with e.g. -DLARGETIME
It would unfortunately only work if there would be another stat(2) interface
for this purpose as this would affect the layout of struct stat.
If this is not done, we would need 64 bit versions of all programs that call
stat(2) on files that may have time stamps outside the permitted range for a 32
bit program. This may be any file from NFS or PCFS, so this are many/all
programs using stat(2) and even important programs like find(1)
are still missing from the list of 64 bit programs on Solaris.
J?rg
--
EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin
js at cs.tu-berlin.de (uni)
schilling at fokus.fraunhofer.de (work) Blog:
http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
