> On May 31, 2017, at 12:32, Alan Coopersmith <alan.coopersm...@oracle.com> > wrote: > > On 05/31/17 09:19 AM, Richard L. Hamilton wrote: >> Aside from executables that reference timestamps (given that a signed >> twos-complement will overflow after Tue Jan 19 03:14:07 2038 GMT), and for >> programs that will never need to manipulate files larger than 2GiB-1 (unless >> they use large file support), is it necessarily desirable to upgrade >> user-space binaries at all? On x86, ok you get more registers and such; but >> on SPARC, I've heard you may be better off with V8 (or V8+), given smaller >> binaries, better use of cache, etc. > > Remember that any program that calls stat() on a file references timestamps > and can get stat() failures with an out-of range timestamp. > > Also as noted in the blogs various newer features either work better with > 64-bit > pointers (like ASLR) or can only work with 64-bit pointers (like ADI on > SPARC). > >> Ok, thinking about it, now that static libc is gone, with the time issues, a >> 32-bit libc would be an invitation to forget that it wouldn't work with >> something that used timestamps, not to mention whatever complications follow >> from maintaining support for 32-bit executables. > > All very true too - at some point there's going to be little benefit in > maintaining a second copy of every single shared library for all those > 32-bit programs, plus all the translation layers in the kernel for 32-bit > syscalls. That point is probably years in the future, but certainly > less than 20 years from now.
The alternative would be a large times analog of large file support; why that wasn't done when 64-bit began, I don't understand. :-)
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ openindiana-discuss mailing list openindiana-discuss@openindiana.org https://openindiana.org/mailman/listinfo/openindiana-discuss
