Re: [Patch] Another small memattr fix.

[Don Howard <dhoward@redhat.com>]

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