From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32737 invoked by alias); 13 Nov 2012 19:02:51 -0000 Received: (qmail 32729 invoked by uid 22791); 13 Nov 2012 19:02:51 -0000 X-SWARE-Spam-Status: No, hits=-5.3 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,RP_MATCHES_RCVD,TW_RG X-Spam-Check-By: sourceware.org Received: from ausc60pc101.us.dell.com (HELO ausc60pc101.us.dell.com) (143.166.85.206) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 13 Nov 2012 19:02:41 +0000 X-Loopcount0: from 10.175.216.249 From: To: CC: Subject: Re: [PATCH] Python 3 support, part 1 (non-testsuite part) Date: Tue, 13 Nov 2012 19:02:00 -0000 Message-ID: References: <87mwyma6xi.fsf@fleche.redhat.com> <87390d8hdf.fsf@fleche.redhat.com> In-Reply-To: <87390d8hdf.fsf@fleche.redhat.com> Content-Type: text/plain; charset="us-ascii" Content-ID: <9DEFA3982504DB41A0B3548B4DEA4E7B@dell.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2012-11/txt/msg00330.txt.bz2 On Nov 13, 2012, at 1:53 PM, Tom Tromey wrote: >>>>>> "Paul" =3D=3D writes: >=20 > ...Tom> Can we really assume a working wchar_t? >=20 > Paul> Yes, you'd expect a configure check or the like. But the header fi= les > 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 th= ose > Paul> aren't defined (which makes some sense -- how else could you build a > Paul> program that uses Unicode for all its strings?). >=20 > 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. >=20 > 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 u= ses 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. >=20 > Paul> Ok. That code was adapted from Python 3 code which does it this wa= y. > Paul> The existing code in python.c calls a whole string of API calls (li= ke > Paul> PyModule_AddStringConstant) without checking the error status from = any > Paul> of them. Should I add those, with the failure action being to disa= ble > Paul> Python support in GDB? >=20 > I'm not sure what to do about those. I guess failing gracefully would > be better than what we do now. >=20 > 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 patc= h. >=20 > Paul> Index: py-inferior.c > [...] > Paul> GDB_PY_HANDLE_EXCEPTION (except); >=20 > Paul> +#ifdef IS_PY3K > Paul> + PyBuffer_Release (pybuf); > Paul> +#endif >=20 > GDB_PY_HANDLE_EXCEPTION can return, so cleaning up has to be handled > there as well somehow. >=20 > 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 >=20 > Tom