From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13937 invoked by alias); 8 Jun 2012 17:41:37 -0000 Received: (qmail 13927 invoked by uid 22791); 8 Jun 2012 17:41:36 -0000 X-SWARE-Spam-Status: No, hits=-6.5 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,SPF_HELO_PASS,TW_FN,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 08 Jun 2012 17:41:23 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q58HfM3Z011386 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 8 Jun 2012 13:41:22 -0400 Received: from barimba (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q58HfLWB002351 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 8 Jun 2012 13:41:22 -0400 From: Tom Tromey To: Siva Chandra Cc: gdb-patches@sourceware.org Subject: Re: [RFC] Extend existing support for evaluating expressions using overloaded operators References: <87aa0in6ii.fsf@fleche.redhat.com> Date: Fri, 08 Jun 2012 17:41:00 -0000 In-Reply-To: (Siva Chandra's message of "Wed, 6 Jun 2012 00:03:39 +0530") Message-ID: <871ulpem66.fsf@fleche.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.97 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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-06/txt/msg00241.txt.bz2 >>>>> "Siva" =3D=3D Siva Chandra writes: Siva> If we want to extend the operator overloading support into Python, Siva> then we will have to have code to decide whether to call value_binop Siva> or value_x_binop in the py-value.c. Another client of these two Siva> functions is evaluate_subexp_standard, which also has code to decide Siva> whether to call value_binop or value_x_binop. Though I did not mention Siva> in my post, my intention is avoid such repetitive code and get all Siva> clients to depend only on value_binop and treat value_x_binop as Siva> 'internal'. I think you should start with this cleanup, then. After the current patch it seems to me that the code would be inconsistent. I think this idea is ok in the abstract but you have to be sure to audit all the existing uses to make sure it does the right thing. (I don't anticipate a problem here, but still...) Siva> I would like to follow this patch with another patch to do Siva> this change. Note that, only evaluate_subexp_standard calls Siva> value_x_binop currently. Hence, replacing these calls with value_binop Siva> should not be much work (though I have not yet come up with a way to Siva> deal with the 'noside' argument of value_x_binop). Letting that leak out of eval.c seems like a flaw. Tom> It would be nice if the test suite tested this case as well. Siva> I agree, I will add more tests after we finalize this patch. Siva> + =C2=A0 =C2=A0 =C2=A0TRY_CATCH (except, RETURN_MASK_ERROR) Siva> + =C2=A0 =C2=A0 =C2=A0 =C2=A0{ Siva> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/* Retrieve the list of methods w= ith the name NAME. =C2=A0*/ Siva> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0fns_ptr =3D value_find_oload_meth= od_list (&temp, name, Siva> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 0, &num_fns, Siva> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0&basetype, &boffset); Siva> + =C2=A0 =C2=A0 =C2=A0 =C2=A0} Siva> + =C2=A0 =C2=A0 =C2=A0if (except.reason < 0) Siva> + =C2=A0 =C2=A0 =C2=A0 =C2=A0fns_ptr =3D NULL; Tom> I'll have to go read this in more depth; but I wonder why it is ok to Tom> ignore exceptions here. Siva> An exception is thrown if we are trying to lookup methods of a Siva> non-struct and non-union type. One can ask that, in such cases, why Siva> call value_find_oload_method_list at all. My argument is, if Siva> value_find_oload_method_list is doing the check, why should we repeat Siva> before calling it. Throwing and catching an exception is much more expensive, and less clear, than just checking the type. Tom