[jira] [Issue Comment Edited] (STDCXX-1057) attempting to create a std::string of size 65535 or greater fails with Perennial CPPVS V8.1
[
https://issues.apache.org/jira/browse/STDCXX-1057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13202609#comment-13202609
]
Travis Vitek edited comment on STDCXX-1057 at 2/8/12 12:48 AM:
---
The question here is not what value should {{string::max_size()}} or
{{allocator::max_size()}} return. The question is should the
{{std::basic_stringT}} constructors use {{allocator::max_size()}} at all, or
should they just try to make the allocation request and allow the exception to
propagate out to the caller?
I believe that Martin is suggesting the constructors should consult
{{allocator::max_size()}} before making the allocation, and the Perennial
testcase seems to think that this behavior is forbidden. I read through all of
21.3.1 and didn't see anything that indicates there is a requirement either
way. There are requirements relating to this for functions that grow the
string, but I don't see anything for the string constructors. So, as Martin
suggests, this is _unspecified behavior_, and as such, the actual behavior is
_implementation defined_.
was (Author: vitek):
The question here is not what value should {{string::max_size()}} or
{{allocator::max_size()}} return. The question is should the
{{std::basic_stringT}} constructors use {{basic_stringT::max_size()}} or
{{allocator::max_size()}} at all, or should they just try to make the
allocation request and allow the exception to propagate out to the caller?
I believe that Martin is suggesting the constructors should consult
{{basic_stringT::max_size()}} before making the allocation, and the Perennial
testcase seems to think that this behavior is forbidden. I read through all of
21.3.1 and didn't see anything that indicates there is a requirement either
way. There are requirements relating to this for functions that grow the
string, but I don't see anything for the string constructors. So, as Martin
suggests, this is _unspecified behavior_, and as such, the actual behavior is
_implementation defined_.
That said, I did find
[LWG#83|http://www.open-std.org/Jtc1/sc22/wg21/docs/lwg-defects.html#83], which
indicates the addition of the following paragraph to the requirements of
{{std::basic_string}}
{quote}
For any string operation, if as a result of the operation, size() would exceed
max_size() then the operation throws length_error.
{quote}
A quick check of the C++11 standard shows that as [string.require] p1.
attempting to create a std::string of size 65535 or greater fails with
Perennial CPPVS V8.1
---
Key: STDCXX-1057
URL: https://issues.apache.org/jira/browse/STDCXX-1057
Project: C++ Standard Library
Issue Type: Bug
Components: 21. Strings
Affects Versions: 4.2.1, 4.2.x, 4.3.x, 5.0.0
Environment: Solaris 10 and 11, RedHat Linux, OpenSuSE Linux
SUN C++ Compilers 12.1, 12.2, 12.3
Defect is independent of compiler and platform
Reporter: Stefan Teleman
Labels: conformance, features, standards, test
Fix For: 4.2.x, 4.3.x, 5.0.0
Attachments: stdcxx-1057.patch, test.cc
in member function:
size_type basic_string_CharT, _Traits, _Allocator::max_size();
the maximum size of a basic_string is restricted to less than 65535 bytes.
The Standard is ambiguous as to what the max_size() of a std::string should
actually be (see LWG Core Issue 197). However, less than 65535 bytes for
the max_size of a std::string is rather small. GNU libstdc++ and stlport4
set std::string::max_size to (SIZE_MAX / 4) (i.e. 1GB). Solaris sets it
to SIZE_MAX.
Perennial CPPVS explicitly tests for the creation of a std::string of size
greater than 65535. In the current stdcxx implementation, this test fails.
The max_size of a std::string should be significantly greater than 65535
bytes.
Test to reproduce the defect:
{code:title=test.cc|borderStyle=solid}
#include iostream
#include string
const size_t maxlen = 65536U;
char array[maxlen];
struct test_traits : public std::char_traitschar
{ };
templateclass T
struct test_alloc : public std::allocatorT
{
typedef typename std::allocatorT::size_type size_type;
templateclass Y
struct rebind
{
typedef test_allocY other;
};
test_alloc() throw() { }
test_alloc(const test_alloc rhs) throw() { }
templateclass Y
test_alloc(const test_allocY y) throw() { }
~test_alloc() throw() { }
size_type max_size() const throw() { return maxlen; }
};
int main()
{
typedef
std::basic_stringchar, test_traits, test_allocchar test_string;
int ret = 0;
size_t i, j;
for (i = 0; i maxlen; i++)
array[i] = '*';
array[maxlen - 1] = '\0';
for (i = 0;
[jira] [Issue Comment Edited] (STDCXX-1057) attempting to create a std::string of size 65535 or greater fails with Perennial CPPVS V8.1
[
https://issues.apache.org/jira/browse/STDCXX-1057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13201791#comment-13201791
]
Travis Vitek edited comment on STDCXX-1057 at 2/7/12 12:09 AM:
---
I agree with Martin. I'll even go further to say that the testcase is incorrect
in that it expects an allocation larger than {{test_allocatorT::max_size()}}
to succeed.
was (Author: vitek):
I agree with Martin. I'll even go further to say that the testcase is
incorrect in that it expects an allocation larger than
{{test_allocatorT::max_size()}} to succeed. Overriding {{allocate()}} to
throw {{bad_alloc}} when such a request occurs should result in the testcase
throwing.
attempting to create a std::string of size 65535 or greater fails with
Perennial CPPVS V8.1
---
Key: STDCXX-1057
URL: https://issues.apache.org/jira/browse/STDCXX-1057
Project: C++ Standard Library
Issue Type: Bug
Components: 21. Strings
Affects Versions: 4.2.1, 4.2.x, 4.3.x, 5.0.0
Environment: Solaris 10 and 11, RedHat Linux, OpenSuSE Linux
SUN C++ Compilers 12.1, 12.2, 12.3
Defect is independent of compiler and platform
Reporter: Stefan Teleman
Labels: conformance, features, standards, test
Fix For: 4.2.x, 4.3.x, 5.0.0
Attachments: stdcxx-1057.patch, test.cc
in member function:
size_type basic_string_CharT, _Traits, _Allocator::max_size();
the maximum size of a basic_string is restricted to less than 65535 bytes.
The Standard is ambiguous as to what the max_size() of a std::string should
actually be (see LWG Core Issue 197). However, less than 65535 bytes for
the max_size of a std::string is rather small. GNU libstdc++ and stlport4
set std::string::max_size to (SIZE_MAX / 4) (i.e. 1GB). Solaris sets it
to SIZE_MAX.
Perennial CPPVS explicitly tests for the creation of a std::string of size
greater than 65535. In the current stdcxx implementation, this test fails.
The max_size of a std::string should be significantly greater than 65535
bytes.
Test to reproduce the defect:
{code:title=test.cc|borderStyle=solid}
#include iostream
#include string
const size_t maxlen = 65536U;
char array[maxlen];
struct test_traits : public std::char_traitschar
{ };
templateclass T
struct test_alloc : public std::allocatorT
{
typedef typename std::allocatorT::size_type size_type;
templateclass Y
struct rebind
{
typedef test_allocY other;
};
test_alloc() throw() { }
test_alloc(const test_alloc rhs) throw() { }
templateclass Y
test_alloc(const test_allocY y) throw() { }
~test_alloc() throw() { }
size_type max_size() const throw() { return maxlen; }
};
int main()
{
typedef
std::basic_stringchar, test_traits, test_allocchar test_string;
int ret = 0;
size_t i, j;
for (i = 0; i maxlen; i++)
array[i] = '*';
array[maxlen - 1] = '\0';
for (i = 0; i maxlen - 1; i+= 8)
{
array[i] = '\0';
test_string s(array);
j = s.size();
array[i] = '-';
if (i != j)
{
std::cerr i = i j = j expected i == j
std::endl;
ret = 1;
break;
}
}
return ret;
}
{code}
1. Output from GCC 4.5.0:
{noformat}
[steleman@darthvader][/src/steleman/programming/stdcxx-ss122/bugfixes-sunw/6889771][02/06/2012
10:16:34][2162] ./test-gcc
[steleman@darthvader][/src/steleman/programming/stdcxx-ss122/bugfixes-sunw/6889771][02/06/2012
10:16:48][2163] echo $status
0
{noformat}
2. Output from Sun C++ 12.2 with stlport:
{noformat}
[steleman@darthvader][/src/steleman/programming/stdcxx-ss122/bugfixes-sunw/6889771][02/06/2012
10:16:50][2164] ./test-ss122-stlport
[steleman@darthvader][/src/steleman/programming/stdcxx-ss122/bugfixes-sunw/6889771][02/06/2012
10:16:58][2165] echo $status
0
{noformat}
3. Output from Sun C++ 12.2 with our patched stdcxx:
{noformat}
[steleman@darthvader][/src/steleman/programming/stdcxx-ss122/bugfixes-sunw/6889771][02/06/2012
10:17:00][2166] ./test-ss122-stdcxx
[steleman@darthvader][/src/steleman/programming/stdcxx-ss122/bugfixes-sunw/6889771][02/06/2012
10:17:06][2167] echo $status
0
{noformat}
4. Output from Pathscale 4.0.12.1 (which did not patch stdcxx):
{noformat}
[steleman@darthvader][/src/steleman/programming/stdcxx-ss122/bugfixes-sunw/6889771][02/06/2012
10:17:08][2168] ./test-pathscale
Terminating due to uncaught exception 0x614240 of type std::length_error
Abort (core dumped)
[steleman@darthvader][/src/steleman/programming/stdcxx-ss122/bugfixes-sunw/6889771][02/06/2012
