[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: rev 5143 - trunk/subversion/bindings/swig

From: Greg Stein <gstein_at_lyra.org>
Date: 2003-03-01 03:49:36 CET

On Fri, Feb 28, 2003 at 08:45:26AM -0600, Karl Fogel wrote:
> gstein@tigris.org writes:
>...
> > +%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?

Well, technically it is where the type mapping results in Py_None for the
first value in a multi-valued return. NULL pointers map to that, but we
could envision others.

In any case... yes, the same problem could occur elsewhere. I'm not sure how
many of those exist.

> 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?

Yup, as I similarly explained in another email to Marshall.

> 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().

Right now, SWIG initializes the result to Py_None so that you have something
to return. You could probably initialize that to NULL to indicate nothing so
far, and a t_output_helper replacement would differentiate between NULL and
"already got a return value".

But at the point that "return resultobj;" is performed, you'd need to do
something like:

  if (resultobj)
    return resultobj;
  Py_INCREF(Py_None);
  return Py_None;

I bet SWIG has a way to alter the return processing, but I don't know it off
the top of my head. I also hope there is a way to alter that initial value
for the result object. In the worst case, those might be hard-coded into the
SWIG Python "language" mechanism, which would then require a patch to SWIG.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Mar 1 03:44:54 2003

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.