quetz-mod_python-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Gallacher <...@jgassociates.ca>
Subject Re: mod_python 3.3.0-dev-20061109 tests on Win32
Date Thu, 16 Nov 2006 02:06:07 GMT
Graham Dumpleton wrote:
> 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.

This changed in python 2.3. From the 2.4 docs:

"""Changed in version 2.3: If stat_float_times returns true, the time 
values are floats, measuring seconds. Fractions of a second may be 
reported if the system supports that. On Mac OS, the times are always 
floats. See stat_float_times for further discussion."""

I don't have a problem with leaving it as int however.

Jim


Mime
View raw message