It appears that recent changes to string have accidentally removed some
overflow checking that used to be in the basic_string::append() and
push_back() methods. The following patch adds the checks back in.
Travis
2007-09-20 Travis Vitek [EMAIL PROTECTED]
* string (append): add
Travis Vitek wrote:
It appears that recent changes to string have accidentally removed some
overflow checking that used to be in the basic_string::append() and
push_back() methods. The following patch adds the checks back in.
Travis
Lets try that again. This one has the correct method name
Martin Sebor wrote:
Travis Vitek wrote:
It appears that recent changes to string have accidentally
removed some overflow checking that used to be in the
basic_string::append() and push_back() methods. The following
patch adds the checks back in.
Does this fix a test failure? Or some
Martin,
I think that you are right in the case of push_back, or when the string
to append is short. My last testcase didn't prove anything. This one
does. If you use the current trunk, this prints '4 ' to the console.
i.e. appending 20 characters to a buffer with 240 should not get you 4,
Travis Vitek wrote:
Martin,
I think that you are right in the case of push_back, or when the string
to append is short. My last testcase didn't prove anything. This one
does. If you use the current trunk, this prints '4 ' to the console.
i.e. appending 20 characters to a buffer with 240
Martin Sebor wrote:
Travis Vitek wrote:
If that is the case, then why would we possibly need this
same code in any of the other methods that are used to extend
the original string?
I don't think we do, really. I suspect the main reason why the
code is in all other (out-of-line)
Travis Vitek wrote:
[...]
The change also seems unnecessary -- when size() equals capacity()
we check that it doesn't exceed max_size() before allocating more
memory in append(). Otherwise, when size() is less than capacity()
(or rather capacity() - 1), there should be no reason to check
against
Travis Vitek wrote:
Martin Sebor wrote:
Travis Vitek wrote:
If that is the case, then why would we possibly need this
same code in any of the other methods that are used to extend
the original string?
I don't think we do, really. I suspect the main reason why the
code is in all other
Martin Sebor wrote:
Travis Vitek wrote:
template class _TypeT
class Xallocator
{
public:
typedef unsigned char size_type;
I suspect the problem might actually be here. Once you define
size_type to a type with a more generous range the test case
passes. I made this and a few
Stupid outlook.
[21.3.5.2 p4] Effects: Determines the effective length rlen of the
string to append as the smaller of n and str.size() - pos. The function
then throws length_error if size() = npos - rlen.
The append that I'm invoking is described to behave as if it had called
that function.
Travis Vitek wrote:
Stupid outlook.
[21.3.5.2 p4] Effects: Determines the effective length rlen of the
string to append as the smaller of n and str.size() - pos. The function
then throws length_error if size() = npos - rlen.
The append that I'm invoking is described to behave as if it had
Travis Vitek wrote:
Martin Sebor wrote:
Travis Vitek wrote:
If that is the case, then why would we possibly need this
same code in any of the other methods that are used to extend
the original string?
I don't think we do, really. I suspect the main reason why the
code is in all other
12 matches
Mail list logo
