[bind10-dev] 64 bit time_t on NetBSD 6.0

Shane Kerr shane at isc.org
Thu Mar 15 20:24:01 UTC 2012


All,

On Thursday, 2012-03-15 10:28:39 -0700, 
JINMEI Tatuya / 神明達哉 <jinmei at isc.org> wrote:
> At Wed, 14 Mar 2012 18:36:31 +0000,
> Francis Dupont <fdupont at isc.org> wrote:
> 
> > > Yes. http://bind10.isc.org/ticket/911
> > > 
> > > > system I know to have strong support(ers) in BIND10.
> > > 
> > > Should we prioritize it?
> > 
> > => I shan't complain if you do it (:-)!
> 
> I've added it to the proposed list for the next sprint, although I'm
> not sure how popular this ticket will be.

The issue is... that I'm not sure what the issue is.

The original ticket involves needing to set some defines for headers to
get time_t to be 64-bits in some systems, I thought.

Right now most Linux 64-bit systems use 64-bit time_t values, and BIND
10 builds, passes the tests, and seems to run okay. So I don't think
there are any major problems using 64-bit time_t, although of course
there could be some untested corner case somewhere not handled properly.

So, what exactly are we supposed to do? Is this just a Y2K type thing
where the idea is to audit the code and make sure it is 64-bit time_t
compliant? Or is it about adding defines to the build to use 64-bit
time_t when available and required?

If the issue is about a Y2K-style audit, then I'm not sure it is urgent
in the absence of any reason to think things are broken.

If the issue is about setting magic defines on some systems, then I
think we have problems that affect users more than this issue, at least
for the next 20 years or so.

Other opinions may vary, of course. And I might have the completely
wrong idea about the goals here!

--
Shane


More information about the bind10-dev mailing list