From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11538 invoked by alias); 20 May 2010 23:03:39 -0000 Received: (qmail 11462 invoked by uid 22791); 20 May 2010 23:03:39 -0000 X-SWARE-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 20 May 2010 23:03:31 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 4CADF2BB77F; Thu, 20 May 2010 19:03:30 -0400 (EDT) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id TegLun32eQ35; Thu, 20 May 2010 19:03:30 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 137FB2BB77E; Thu, 20 May 2010 19:03:30 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id E367AF58FA; Thu, 20 May 2010 16:03:26 -0700 (PDT) Date: Thu, 20 May 2010 23:04:00 -0000 From: Joel Brobecker To: Tom Tromey Cc: gdb-patches@sourceware.org Subject: Re: RFC: partially fix empty DW_OP_piece Message-ID: <20100520230326.GJ3019@adacore.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) 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: 2010-05/txt/msg00462.txt.bz2 > This patch "fixes" the problem in a simple way. Missing pieces are > filled with zeros, and read_pieced_value emits a warning, so that users > know not to fully trust the result. > > This is not an excellent fix. I think it is an improvement, but I can > understand if people would rather not see it go in. I also think that this is an improvement, and that it should go in. > I thought of two ways to implement the val_print part. One way would be > to make a temporary 'struct type' instance that encodes the validity in > the type somehow. The other way is to simply remove val_print entirely > and make all of printing work using values. I think this is the route I > would prefer. FWIW: I think that would be my preference indeed. Generally speaking, it looks like our struct type is headed for some major upgrades, once we start thinking about making some elements of a type dynamic (Eg: range type bounds, array bounds). But using a temporary type to track the validity of a field for a given entity does not seem to be the right idiom... -- Joel