[ 
https://issues.apache.org/jira/browse/STDCXX-1057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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_string<T>}} 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_string<T>}} constructors use {{basic_string<T>::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_string<T>::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_traits<char>
> { };
> template<class T>
> struct test_alloc : public std::allocator<T>
> {
>     typedef typename std::allocator<T>::size_type size_type;
>     template<class Y>
>     struct rebind
>     {
>         typedef test_alloc<Y> other;
>     };
>     test_alloc() throw() { }
>     test_alloc(const test_alloc& rhs) throw() { }
>     template<class Y>
>     test_alloc(const test_alloc<Y>& y) throw() { }
>     ~test_alloc() throw() { }
>     size_type max_size() const throw() { return maxlen; }
> };
> int main()
> {
>     typedef
>     std::basic_string<char, test_traits, test_alloc<char> > 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
>  10:17:13][2169]>> echo $status
> 134
> {noformat}
> Patch for 4.2.1 to follow shortly.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Reply via email to