Re: [PATCH] Python 3 support, part 1 (non-testsuite part)

[<Paul_Koning@Dell.com>]

On Nov 13, 2012, at 1:53 PM, Tom Tromey wrote:

>>>>>> "Paul" ==   <Paul_Koning@Dell.com> writes:
> 
> ...Tom> Can we really assume a working wchar_t?
> 
> Paul> Yes, you'd expect a configure check or the like.  But the header files
> Paul> for Python reference that type without any checks that I can see.
> Paul> Similarly mbstowcs().  It looks like you can't built Python 3 if those
> Paul> aren't defined (which makes some sense -- how else could you build a
> Paul> program that uses Unicode for all its strings?).
> 
> Ok, I think that is sufficient.
> If Python ever adds checks, and we hit such a such a system, we can fix
> it up then.
> 
> It is a little weird since wchar_t isn't guaranteed to have anything to
> do with Unicode.  But I assume they know what they are doing.

It seems that way.  Python uses its own type internally if it has to, but uses wchar_t if that is suitable for storing Unicode in the way it wants to store it.  And the PySys_SetArgv call is specifically defined to take wchar_t arguments -- not the Python Unicode type that is used elsewhere.
> 
> Paul> Ok.  That code was adapted from Python 3 code which does it this way.
> Paul> The existing code in python.c calls a whole string of API calls (like
> Paul> PyModule_AddStringConstant) without checking the error status from any
> Paul> of them.  Should I add those, with the failure action being to disable
> Paul> Python support in GDB?
> 
> I'm not sure what to do about those.  I guess failing gracefully would
> be better than what we do now.
> 
> FWIW I'm not sure we really have a way to disable Python at runtime yet.
> And to be clear, I don't expect you to add this as part of your patch.
> Mostly I just want to avoid an 'exit' on a failure to initialize -- it
> is better for gdb to try to limp along in this situation.

Ok, I'll take out the exit and leave the error handling for a separate patch.
> 
> Paul> Index: py-inferior.c
> [...]
> Paul>    GDB_PY_HANDLE_EXCEPTION (except);
> 
> Paul> +#ifdef IS_PY3K
> Paul> +  PyBuffer_Release (pybuf);
> Paul> +#endif
> 
> GDB_PY_HANDLE_EXCEPTION can return, so cleaning up has to be handled
> there as well somehow.
> 
> Maybe this is an issue in the other spot, too, I couldn't tell
> immediately.

Oops.  I suppose I can do this via the "cleanup" mechanism, right?

	paul

> 
> Tom