RFC: time_t declaration

[Robert Millan]

On Wed, Dec 01, 2004 at 02:35:42PM +0100, Bruno Haible wrote:
> 
> Yes, this is the situation. More precisely, it's about the 64-bit CPU ports
> (such as alpha), and the __kernel_time_t is 32-bit, whereas I wanted the
> __time_t to be 64-bit.
> 
> I made this choice because 32-bit time_t will overflow in 2038. I expect
> that 32-bit systems will not be around any more at that time, but 64-bit
> systems will. So all systems which use 32-bit time_t on 64-bit platforms
> will have to change their time_t type till then. But time_t is part of
> the ABI offered by glibc, and changing it would require a change of the
> major version number of glibc.

Thanks, that was pretty clarifying.  Well I checked that Glibc declares
time_t as "long int" on all linux-gnu platforms, which AFAIK is always 32bit.
Are 64bit linux-gnu ports screwed?

> Now, a weak point in this argumentation is that the 'alpha' architecture
> is already nearly dead and will be dead before 2038. So it would be good
> to check what is the status of the other 64-bit ports in FreeBSD 5.3
> (AMD64, SPARC64 etc.). Is the 'alpha' architecture the only one with a
> 32-bit time_t or not? If yes, then we don't need the __kernel_time_t thing
> at all. If no, we need it.

Yes.  x86_64, sparc64 and ia64 all have int64_t.  So importing it from
kfreebsd headers (32bit on i386/alpha/arm/powerpc and 64bit on
x86_64/sparc64/ia64) is the way to go?

-- 
 .''`.   Proudly running Debian GNU/kFreeBSD unstable/unreleased (on UFS2+S)
: :' :
`. `'    http://www.debian.org/ports/kfreebsd-gnu
  `-