Re: [RFA] Assuming malloc exists in callfwmall.exp

Fernando Nasser
2001-02-15T08:09:00Z

Michael Elizabeth Chastain wrote:
>
> Fernando's proposal is to remove coverage of #3 and #4.
>

You may have missed some messages from me and Kevin.

Both Kevin and I are now proposing a minimal test for #4 (#3 does not
depend on malloc() so it is already tested in callfuncs).

It would consist of your test for the presence of malloc() and, if it
indeed is not there, a *single* test for the error message.

Michael Elizabeth Chastain wrote:
>
> Hi Fernando,
>
> > The other case to be tested is when there isn't a malloc() available at
> > all (that is why the test Keith and you proposed is so nice). But the
> > FAILs are wrong. Not having malloc() available is not GDB's fault and
> > it may be just a limitation of the target environment.
>
> I think there are four use cases.
>
> Use case #1:
>
> . malloc is available
> . the user types: call abs(-10)
> . gdb expected response: "$1 = 10"
>
> Use case #2:
>
> . malloc is available
> . the user types: call strlen("foo")
> . gdb expected response: "$1 = 3"
>
> Use case #3:
>
> . malloc is not available
> . the user types: call abs(-10)
> . gdb expected response: "$1 = 10"
>
> Use case #4:
>
> . malloc is not available
> . the user types: call strlen("foo")
> . gdb expected responses: either one of
> . "$1 = 3"
> . error: evaluation of this expression requires the program to have a function "malloc"
>
> callfuncs.exp tests #1 and #2.
> callfuncs.exp can never test #3 or #4.
>
> callfwmall.exp, as written, tests use case #3 (on some platforms).
>
> callfwmall.exp, as written, has an incorrect test for #4. It accepts only
> the first response, but gdb can produce either response, and the current
> gdb produces the second response.
>
> Keith's patch removes use case #4 from the test coverage.
>
> Michael's patch makes callfwmall.exp verify that it gdb+inferior is in the
> regime of #3 and #4. If gdb+inferior is not, then callfwmall.exp returns
> UNTESTED. If gdb+inferior is in that regime (inferior has no malloc),
> then it tests #3 only. I could make it test #4 properly by adding more RE's.
>
> Fernando's proposal is to remove coverage of #3 and #4.
>
> Kevin's evidence is that Linux native, and probably every glibc platform,
> never enters the regime of #3 and #4 anyways.
>
> Michael

--
Fernando Nasser
Red Hat Canada Ltd. E-Mail: fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario M4P 2C9