Re: libstdc++ test suite still drives machine into swap

[Stephen M. Webb <stephen at bregmasoft dot com>]

On Wed, 01 Aug 2001, Phil Edwards wrote:
> On Thu, Aug 02, 2001 at 04:24:46AM -0400, Stephen M. Webb wrote:
> > Keep in mind that all of the max_size member functions are broken for
> > all the containers, it's just that there are no automated testsuite entires for
> > them (yet).  
> 
> Sorry, this is the first I can recall hearing of this.  Can you point me
> to the right place in the archives?  (Has this been brought up before?)

I can't say if it's been brought up before, but since using the result of any
tests of max_size on any containers (or anything using the default allocator)
will have the same exhaust-the-memory-till-you-die effect as basic_string,
I thought it was relevant.  I guess it's on the recod now.

I noticed while I was trying to write some fairly comprehensive test
suites that all the containers simply return size_type(-1) for max_size. 
That's incorrect for a number of reasons, least of which is that's not the
behaviour mandated by the standard, but it also means valid tests using
max_size would kill my machine regardless of whether the underlying
malloc lies or not, so I'm not including a test for it.  Even with that ulimit
fix to dejagnu, I can't guarantee certain categories of tests are valid unless
max_size returns valid numbers, although I can still run them without fear
of killing my machine.

Unfortunately the fix for max_size is somewhat large and convoluted.  It
would require proper (standard-mandated) support for allocators in the
containers, which should be a desireable thing anyway.  It would also
require that malloc not lie or that the default allocator work around that
lie somehow.

I though the first order of business before proposing such a change was to
develop a comprehensive regression and conformance test suite, one that
runs without killing my machine.  That's where what you were talking about
came in.

_______
Stephen M. Webb