Date: Sat, 30 Apr 2011 01:39:12 +0530 From: "Jayachandran C." <c.jayachandran@gmail.com> To: Warner Losh <imp@bsdimp.com> Cc: freebsd-mips@freebsd.org Subject: Re: 64 bit time_t in 32 bit ABI? Message-ID: <BANLkTi=vdkPNGwpi=CBNecMjbS%2B=S44suA@mail.gmail.com> In-Reply-To: <DD2906D8-811B-4CFB-B899-2AC88FF26720@bsdimp.com> References: <BANLkTimdbgabRCBbdjR1L45DtkETDT1UNw@mail.gmail.com> <DD2906D8-811B-4CFB-B899-2AC88FF26720@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Apr 30, 2011 at 12:54 AM, Warner Losh <imp@bsdimp.com> wrote: > I thought we made all new architectures adopt a 32-bit time_t and that's = why it is this way. Although it is not required by standard, having time_t as long is (in my opinion) would be the least surprising implementation. Having it 'long long' on 32-bit will avoid the 2038 issue, but it also makes us incompatible with other platforms and might trip up some programs. That said, if this is a decision that has been taken, we will abide by that= . JC. > Warner > > On Apr 29, 2011, at 11:36 AM, Jayachandran C. wrote: > >> In sys/mips/include/_types.h, I see >> >> | 119 typedef __int64_t =A0 =A0 =A0 __time_t; =A0 =A0 =A0 =A0 =A0 =A0 = =A0 /* time()... */ >> >> Which as far as I can see, is not right for the 32-bit ABIs. But this >> definition has been there for a long time, so I would like to know if >> there is any reason for this? >> >> Since this is a user-visible type, changing it would break binary compat= ibility. >> >> Thanks, >> JC.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?BANLkTi=vdkPNGwpi=CBNecMjbS%2B=S44suA>