gstein@tigris.org writes:
> Log:
> Fix the string typemaps and fix svn_fs_commit_txn.
Thanks, Greg!
Question: does this portion
> --- trunk/subversion/bindings/swig/svn_fs.i (original)
> +++ trunk/subversion/bindings/swig/svn_fs.i Thu Feb 27 19:44:45 2003
> @@ -120,6 +122,22 @@
> $result = t_output_helper(
> $result,
> svn_swig_py_convert_hash(*$1, SWIGTYPE_p_svn_fs_path_change_t));
> +}
> +
> +/* -----------------------------------------------------------------------
> + Fix the return value for svn_fs_commit_txn(). If the conflict result is
> + NULL, then t_output_helper() is passed Py_None, but that goofs up
> + because that is *also* the marker for "I haven't started assembling a
> + multi-valued return yet" which means the second return value (new_rev)
> + will not cause a 2-tuple to be manufactured.
> +
> + The answer is to explicitly create a 2-tuple return value.
> +*/
> +%typemap(python, argout) (const char **conflict_p, svn_revnum_t *new_rev) {
> + /* this is always Py_None */
> + Py_DECREF($result);
> + /* build the result tuple */
> + $result = Py_BuildValue("zi", *$1, (long)*$2);
> }
... imply that we'll need to make a similar special-case for any other
Subversion function that returns multiple output parameters, where the
first one could return NULL by reference?
Obviously your change is a big improvement over the previous
workaround, no argument there :-). I'm just thinking there's still a
bug in SWIG itself (in t_output_helper), would you concur?
If so, I might spend an hour working up a patch for SWIG, unless
there's some deep theoretical reason why None has to mean what it
currently does in t_output_helper().
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Feb 28 16:20:16 2003