Re: [Patch] Another small memattr fix.

[Andrew Cagney <ac131313@cygnus.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