Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (nike.apache.org: domain of jorton@redhat.com designates
 66.187.233.31 as permitted sender)
Date: Thu, 13 Sep 2007 09:14:46 +0100
From: Joe Orton <jorton@redhat.com>
To: Bojan Smojver <bojan@rexursive.com>
Cc: APR Development List <dev@apr.apache.org>
Subject: Re: Problems with testdate
Message-ID: <20070913081446.GB309@redhat.com>
Mail-Followup-To: Bojan Smojver <bojan@rexursive.com>,
	APR Development List <dev@apr.apache.org>
References: <1189397383.22304.93.camel@shrek.rexursive.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <1189397383.22304.93.camel@shrek.rexursive.com>
User-Agent: Mutt/1.4.2.1i
Organization: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor,
 Berkshire, SL4 1TE, United Kingdom.
  Registered in UK and Wales under Company Registration No. 03798903
  Directors: Michael Cunningham (USA), Brendan Lane (Ireland),
 Matt Parson (USA), Charlie Peters (USA)

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