Re: basic_string<>::max_size - only 1MB?

[Gabriel Dos_Reis <Gabriel.Dos_Reis@sophia.inria.fr>]

Nathan Myers <ncm@best.com> writes:

| Jason wrote:
| >>>>> Ryszard Kabatek <rysio@rumcajs.chemie.uni-halle.de> writes:
| 
| > > I think _Rep::_S_max_size should be increased to npos/40 (=100MB) or
| > > so. 
| >
| > Why not just (npos/sizeof(CharT)) - 1 ?
| 
| The correct value would be something like
|    ((~(size_t)0)-sizeof(_Rep)-1)/sizeof(_CharT) - 2.
| 
| Trying to create a string close to that size evokes a fatal bug in 
| common implementations of malloc.

Which reminds me something I thought was a bug in EGCS' current
implementation of new-expression. On a 32-bit machine where a double
is 64 bit wide, the following ends up with a seg fault

	int main()
	{
		size_t n = 1u << 29;
		double* = new double[n];
		p[0] = 0;
	}

I discussed the matter on egcs-bugs list with Alexandre, and finally I 
suspect a defect in the standard: what to do when an implementation
is faced with the request to create an object of size greater than 
numeric_limits<size_t>::max()?

In fact the situation is more pernicious

	#include <iostream>

	int main()
	{ 
		size_t n = 1u << 29;
		double array[n];
		std::cout << sizeof(array) << std::endl;
	}

I had private discussion with James Kanze. Both we agreed that an
undefined behaviour is unacceptable.  I haven't had time to ask on the 
core group.


-- Gaby