Re: [Patch] Another small memattr fix.

[Andrew Cagney <ac131313 at cygnus dot com>]

> > 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