I filed issue #SVN-4781 for this.

The log message of r1700966 says it also affects the bindings of this 
function's higher-layer wrappers (which would be svn_repos_fs_change_rev_prop2, 
svn_ra_change_rev_prop2). I haven't checked this.

- Julian


Julian Foad wrote on 2018-10-26:
> svn_fs_change_rev_prop2(... old_value_p ...) crashes in 1.9.9.
> 
> The problem is with its 4th parameter, "const svn_string_t *const 
> *old_value_p".
> 
> In 1.10.x the binding throws an "unimplemented" exception instead of 
> crashing, because of the patch applied in
> http://svn.apache.org/r1700966 -- "Disable wrappers that aren't 
> working."
> This patch adds the following type-map in subversion/bindings/swig/
> include/svn_types.swg:
> 
> [[[
> %typemap(in,warning="901:FIXME: Missing old_value_p typemap") const 
> svn_string_t *const *old_value_p {
> ...
>   SWIG_exception(SWIG_ValueError, "$symname is not implemented yet");
> ...
> }
> ]]]
> 
> which changes the generated bindings as follows:
> [[[
> --- 1.9.x/obj-dir/subversion/bindings/swig/python/svn_ra.c
> +++ 1.10.x/obj-dir/subversion/bindings/swig/python/svn_ra.c
> @@ -7182,10 +7184,8 @@ SWIGINTERN PyObject *_wrap_svn_ra_change
>      }
>    }
>    {
> -    arg4 = (svn_string_t **)svn_swig_py_must_get_ptr(obj3, 
> SWIGTYPE_p_p_svn_string_t, svn_argnum_obj3);
> -    if (PyErr_Occurred()) {
> -      SWIG_fail;
> -    }
> +    SWIG_exception(SWIG_ValueError, "svn_ra_change_rev_prop2 is not 
> implemented yet");
> +    
>    }
>    {
>      if (obj4 == Py_None)
> ]]]
> 
> In both cases the generated code goes on like this:
> [[[
> ...
>     result = (svn_error_t *)svn_fs_change_rev_prop2(arg1,arg2,(char 
> const *)arg3,(struct svn_string_t const *const *)arg4,(struct 
> svn_string_t const *)arg5,arg6);
> ...
>     if (*arg4 == NULL) {
>       Py_INCREF(Py_None);
>       s = Py_None;
>     }
>     else {
>       s = PyString_FromStringAndSize((*arg4)->data, (*arg4)->len);
>       if (s == NULL)
>       SWIG_fail;
>     }
>     resultobj = SWIG_Python_AppendOutput(resultobj, s);
> ...
> ]]]
> 
> which is treating the parameter as if it were an output parameter as 
> most (TYPE **) parameters are, and assumes it is non-null, but this one 
> is an input parameter (and may be null).
> 
> Can anyone help me work out the correct type-map(s) for it?

Reply via email to