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
