From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30237 invoked by alias); 21 Aug 2012 15:28:09 -0000 Received: (qmail 30206 invoked by uid 22791); 21 Aug 2012 15:28:07 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_HOSTKARMA_NO 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; Tue, 21 Aug 2012 15:27:52 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 778201C7641; Tue, 21 Aug 2012 11:27:51 -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 QxXZDCJA1qIR; Tue, 21 Aug 2012 11:27:51 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 3FD591C762A; Tue, 21 Aug 2012 11:27:50 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id AFD9E14561A; Tue, 21 Aug 2012 08:27:40 -0700 (PDT) Date: Tue, 21 Aug 2012 15:28:00 -0000 From: Joel Brobecker To: Tom Tromey Cc: gdb-patches@sourceware.org Subject: Re: RFC: printing pointers to global (data) variable on Windows... Message-ID: <20120821152740.GR2798@adacore.com> References: <20120816152255.GA2836@adacore.com> <87zk5umwj3.fsf@fleche.redhat.com> <20120816224524.GC2798@adacore.com> <87628hmwbr.fsf@fleche.redhat.com> <20120817231554.GF2798@adacore.com> <20120820150849.GQ2798@adacore.com> <87mx1ph2qd.fsf@fleche.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87mx1ph2qd.fsf@fleche.redhat.com> 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: 2012-08/txt/msg00571.txt.bz2 > What about defaulting it to zero, applying the appended, and then fixing > up the fallout? I thought about that too, and got concerned about missing some places. However, I very much like one thing about your patch, which is the fact that it now forces the use of a "setter" to change the value of the msymbol size, and that answers my main worry. And just because of the "setter" alone, I'd go with this approach. We could go with this appraoch independently of the has_size flag first, and then add the flag. The one tiny concern is for readers that did not set the size of zero-sized symbols because it knew that the default was already zero. > I could do the mechanics of this if you think it is ok; and if you plan > to go forward with this. Thanks for the kind offer - I brought this up, I should really be doing the work... -- Joel