From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13884 invoked by alias); 17 Jun 2002 17:47:00 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 13869 invoked from network); 17 Jun 2002 17:46:58 -0000 Received: from unknown (HELO cygnus.com) (205.180.83.203) by sources.redhat.com with SMTP; 17 Jun 2002 17:46:58 -0000 Received: from theotherone.redhat-remotie.org (romulus.sfbay.redhat.com [172.16.27.251]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id KAA06227; Mon, 17 Jun 2002 10:46:45 -0700 (PDT) Received: from localhost (localhost.fidalgo.net [127.0.0.1]) by theotherone.redhat-remotie.org (Postfix) with ESMTP id 331EDBB410; Mon, 17 Jun 2002 10:46:28 -0700 (PDT) Date: Mon, 17 Jun 2002 10:47:00 -0000 From: Don Howard X-X-Sender: To: Andrew Cagney Cc: Kevin Buettner , Subject: Re: [Patch] Another small memattr fix. In-Reply-To: <3D0BE9C3.90209@cygnus.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2002-06/txt/msg00303.txt.bz2 On Sat, 15 Jun 2002, Andrew Cagney wrote: > > >> I can think of three alternatives: > >> > >> [base, bound) > >> [base, bound] > >> [base, base+size-1) > > Try [base, base+(size-1)] > > (and the paren are important :-) > > >> > >> The first one is what the doco says and has been there for a while so I > >> don't think that changing it is a good idea. > >> > >> Internally, I suspect base+size-1 is the best representation. However, > >> for the user interface, is there anything that really says that: > >> > >> mem 0xfffffff0 0 > >> > >> is either illegal or poorly defined? > > > > > > > > The fact that the first bound is inclusive and the second is exclusive > > implies that to me. Also, the current implemntation enforces it. > > Don, sorry, I'm not sure what you mean here. The first bound == lower bound, second == upper (in the current implementation). The first/lower is included in the range, while the second/upper is excluded. I suppose it's gdb could allow the upper or the low in either position, but this would be susceptible to the overflow problem. > > How's this: let the parser find the size of the region for us: > > > > labs (parse_and_evaluate_long (tok1 " - " tok2)); > > I think it is better to evaluate low/high and then compute the range > directly. > This is where the maxint problem shows up, and is precisely what I was trying to avoid. There is no way to detect overflow. > I wouldn't trust the above expression to always do what you want. When would it not? Maybe the string should be: "(" tok1 ") - (" tok2 ")" ? Is there something about the expression parser that I am missing? > > > That seems to avoid the max int problem. Then we can use base and size > > as the internal representation. > > No matter what is done I think there will be an edge condition. For > instance: > > [base, base+(size-1)] > > doesn't work very well when base==0 :-) and size == 0, so don't permit size == 0. > > Andrew > > -- dhoward@redhat.com gdb engineering