[pywin32-bugs] [ pywin32-Bugs-3238774 ] Calls from VBScript clobber passed args

[SourceForge.net <no...@so...>]

Bugs item #3238774, was opened at 2011-03-23 15:20
Message generated for change (Comment added) made by mhammond
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3238774&group_id=78018

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
>Resolution: Invalid
Priority: 5
Private: No
Submitted By: Chris Lambacher (lambacck)
Assigned to: Nobody/Anonymous (nobody)
Summary:  Calls from VBScript clobber passed args

Initial Comment:
I am running into a bug that was submitted erroneously to the python language bug tracker: http://bugs.python.org/issue1156179

I am using v216 with Python 2.6.

The original reporter did some excellent detective work on what is happening. From his description:

I'm using Python 2.4.0 and VBScript under ASP on IIS 5. If I call a 
Python function from VBScript AND pass a local var as the first 
parameter AND don't use the return value, then the local var I 
passed in is, upon the function's return, set to Null.

If I store the return value (even if there isn't one) OR pass the return 
value to another function, this doesn't happen. I'm attaching some 
snippets that demonstrate and work around the bug.

He later updates the problem to be:
call go(x)
clobbers x, as I've said before, but...

call aTwoParamFunction("somethingStatic", x, y)
clobbers x as well! y is not clobbered.

If someone can point me in the general right direction, I am willing to try and fix the bug, but as of right now the active script stuff looks like a maze of twisty little passages, all alike.

----------------------------------------------------------------------

>Comment By: Mark Hammond (mhammond)
Date: 2012-01-27 21:01

Message:
Yeah - unfortunately I don't think we can change these semantics at this
stage.

----------------------------------------------------------------------

Comment By: Chris Lambacher (lambacck)
Date: 2011-03-25 11:01

Message:
Okay let me see if I understand this correctly (I've been looking at the
code of PyGatewayBase.cpp InvokeEx):

In python, there is no way to say I expect these parameters to be passed by
reference and pass values to those parameters so instead, a return tuple is
interpreted as:
    index 0: return value (pVarResult) , 
    subsequent values: the positional values of parameters listed as
by-ref
   
    if there is no pVarResult, assume that return values are only applied
to by-ref arguments (i.e. skip return value)
    
    if return value is not a tuple, interpret the one values as if it were
index 0 and apply same algorithm.
    

Is this documented somewhere? This scheme seems like an awful big burden to
put on the caller. What if the caller missed setting that a particular
value should be by-ref?

I expect we are stuck with it now because someone, somewhere is dependent
on this behavior :(

-Chris


----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2011-03-24 15:26

Message:
> Why do we need to pass the return value back if the caller does
not ask for it? 

The problem is that from Python's POV, the caller *has* asked for a result
to be placed in a BYREF param.  This is why there is no problem with only
BYVAL params as there is literally nowhere to put it.

----------------------------------------------------------------------

Comment By: Chris Lambacher (lambacck)
Date: 2011-03-24 12:55

Message:
I missed your earlier comment so my "discovery" would appear to be obvious
from the information you provided. It probably follows on that this happens
with other VB languages (like VBA) but not with javascript. 

Your answer about not having a place to put the return value sounds
correct. Why do we need to pass the return value back if the caller does
not ask for it? VB makes a distinction between Functions and Subroutines
and has a call convention that explicitly drops the return value using the
Call keyword or by not having parens around the function/method/sub
arguments.



----------------------------------------------------------------------

Comment By: Chris Lambacher (lambacck)
Date: 2011-03-24 12:20

Message:
More info:
Looks like this happens with a registered com object as well, so it seems
like it is an issue with values passed in to a COM function from at the
very least VBScript in IIS (I am using windows 7).

At least it gives me a place to look.

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2011-03-23 15:37

Message:
That is going to be very hard to avoid given the dynamic nature of Python
and VBScript  - when "go" returns (with an implied value of None or with
any explicit value), pythoncom looks for somewhere to stick the result.  As
the only place is the byref arg, that is where it is placed.  It is
probably possible to work around this by doing something like having the
function raise a COMServerException with a hresult of S_OK, or by tricking
VB into not passing the args byref.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3238774&group_id=78018