[Patches] [Patch #103933] sys.path not set correctly when embedded

[noreply@sourceforge.net]

Patch #103933 has been updated. 

Project: python
Category: Windows
Status: Open
Submitted by: theller
Assigned to : mhammond
Summary: sys.path not set correctly when embedded

Follow-Ups:

Date: 2001-Feb-23 01:02
By: tim_one

Comment:
Mark overwrote your patch with his.  That is, his patch is *right here*. 
It's 4am here, and I have to get some sleep, so do try it!
-------------------------------------------------------

Date: 2001-Feb-23 00:23
By: theller

Comment:
I would be happy to test your new patch (running Win98 with VC6 under
VMWare under 2000), but where is it?

BTW: RegQueryInfoKey as documented, includes NULL!
-------------------------------------------------------

Date: 2001-Feb-22 23:44
By: mhammond

Comment:
OK - stepping through in the debugger, it appears as tho Win2k always gives
us a much bigger buffer.  Stepping through in the debugger with a value of
"foo" in the registry, 2k told me the buffer size was 8!  Can speculate as
to why, but that doesn't help.  Unfortunately, I don't have MSVC etc on my
9x box, but I can only speculate that there RegKeyQueryInfo() there works
as documented - returning exactly the size without room for the NULL. 
Hence we would hit this bug there.

Uploading a revised patch which has _not_ been tested on Win9x, but the
behaviour was verified in the debugger on 2k, even if the sizes werent set
to kill us.

I would be grateful if someone could test this on Win9x for me.  A
reasonable way to test is to rename your existing "2.1" key to "2.1_save",
and create a new key with just a PythonPath value.  Then copy Python.exe to
your temp dir and run it.

I'll check it in as soon as I hear someone has done that, or Tim tells me
to <wink>
-------------------------------------------------------

Date: 2001-Feb-22 22:58
By: mhammond

Comment:
Yes - Tim spotted it.

the dataSize returned from RegQueryInfoKey() does not include the NULL,
hence the one from thin air.  Ive added a comment :)  If skipcore is false,
we do indeed stick the extra semicolon for the non-existant sub-values, and
this makes the buffer one byte too small.

The code is still a little strange as it used to work on Win16, where the
sizes weren't available in advance.  I'll add a comment about that too ;-) 
I will work out an appropriate patch and submit a new version in a few
minutes.
-------------------------------------------------------

Date: 2001-Feb-22 22:06
By: tim_one

Comment:
Yes, I saw that.  I still want Mark to look at it, though:  the code isn't
clear (neither of us understands why it's doing what it's doing), and I
don't have the bandwidth to try to sort this out before the beta release.

You *may* have just hit the nail on the head:  if there are no subkeys and
skipcore is false, then "the preceding loop" didn't allocate any space for
this semicolon, and indeed the semicolon should *not* be there.  In that
case a correct fix is to suppress the semicolon, not to add 1 at random
beforehand (when the code is already murky, making it murkier is a Bad
Idea).

But, even in that case, it's unclear to me why

dataBuf = malloc((dataSize+1) * sizeof(TCHAR));

already adds a 1 pulled out of thin air.
-------------------------------------------------------

Date: 2001-Feb-22 08:36
By: theller

Comment:
There's another semicolon after the second loop, in the else-clause of the
if(skipCore) statement.

I'm not sure whether the semicolon should be inserted or not,
IF it is inserted, the buffer is too small and the RegQueryValueEx() fails
with error 234 (More data is available). Well, only on Win98 and if there
are no subkeys.
-------------------------------------------------------

Date: 2001-Feb-21 17:55
By: tim_one

Comment:
Assigned to Mark, as it's his code and I don't understand it offhand. 
Mark, this is a very simple (one-liner) patch.

theller, I don't understand your comment.  What semicolon are you talking
about?  The preceding loop incremented dataSize by the lengths of all
items, + one more for each item to hold a semicolon after it.  And that's
all the semicolons there are.

It appears to me that the second loop is *incorrect*, in that it adds a
semicolon whenever index>0, regardless of whether ppPaths[index] is or
isn't NULL, and so may end up inserting arbitrarily more semicolons than
the preceding loop saved space for.  But if that's what's going on, your
patch doesn't fix it in general, it would just cover up the simplest
failing case.
-------------------------------------------------------

Date: 2001-Feb-21 13:07
By: theller

Comment:
Assigned to Tim, one of the windows guys:-)

This is urgent.
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=103933&group_id=5470