[PATCH] osutil: implementation for Win32

Petr Kodl petrkodl at gmail.com
Tue Sep 9 16:10:44 CDT 2008


Benoit - sorry for sending the reply twice - missed the reply all

> +static int to_python_time(FILETIME* ms_time)
> > +{
> > +       /* this is number of 100-nanoseconds between epoch and January 1
> 1601 */
> > +       static __int64 a0 = (__int64)134774L * (__int64)24L
> > +                                               * (__int64)3600L *
> (__int64)1000L
> > +                                               * (__int64)1000L *
> (__int64)10L;
> > +       /* conversion factor back to 1s resolution required by Python
> ctime */
> > +       static __int64 a1 = 1000 * 1000 * 10;
>
> good point - I'll change it
>
> > +       __int64 tmp;
> > +       memcpy(&tmp, ms_time, sizeof(__int64));
>
> why not directly return (int)(*ms_time - a0)/a1 ?


potential alignment  problem by direct pointer cast
http://blogs.msdn.com/oldnewthing/archive/2004/08/25/220195.aspx

>
> > +       char path[_MAX_PATH + 1];
> > +       char *buffer = path;
> > +       int plen = _MAX_PATH - 2;
> > +
> > +       int keepstat = 0;
> > +
> > +       static char *kwlist[] = {"path", "stat", NULL};
> > +
> > +       if (!PyArg_ParseTupleAndKeywords(args, kwargs, "et#|O:listdir",
> > +                       kwlist, Py_FileSystemDefaultEncoding, &buffer,
> &plen, &statobj))
> > +               goto error;
>
> What if plen is then > _MAX_PATH ?
>
>
That should be OK - the PyArg_... should bail out as per documentation of
es# format if the buffer is not large enough.
There is technically incorrect behavior in one edge case - when real length
is MAX_PATH-1 and the string passed in ends with \ already, in that case the
function would still accept the argument, but only single character entities
could be legally returned and form valid ANSI path. No sure is this is worth
the extra error handling.

pk
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://selenic.com/pipermail/mercurial-devel/attachments/20080909/c06664a9/attachment.htm 


More information about the Mercurial-devel mailing list