Problems with testdate

[Bojan Smojver <bo...@rexursive.com>]

Just bumped into this today, but it seems that in function
gm_timestr_822() of testdate.c, we are stuffing a 64-bit value
(apr_time_t) into something may be a lot shorter (time_t). So, errors
start occurring and test fails (Fedora 7, i686). I was thinking that we
should patch the test along the lines of the attached.

Thoughts?

-- 
Bojan

Re: Problems with testdate

[Bojan Smojver <bo...@rexursive.com>]

On Thu, 2007-09-13 at 09:14 +0100, Joe Orton wrote:

> It looks like the range of the test is supposed to be limited by that of 
> a 32-bit time_t, given the range of dates in year2secs.  If you make 
> that array simply an array of time_t or apr_int32_t, and drop the 
> INT64_C() casts, does it work?

The problem is in the second test, where this table isn't used.

The value of "guess" comes from the lgc() function, which can return
values that are out of range (time_t is signed 32-bit number and lgc()
returns unsigned values). Of course, "guess", being apr_time_t, happily
holds whatever apr_uint32_t can muster and more...

-- 
Bojan

Re: Problems with testdate

[Joe Orton <jo...@redhat.com>]

On Mon, Sep 10, 2007 at 02:09:43PM +1000, Bojan Smojver wrote:
> Just bumped into this today, but it seems that in function
> gm_timestr_822() of testdate.c, we are stuffing a 64-bit value
> (apr_time_t) into something may be a lot shorter (time_t). So, errors
> start occurring and test fails (Fedora 7, i686). I was thinking that we
> should patch the test along the lines of the attached.

It looks like the range of the test is supposed to be limited by that of 
a 32-bit time_t, given the range of dates in year2secs.  If you make 
that array simply an array of time_t or apr_int32_t, and drop the 
INT64_C() casts, does it work?

joe