From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10650 invoked by alias); 21 Sep 2008 04:27:58 -0000 Received: (qmail 10642 invoked by uid 22791); 21 Sep 2008 04:27:57 -0000 X-Spam-Check-By: sourceware.org Received: from NaN.false.org (HELO nan.false.org) (208.75.86.248) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sun, 21 Sep 2008 04:27:00 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id 90E27104BE; Sun, 21 Sep 2008 04:26:58 +0000 (GMT) Received: from caradoc.them.org (22.svnf5.xdsl.nauticom.net [209.195.183.55]) by nan.false.org (Postfix) with ESMTP id 656E1104BC; Sun, 21 Sep 2008 04:26:58 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.69) (envelope-from ) id 1KhGXB-0005vB-5A; Sun, 21 Sep 2008 00:26:57 -0400 Date: Sun, 21 Sep 2008 04:27:00 -0000 From: Daniel Jacobowitz To: Tom Tromey Cc: Thiago Jung Bauermann , gdb-patches ml Subject: Re: [rfc] expose gdb values to python Message-ID: <20080921042657.GB29631@caradoc.them.org> Mail-Followup-To: Tom Tromey , Thiago Jung Bauermann , gdb-patches ml References: <1221199426.24580.26.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2008-05-11) 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: 2008-09/txt/msg00451.txt.bz2 On Fri, Sep 19, 2008 at 04:39:12PM -0600, Tom Tromey wrote: > Thiago> I believe it's better to avoid using current_language, right? > Thiago> I don't think there's a way to get a sensible language_defn to > Thiago> use here, so my only idea is to add an element to struct value > Thiago> which holds the language associated with the value. This > Thiago> element would be filled at the moment the value is created. > > My first reaction to this was "no way". But, I couldn't think of a > concrete case where this would have bad results -- especially provided > we restrict use of the language field to stringifying the value. This seems iffy. A value's just a value - how it's printed depends on how it's used, not how it was created. e.g. if two languages had different number formatting, "print $1" should generate different results based on the current language. So what the right language is may depend on the context. > There are some intermediate ideas, too, like allowing the invisible > approach only when the field name is unique; or we could define the > search order. (It is tempting to use the language's rules, but I > suspect this might be too tricky to get right.) Why isn't this the same as for expression evaluation in GDB today? That does follow the language rules (and fail, in some cases). I'm not sure we really need length to work, but I haven't spent much time looking at it. If we don't, I'd rather it failed always than intermittently. -- Daniel Jacobowitz CodeSourcery