Mailing-List: contact issues-help@stdcxx.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@stdcxx.apache.org
Date: Tue, 7 Feb 2012 18:38:59 +0000 (UTC)
From: "Martin Sebor (Commented) (JIRA)" <jira@apache.org>
To: issues@stdcxx.apache.org
Message-ID: 
 <2034153144.9446.1328639939220.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <1645572501.12343.1328407733846.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Commented] (STDCXX-1057) attempting to create a std::string
 of size 65535 or greater fails with Perennial CPPVS V8.1
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/STDCXX-1057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13202606#comment-13202606 ] 

Martin Sebor commented on STDCXX-1057:
--------------------------------------

I don't have access to too many other libraries but, IIRC, from talking to other implementers on the C++ committee when the function was discussed, other libraries tend to simply hardcode some large constant directly into {{basic_string::max_size()}}, making the function not terribly useful. The committee discussed a proposal to make the function more useful and chose to do nothing. Library Issue [197|http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#197] has the background. FWIW, I argued for a change that would make it possible (but not required) to provide (4) in the issue because that, in my view, would make the function the most useful. This is what stdcxx does.
                
> 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