std::string and bufferoverflow problem

[puzzlecracker]

Does string class take into consideration a poterntial buffer overflow
issue?

or does std:string::c_s tr() member functions does?

what are the preventives?

[John Carson]

"puzzlecrac ker" <ir*********@gm ail.com> wrote in message
news:11******** **************@ g49g2000cwa.goo glegroups.com

Does string class take into consideration a poterntial buffer overflow
issue?
string automatically expands the size of the buffer as required in most
contexts, e.g., the following program illustrates how capacity is
automatically increased:

#include <iostream>
using namespace std;

int main()
{
string str("Start");
for (int i=0; i<20; ++i)
{
cout << "capacity is " << str.capacity() << endl;
str += " addendum to string";
}
return 0;
}

or does std:string::c_s tr() member functions does?

c_str() returns a read only C-style string and the string class will
allocate whatever size buffer is needed to contain the C-style string. Of
course, as with any other class, if the computer doesn't have enough memory,
then the attempted memory allocation can fail.

If you are trying to write to the string's buffer by getting a pointer to
it, then you have no protection against buffer overflows. This operation is
undefined anyway.

--
John Carson

[John Carson]

"puzzlecrac ker" <ir*********@gm ail.com> wrote in message
news:11******** **************@ g49g2000cwa.goo glegroups.com

Does string class take into consideration a poterntial buffer overflow
issue?

As a follow-up to my other post, you can overflow the buffer using the
subscript operator since its use does not cause any automatic capacity
increase, e.g.,

#include <iostream>
using namespace std;

int main()
{
string str;
for (int i=0; i<100; ++i)
{
cout << "capacity is " << str.capacity() << endl;
str[i] = '0';
}
return 0;
}

If you use the at() member function instead, then you won't overflow the
buffer but you will get an out_of_range exception.

Note that a lot of string member functions can throw a length_error
exception if max_size() is exceeded. This max_size() is not capacity,
however. It is an upper bound on the size of any string. On my system
max_size() returns 4294967294.
--
John Carson

[Valentin Samko]

John Carson wrote:

c_str() returns a read only C-style string and the string class will
allocate whatever size buffer is needed to contain the C-style string.

c_str *may* allocate. Many STL implementations return the pointer to the internal string
buffer, ensuring that it has a terminating \0.

--

Valentin Samko - http://www.valentinsamko.com

[Jim Langston]

"puzzlecrac ker" <ir*********@gm ail.com> wrote in message
news:11******** **************@ g49g2000cwa.goo glegroups.com.. .

Does string class take into consideration a poterntial buffer overflow
issue?

or does std:string::c_s tr() member functions does?

what are the preventives?

std::string::c_ str() returns a const char *. It is constant, meaning you
can't change the data. Well, you could if you const_cast it, but then you
would get undefined behavior.

std::string::da ta() returns a char* that you can change the data. Normally
it is not null terminated I believe. This buffer is a fixed size though,
and you can overflow it.

so if you want to use std::string as a buffer direct into the data you need
to make sure that std::string allocates enough memory first (just as you
need to make sure a char array has enough elements).

[John Carson]

"Jim Langston" <ta*******@rock etmail.com> wrote in message
news:ks******** ********@fe06.l ga

std::string::da ta() returns a char* that you can change the data. Normally
it is not null terminated I believe. This buffer is a fixed
size though, and you can overflow it.

It returns a const char * so you cannot change it. The only difference from
c_str() is that it is not null terminated.

--
John Carson

[Jim Langston]

"John Carson" <jc************ ****@netspace.n et.au> wrote in message
news:dk******** ***@otis.netspa ce.net.au...

"Jim Langston" <ta*******@rock etmail.com> wrote in message
news:ks******** ********@fe06.l ga

std::string::da ta() returns a char* that you can change the data.
Normally it is not null terminated I believe. This buffer is a fixed
size though, and you can overflow it.

It returns a const char * so you cannot change it. The only difference
from c_str() is that it is not null terminated.

--
John Carson

Gah, you're right. I just looked up data() in MSDN and it does indeed also
return a const char*. Is there no way, then, to get a pointer to the data
of the std::string that can be changed?

[Mike Wahler]

"Jim Langston" <ta*******@rock etmail.com> wrote in message
news:_r******** ********@fe06.l ga...

"John Carson" <jc************ ****@netspace.n et.au> wrote in message
news:dk******** ***@otis.netspa ce.net.au...

"Jim Langston" <ta*******@rock etmail.com> wrote in message
news:ks******** ********@fe06.l ga

std::string::da ta() returns a char* that you can change the data.
Normally it is not null terminated I believe. This buffer is a fixed
size though, and you can overflow it.

It returns a const char * so you cannot change it. The only difference
from c_str() is that it is not null terminated.

--
John Carson

Gah, you're right. I just looked up data() in MSDN and it does indeed
also return a const char*. Is there no way, then, to get a pointer to the
data of the std::string that can be changed?

There's no need. We already have iterators (which
btw have as much potential for abuse as do pointers. :-) )

-Mike

[John Carson]

"Jim Langston" <ta*******@rock etmail.com> wrote in message
news:_r******** ********@fe06.l ga

Gah, you're right. I just looked up data() in MSDN and it does
indeed also return a const char*. Is there no way, then, to get a
pointer to the data of the std::string that can be changed?

No legal way. In fact, there is nothing in the standard that guarantees that
the data is stored in a contiguous array. In practice, you can probably get
the address of the (probably contiguous) buffer using &str[0] (where str is
the name of the string object), but this involves undefined behaviour.

--
John Carson