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: Don Howard <dhoward at redhat dot com>
- To: Andrew Cagney <ac131313 at cygnus dot com>
- Cc: Kevin Buettner <kevinb at redhat dot com>, <gdb-patches at sources dot redhat dot com>
- Date: Mon, 17 Jun 2002 10:46:28 -0700 (PDT)
- Subject: Re: [Patch] Another small memattr fix.
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