From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15282 invoked by alias); 14 Jun 2002 20:00:20 -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 15242 invoked from network); 14 Jun 2002 20:00:15 -0000 Received: from unknown (HELO cygnus.com) (205.180.83.203) by sources.redhat.com with SMTP; 14 Jun 2002 20:00:15 -0000 Received: from romulus.sfbay.redhat.com (romulus.sfbay.redhat.com [172.16.27.251]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id NAA17449; Fri, 14 Jun 2002 13:00:14 -0700 (PDT) Received: (from kev@localhost) by romulus.sfbay.redhat.com (8.11.6/8.11.6) id g5EK09K24923; Fri, 14 Jun 2002 13:00:09 -0700 Date: Fri, 14 Jun 2002 13:00:00 -0000 From: Kevin Buettner Message-Id: <1020614200008.ZM24922@localhost.localdomain> In-Reply-To: Don Howard "Re: [Patch] Another small memattr fix." (Jun 14, 12:44pm) References: To: Don Howard Subject: Re: [Patch] Another small memattr fix. Cc: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2002-06/txt/msg00250.txt.bz2 On Jun 14, 12:44pm, Don Howard wrote: > The strings are arbitrary expressions and are converted to address via > parse_and_eval_address(), which does not flag overflow: > > mem_command (char *args, int from_tty) > { > CORE_ADDR lo, hi; > char *tok; > struct mem_attrib attrib; > > if (!args) > error_no_arg ("No mem"); > > tok = strtok (args, " \t"); > if (!tok) > error ("no lo address"); > lo = parse_and_eval_address (tok); > > tok = strtok (NULL, " \t"); > if (!tok) > error ("no hi address"); > hi = parse_and_eval_address (tok); > > mabe parse_and_eval_address could detect overflow and throw an error(). Maybe I'm missing something, but it seems to me that you're still left with the problem of how to represent the maximum address + 1. (Throwing an error doesn't really help, does it?) > Another possiblity is that the interface could be changed, making the > upper bound inclusive also. This sounds better. So, on a 16 bit machine, you could say mem 0xf000 0xffff ro to indicate that the top 4096 bytes are read-only. Kevin