[C++-sig] Segfault with keyword arguments and overloads.

[Alex Mohr]

Thanks for your response.  I've responded to your comments in-line below.

After further investigation, I believe this can be fixed by simply 
checking for None when we get 'kv' from f->m_arg_names while resolving 
keywords.  If we encounter None, that means the overload doesn't accept 
a keyword argument in that position (so not enough positional args were 
passed), and we can reject the overload.

If it works, I think that's a simple, targeted fix that isn't 
particularly risky.  I'll try to work up a patch.

On 8/7/2013 3:21 AM, Alex Leach wrote:
> I think the signature looks incorrect here. From my understanding of
> signatures, if you define one argument name, you should define the name
> for all arguments. On class methods, this includes adding an arg for
> 'self'.

That makes sense if I was interested in the auto-docstring generation, 
but I'm not: in fact we don't use it.

Reading the docs for boost::python::def, and 
boost::python::class_<>::def, it seems like trailing keyword arguments 
are supported:

http://www.boost.org/doc/libs/1_54_0/libs/python/doc/v2/def.html#def-spec
http://www.boost.org/doc/libs/1_54_0/libs/python/doc/v2/class.html#class_-spec

In particular, "If the longest valid prefix of A1 contains N types and 
a1 holds M keywords, an initial sequence of the keywords are used for 
all but the first N - M arguments of each overload."

Moreover, it would surprise me if boost.python demanded that if you want 
any argument to be a keyword argument then *all* arguments must be 
keyword arguments, and the code appears to be written to allow a mixture 
of positional and keyword arguments.

> Also, it seems strange that you're assigning the final argument a
> default value, when the actual C++ function has none. I did add the
> corresponding default argument to the C++ function signatures, but that
> still seg faults, so I guess you've got default arguments in your actual
> code (good minimal example, though!). However, the function signature in
> the documentation - ie. from `help(kwargCrash)` - looks correct.

I could have added default args to the C++ functions, but they'd never 
be used and thus seemed superfluous so I left them out.

And yes, thanks, providing keyword arguments for all arguments does 
workaround the crash, but it's not a very practical option for me, since 
I have at least tens of thousands of lines of boost.python wrapping code 
to deal with.

It would be nice to just fix the crash bug and have this use-case work 
correctly.

Alex