From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3110 invoked by alias); 7 Dec 2009 20:08:57 -0000 Received: (qmail 3011 invoked by uid 22791); 7 Dec 2009 20:08:55 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS 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; Mon, 07 Dec 2009 20:08:47 +0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id nB7K855W020919 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 7 Dec 2009 15:08:05 -0500 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id nB7K84FI011453; Mon, 7 Dec 2009 15:08:04 -0500 Received: from opsy.redhat.com (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id nB7K7vYo031983; Mon, 7 Dec 2009 15:08:04 -0500 Received: by opsy.redhat.com (Postfix, from userid 500) id 8BB413782A2; Mon, 7 Dec 2009 13:07:57 -0700 (MST) From: Tom Tromey To: Hilfinger@adacore.com Cc: brobecker@adacore.com, gdb-patches@sourceware.org Subject: Re: [RFA] 64-bit range types in GDB References: <20091204081343.A8718227B32@nile.gnat.com> <20091205121800.DB060227B32@nile.gnat.com> Reply-To: Tom Tromey Date: Mon, 07 Dec 2009 20:08:00 -0000 In-Reply-To: <20091205121800.DB060227B32@nile.gnat.com> (Paul Hilfinger's message of "Sat, 5 Dec 2009 07:18:00 -0500 (EST)") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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: 2009-12/txt/msg00088.txt.bz2 >>>>> "Paul" == Paul Hilfinger writes: Paul> Hmm. Sticky. There's this comment on 'length' in struct type: Paul> /* Length of storage for a value of this type. This is what Paul> sizeof(type) would return; use it for address arithmetic, Paul> memory reads and writes, etc. .... Paul> But then the code goes on to define 'unsigned length'. However, Paul> according to the C standard, the type should really be Paul> size_t---and technically that should be the TARGET's size_t. I Paul> suspect this part of the representation hasn't been updated since Paul> the days when people actually used 16-bit address spaces. What do Paul> you suppose people would say to using size_t here at least? size_t won't help on 32-bit hosts. There is also ULONGEST. struct type and struct main_type are size-critical. It would be nice not to grow them. I suppose it depends on how much we care about objects bigger than 4G. An error would be cheaper :-) I'm open to either approach, though. Tom