basic_string<>::max_size - only 1MB?
Gabriel Dos_Reis
Gabriel.Dos_Reis@sophia.inria.fr
Tue Jun 22 13:40:00 GMT 1999
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
More information about the Libstdc++
mailing list