Re: Proposed CHOST change for the 64bit time_t transition

One possible improvement would be to append "t32" if you want 32-bit 
time_t, instead of appending "t64" for 64-bit time_t. That way, people 
wouldn't be stuck with appending that confusing "t64" for the 
foreseeable future, and only specialists concerned with 32-bit time_t 
would need to know about the issue.

Personally, I hope backward-compatibility concerns don't require this 
sort of thing. I'd rather just switch, as Debian has.

I felt the same way about the 64-bit off_t back in the 1990s. It was 
obvious to me even at the time that we would have been significantly 
better off making off_t 64-bit, while keeping 32-bit off_t in the ABI 
for backward compatibility; this is what NetBSD did with time_t in 2012. 
Although I realize others felt differently, I never fully understood 
their concerns.

And here I am, three decades later, still having to make changes[1] to 
Autoconf's AC_SYS_LARGEFILE macro to continue to support that 
30-year-old off_t mistake, and now with 64-bit time_t interacting with 
64-off_t in non-orthogonal ways.

[1]: 
https://git.savannah.gnu.org/cgit/autoconf.git/commit/?id=b71143738516017f0e0d347a4025301c06c40254