[Fwd: Re: Switch SPARC GNU coreutils+bash from 32 to 64bit [PSARC/2008/351]

[Nicolas Williams]

On Mon, Jun 02, 2008 at 11:24:02AM -0700, Alan Coopersmith 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

Wait a minute.  Our stdio does not support more than 256 open FILEs if
you use it right (it does entail raising the soft fildes limit; the
utilities we're talking about may not fork()/exec() other programs that
don't know how to use stdio the new way, so raising the soft fildes
limit when the utility starts should be OK).

> 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

Well, not using time-related functions provided by the OS anyways.

> large file compilation flags only raised the sizes to 64-bit, not the
> timestamps).

True.  Overall I think the switch to 64-bit executables on SPARC can be
justified on a case-by-case basis (or group-by-group, or all at once).

Nico
--