[pubcookie-dev] Re: time_t size problem

[Jon Miner]

Well, pbc_time_t would be defined as int32_t, of course..  I think it's
really the same solution, except that we'll make it easier on ourselves
if we need to transition to something else..

As well, it makes it clear what that int32_t is intended to be used as,
theoretically reminding us that we need to fix the "problem".

Is there any progress on the possibility of moving to an XML cookie
format, like we discussed so many years ago (can you believe that it's
been more than three years?!?) at the summit at UWash?

jon

* Nathan Dors (dors at cac.washington.edu) [051011 18:26]:
> >But, I don't know the "right" answer.  I was hoping that this might spur
> >some discussion.  As well, I don't have a 64-bit machine to test on
> >(yet).
> 
> The pragmatist in me likes the previously mentioned int32_t fix. 
> It seems to address the issue well enough for the next release, 
> and gives us plenty of time after that to consider the Y2038 
> issues.
> 
> But, Jon, it seems your thinking has moved on toward pbc_time_t. 
> Does the cast to int32 have risks that using our own data type and 
> truncation doesn't have? Either way it's got to be 32-bits for 
> now.
> 
> -Nathan

-- 
.Jonathan J. Miner------------------Division of Information Technology.
|miner at doit.wisc.edu                 University Of Wisconsin - Madison|
|608/262.9655                               Room 3146 Computer Science|
`---------------------------------------------------------------------'

"It is easier to port a shell than a shell script."
             -- Larry Wall
                                                              (77/708)