Re: [PATCH] Fix diff build on arm

[Paul Eggert]

Bruno Haible <address@hidden> writes:

> The 64-bit time_t obviously has the purpose to avoid year-2038 problems.[3]

I think by the time 2038 rolls around, ARM will either be extinct or
will have 64-bit 'long int'.  In the meantime what's the rush?

The current ARM reference manual already hints that future versions
will have 64-bit addresses; it says address arithmetic wraps around
now but: "However, to minimize the chances of incompatibility if the
address space is extended in the future, programs should never be
written so that they rely on this behavior. Address calculations
should be written so that their results would still lie in the range 0
to 2^32-1 if they were calculated without wrap-around."  I am quoting
from
<http://forums.arm.com/index.php?s=b51b7b5d9fff06049408295641d427d3&showtopic=2242>.

I suppose FreeBSD could port to these future machines with 32-bit
'long int' and 64-bit addresses, but so far only Microsoft has been
so, ahem, recalcitrant (with its IA64 port of Microsoft Windows).  I
hope FreeBSD doesn't make a similar mistake.

> I guess that more platforms will follow the lead of FreeBSD,

I hope not, at least not for time_t being wider than 'long int'.

> similarly to the switch to a 64-bit off_t for which FreeBSD was also
> ahead of other systems.

This is a bit off the subject, but I think FreeBSD got that from
4.4BSD, around 1995.  But 64-bit off_t came well before that in
commercial systems.  I vaguely recall that Amdahl UTS was using 64-bit
off_t in the early 1980s.

Anyway, I suppose if this FreeBSD ARM port takes off we'll have to
port gnulib to it.  I'm not looking forward to that.  Perhaps someone
else with some free time could do it....