quetz-mod_python-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Graham Dumpleton" <grah...@dscpl.com.au>
Subject Re: mod_python 3.3.0-dev-20061109 tests on Win32
Date Thu, 16 Nov 2006 01:43:48 GMT
Jim Gallacher wrote ..
> Several of your other warnings such as:
> 
> C:\work\mod_python-3.3.0-dev-20061109\src\util.c(170) : warning C4244:
> 'function' : conversion from 'double' to 'long', possible loss of data
> 
> are the result of converting apr_time_t from microseconds to seconds:
> 
>          PyTuple_SET_ITEM(t, 9, PyInt_FromLong(f->ctime*0.000001));
> 
> In these cases your compiler is complaining needlessly. None the less,
> I 
> think multiplying by 0.000001 is both sloppy and error prone for these
> types of conversions.
> 
> I think we should do something like this:
> 
>          PyTuple_SET_ITEM(t, 9,
>                           PyInt_FromLong(f->ctime/ APR_USEC_PER_SEC));
> 	
> or perhaps use the apr_time_sec macro:
> 	PyTuple_SET_ITEM(t, 9, PyInt_FromLong(apr_time_sec(f->ctime)));
> 
> On the other hand, maybe some of these conversions could be considered
> bugs. Should the mtime, ctime and atime of the finfo object be 
> restricted to 1 second resolution? For comparison, req.request_time 
> converts to a float:
> 	PyFloat_FromDouble(time*0.000001)
> where time is also apr_time_t.

When I added struct style access in finfoobject, I deliberately left them as
int's to maintain a parallel to the fact that os.stat() under Python uses ints
still and that tuple access also used ints.

I remember also reading somewhere, which I can't now find, some discussion
about why stat structure in Python uses ints and doesn't use float when a
platform might provide for additional information. There was some good
reason for leaving it the way it was.

Graham

Mime
View raw message