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

[Fernando Nasser <fnasser at redhat dot com>]

I may have found a use for this test:

test the error message issued when no malloc() is available.

We can use Michaels code to test for malloc() and skip the tests if
malloc() is present.

If malloc() is NOT present, then we leave (do not delete) one of the
tests that has a string argument -- just one is enough -- and check for
the error message that is issued.


Question: which target would not have malloc() available?  Some embedded
target linked with newlib where neither the program nor any of the
library functions it calls use malloc()?


I guess this test will not run very often :-)




Fernando Nasser wrote:
> 
> Michael Elizabeth Chastain wrote:
> >
> > If malloc is not present, the script proceeds to test a bunch of things
> > that we believe should work.  It does not test things that we know,
> > by design, don't work.
> >
> 
> But the reason we know that these tests will work without malloc() is
> because they independ on malloc().
> 
> Thus, they have already been tested in callfuncs.exp (doesn't matter
> that the inferior had an malloc -- these things do not use it at all)
> and this whole callfwmall.exp is just useless.
> 
> I am now lead to believe that these tests would only be useful for
> targets that have an alternative way to deal with string arguments when
> malloc() is not available in the inferior.
> 
> As there are no such targets I propose we get rid of callfwmall.exp.  I
> never liked the spelling anyway -- it is unpronounceable.
> 
> Unless the HP dependent code is capable of doing this, them we move it
> to gdb.hp with only the tests that are related to malloc() -- the other
> are just repetition of callfuncs.exp in any case you may think of.
> 

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