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
