This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [Patch] Another small memattr fix.
- From: Andrew Cagney <ac131313 at cygnus dot com>
- To: Don Howard <dhoward at redhat dot com>
- Cc: Kevin Buettner <kevinb at redhat dot com>,gdb-patches at sources dot redhat dot com
- Date: Sat, 15 Jun 2002 21:28:35 -0400
- Subject: Re: [Patch] Another small memattr fix.
- References: <Pine.LNX.4.33.0206141345140.3839-100000@theotherone>
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.
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.
I wouldn't trust the above expression to always do what you want.
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 :-)
Andrew