From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19441 invoked by alias); 19 Oct 2011 20:56:37 -0000 Received: (qmail 19367 invoked by uid 22791); 19 Oct 2011 20:56:36 -0000 X-SWARE-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from qmta06.westchester.pa.mail.comcast.net (HELO qmta06.westchester.pa.mail.comcast.net) (76.96.62.56) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 19 Oct 2011 20:56:19 +0000 Received: from omta18.westchester.pa.mail.comcast.net ([76.96.62.90]) by qmta06.westchester.pa.mail.comcast.net with comcast id mkqH1h0091wpRvQ56kwK32; Wed, 19 Oct 2011 20:56:19 +0000 Received: from [10.127.238.91] ([65.206.2.68]) by omta18.westchester.pa.mail.comcast.net with comcast id mkw81h02f1U2a2h3ekwBoK; Wed, 19 Oct 2011 20:56:17 +0000 Subject: Re: Python: fetch value when building gdb.Value object Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Paul Koning In-Reply-To: Date: Wed, 19 Oct 2011 20:58:00 -0000 Cc: gdb-patches@sourceware.org Content-Transfer-Encoding: quoted-printable Message-Id: <92D17899-A614-4333-87BE-E9746DFB8AB8@comcast.net> References: <36B29E9D-F2B3-446F-AF8A-97254A3AAEE2@comcast.net> <21467A42-84A3-4DFD-83A9-28FFFB0A5C7F@comcast.net> <2F165381-183F-471F-8F55-457F08E6B008@comcast.net> To: Tom Tromey 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: 2011-10/txt/msg00544.txt.bz2 On Oct 19, 2011, at 4:51 PM, Tom Tromey wrote: >>>>>> "Paul" =3D=3D Paul Koning writes: >=20 > Paul> At this point the change has been approved and committed (that > Paul> happened before your comments arrived). So I guess we have a quest= ion > Paul> of whether to change it back. >=20 > Yes, I think so. I think the current approach is going to bite us > later. We already have bugs open about bad memory management using > gdb.Value. Ok, I will work on that. I think the exception handling fixes that were done recently takes care of = the fact that some of the places where the lazy fetch exception could occur= weren't correctly trapped inside Python. Then the other part will be a do= cumentation change, to spell out clearly the fact that operating on a gdb.V= alue type can raise an exception at that time. For example, for a Value ob= ject v, the expression "v+1" can result in an exception (unlike what is usu= ally true for Python variables of most types). paul