Re: this in

[Ryszard Kabatek <rysio@rumcajs.chemie.uni-halle.de>]

On Thu, 1 Jul 1999, benjamin kosnik wrote:
 
> Also, I think that your reserve patch breaks 21_strings/insert.cc and
> 21_strings/ctor_copy_dtor.cc, so you might want to have a look at those
> files.

I found the reason for the core dump.
It has nothing to do with my patch.
It is the changed value returned by basic_string<>::max_size.

21_strings/insert.cc at line 82:

  csz01 = str01.max_size();
  try {
    string str04(csz01, 'b');
//...

After the last change str01.max_size() returns the value 4294967282.

GNU malloc has an old known bug - if the requierd size exceeds 
INT_MAX - 10 
it fails but it not returns 0. So in C++ no exception will be thrwon.

On my system (RH Linux 5.1, i686 with 256MB) in the sample below
malloc should return 0, but...

# include <malloc.h>
# include <assert.h>
# include <limits.h>

int main()
{
  char* p;
  assert((p = (char*)malloc(INT_MAX - 11)) == 0);

  assert((p = (char*)malloc(INT_MAX - 10)) == 0); // line 10
}

if I run the executable I get:
m.cc:10: 
int main(): Assertion `(p = (char*)malloc(2147483647 - 10)) == 0' failed.
Aborted (core dumped)


The same reason causes the problems in  21_strings/ctor_copy_dtor.cc. 

This is a problem for the configure script. On systems that not use 
GNU malloc it should not make any problems. 
A better solution wolud be somebody would fix the malloc function. 

Ryszard Kabatek
Martin-Luther University Halle-Wittenberg, Department of Physical Chemistry
Geusaer Str. 88, 06217 Merseburg, Germany
Tel. +49 3461 46 2487 (2466) Fax. +49 3461 46 2129