Kevin Phillips added the comment:

I should mention that I did discover some source code on GitHub, presumably for 
this wrapper module, and I believe I found a few questionable parts in the 
logic for this library that may help explain the cause of this problem:

https://github.com/python-git/python/blob/master/PC/_msi.c

Here are some snippets from the summary_getproperty function that may help:

    char sbuf[1000];
    char *sval = sbuf;
    DWORD ssize = sizeof(sval);

First, here, I believe the ssize value is not going to be initialized as one 
would expect at first glance. Since sval is a pointer and sizeof() returns the 
size of it's parameter, in this case a pointer, ssize will represent the 
pointer size on the target platform. In this case, on a 64bit OS, it's likely 
going to be set to 8, which I suspect the expected value for ssize is going to 
be 1000 - the size of the static array sbuff.

    status = MsiSummaryInfoGetProperty(si->h, field, &type, &ival, 
        &fval, sval, &ssize);
    if (status == ERROR_MORE_DATA) {
        sval = malloc(ssize);
        status = MsiSummaryInfoGetProperty(si->h, field, &type, &ival, 
            &fval, sval, &ssize);
    }

Now, in this snippet it tries to load the string value from the file, and if 
the input buffer is not of sufficient size it reallocates the pointer to an 
appropriate size. Given the fact that ssize is probably initialized to 8 (or 
less) it is pretty safe to assume the first call to MsiSummaryInfoGetProperty 
changes this value to the length of the data stored in the file. Closer 
examination of the documentation for this Windows API function reveals that in 
this case ssize will be set to the number of characters required 'not including 
the terminating null character'. 
(http://msdn.microsoft.com/en-us/library/aa370409(v=vs.85).aspx)

    result = PyString_FromStringAndSize(sval, ssize);

Then finally I noticed this function call. I suspect the problem may lie here. 
I'm not too familiar with the Python SDK but it sounds like when using Unicode 
strings - as all string are in Python 3 - you are supposed to use 
PyUnicode_FromStringAndSize instead. So perhaps there might be something 
getting lost in the translation, either via the use of this function or perhaps 
subsequent marshalling of the string object into the Python runtime, due to the 
encoding changes... not sure. It could be something as simple as one of the 
function calls used therein assume that the 'size' count includes a null-byte 
while others don't. It's hard to say without digging into the libs some more.

I hope this helps.

----------

_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue22391>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Reply via email to