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?