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.


Reply via email to