468,491 Members | 2,041 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 468,491 developers. It's quick & easy.

c_str() does a SEGSEGV

Hi

I have a program within which i have the following statement.

sprintf(somevar,"%s/%s.%s",PREFIX.c_str( ),MIDDLE.c_str(
),SUFFIX.c_str( ) );

Here PREFIX, MIDDLE and SUFFIX are all const strings.

This works fine but recently after close to 1000 successful runs my
program dumped with SIGSEGV.

I did a bt on the core file at gdb prompt and found that the problem is
with c_str( )

I am using gcc 3.2.3
libstdc++.so.5

on RH linux AS 3.

Is the spriontf statement correct , or is there any better way.

thanks
Shyam

Sep 27 '06 #1
12 4793
Dnia 27 Sep 2006 02:47:52 -0700, shyam napisał(a):
sprintf(somevar,"%s/%s.%s",PREFIX.c_str( ),MIDDLE.c_str(
),SUFFIX.c_str( ) );
What is "somevar" ?
Is the spriontf statement correct , or is there any better way.
Did you try to use stringstream or normal string concatenation?

--
SirMike - http://www.sirmike.org

C makes it easy to shoot yourself in the foot; C++ makes it harder, but
when you do, it blows away your whole leg. - Bjarne Stroustrup
Sep 27 '06 #2
shyam wrote:
Hi

I have a program within which i have the following statement.

sprintf(somevar,"%s/%s.%s",PREFIX.c_str( ),MIDDLE.c_str(
),SUFFIX.c_str( ) );

Here PREFIX, MIDDLE and SUFFIX are all const strings.

This works fine but recently after close to 1000 successful runs my
program dumped with SIGSEGV.

I did a bt on the core file at gdb prompt and found that the problem is
with c_str( )

I am using gcc 3.2.3
libstdc++.so.5

on RH linux AS 3.

Is the spriontf statement correct , or is there any better way.
I'd blame some of your (not shown) code that probably
overwrites some internal memory of the strings, hence
the c_str() segfault.

<OT>
If you are on a 32-bit platform, try valgrind to pinpoint
the error.
</OT>

HTH,
- J.
Sep 27 '06 #3
I havent used string or stringstream concatenation.
And i am not using these const strings in any other way.

I feel it is better to concatenate these three strings into one string
object and then so a c_str( ) on that object.

Jacek Dziedzic wrote:
shyam wrote:
Hi

I have a program within which i have the following statement.

sprintf(somevar,"%s/%s.%s",PREFIX.c_str( ),MIDDLE.c_str(
),SUFFIX.c_str( ) );

Here PREFIX, MIDDLE and SUFFIX are all const strings.

This works fine but recently after close to 1000 successful runs my
program dumped with SIGSEGV.

I did a bt on the core file at gdb prompt and found that the problem is
with c_str( )

I am using gcc 3.2.3
libstdc++.so.5

on RH linux AS 3.

Is the spriontf statement correct , or is there any better way.

I'd blame some of your (not shown) code that probably
overwrites some internal memory of the strings, hence
the c_str() segfault.

<OT>
If you are on a 32-bit platform, try valgrind to pinpoint
the error.
</OT>

HTH,
- J.
Sep 27 '06 #4
shyam wrote:
I havent used string or stringstream concatenation.
And i am not using these const strings in any other way.

I feel it is better to concatenate these three strings into one string
object and then so a c_str( ) on that object.
Why? char* is not a #$*&@!@ string. It's a pointer to
a single character. This isn't C.

string somevar = PREFIX + '/' + MIDDLE + '.' + SUFFIX;

or

ostringstream os;
os << PREFIX << "/" << MIDDLE << "." << SUFFIX;
string somevar = os.str();

Sep 27 '06 #5

Ron Natalie wrote:
shyam wrote:
I havent used string or stringstream concatenation.
And i am not using these const strings in any other way.

I feel it is better to concatenate these three strings into one string
object and then so a c_str( ) on that object.

Why? char* is not a #$*&@!@ string. It's a pointer to
a single character. This isn't C.
You are correct but i want the final string in char * form and not C++
string
string somevar = PREFIX + '/' + MIDDLE + '.' + SUFFIX;

or

ostringstream os;
os << PREFIX << "/" << MIDDLE << "." << SUFFIX;
string somevar = os.str();
Sep 27 '06 #6

shyam wrote:
Ron Natalie wrote:
shyam wrote:
I havent used string or stringstream concatenation.
And i am not using these const strings in any other way.
>
I feel it is better to concatenate these three strings into one string
object and then so a c_str( ) on that object.
Why? char* is not a #$*&@!@ string. It's a pointer to
a single character. This isn't C.

You are correct but i want the final string in char * form and not C++
string
Well, it's your hair. You're problem could very well be a buffer
overrun. This is what happens when you use buffers...they eventually
bite you really hard.

Sep 27 '06 #7
On 27 Sep 2006 08:07:48 -0700, I waved a wand and this message
magically appears in front of shyam:
Why? char* is not a #$*&@!@ string. It's a pointer to
a single character. This isn't C.

You are correct but i want the final string in char * form and not C++
string
Use c_str() on the resulting string. Simple.
--
http://www.munted.org.uk

You've been eating the cat food again, haven't you?
Sep 27 '06 #8
Hi,
I'm not sure, but I think c_str() allocates new memory which has to be freed
by delete.
shyam wrote:
Hi

I have a program within which i have the following statement.

sprintf(somevar,"%s/%s.%s",PREFIX.c_str( ),MIDDLE.c_str(
),SUFFIX.c_str( ) );

Here PREFIX, MIDDLE and SUFFIX are all const strings.

This works fine but recently after close to 1000 successful runs my
program dumped with SIGSEGV.

I did a bt on the core file at gdb prompt and found that the problem is
with c_str( )

I am using gcc 3.2.3
libstdc++.so.5

on RH linux AS 3.

Is the spriontf statement correct , or is there any better way.

thanks
Shyam
Sep 27 '06 #9
Thorsten Kiefer wrote:
Hi,
I'm not sure, but I think c_str() allocates new memory which has to be freed
by delete.
Not a 'delete' in user code, that's for sure.

- J.
Sep 27 '06 #10
Thorsten Kiefer wrote:
Hi,
I'm not sure, but I think c_str() allocates new memory which has to
be freed by delete.
If c_str() allocates extra memory, the std::string has to handle the
deallocation itself. User code has to do nothing.
Bo Persson
Sep 27 '06 #11
shyam wrote:
Ron Natalie wrote:
>shyam wrote:
>>I havent used string or stringstream concatenation.
And i am not using these const strings in any other way.

I feel it is better to concatenate these three strings into one string
object and then so a c_str( ) on that object.
Why? char* is not a #$*&@!@ string. It's a pointer to
a single character. This isn't C.

You are correct but i want the final string in char * form and not C++
string
>string somevar = PREFIX + '/' + MIDDLE + '.' + SUFFIX;

or

ostringstream os;
os << PREFIX << "/" << MIDDLE << "." << SUFFIX;
string somevar = os.str();
char* crappy_c_string = new char[somevar.size() + 1];
memcpy(crappy_c_string, somevar.c_str(), somevar.size() + 1];

Sep 27 '06 #12
"shyam" <sh********@gmail.comwrites:
I have a program within which i have the following statement.

sprintf(somevar,"%s/%s.%s",PREFIX.c_str( ),MIDDLE.c_str(
),SUFFIX.c_str( ) );

Here PREFIX, MIDDLE and SUFFIX are all const strings.

This works fine but recently after close to 1000 successful runs my
program dumped with SIGSEGV.
snprintf is dangerous and flawed, it should not be used in C code, let
alone C++ code.

For C, use snprintf, for C++, use std::stringstream and/or
std::string as other have already suggested.

My bet is that your somevar buffer is to small to hold some of your
resulting formatted strings. That's exactly why that function
shouldn't be used.
I did a bt on the core file at gdb prompt and found that the problem is
with c_str( )
That would surprise me. In the above statement, there is nothing wrong
except the potential buffer overflow. What exactly is gdb telling you?

Regards,

Jens
Sep 27 '06 #13

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

4 posts views Thread by Ericcson | last post: by
15 posts views Thread by Derek | last post: by
2 posts views Thread by Vyacheslav Kononenko | last post: by
2 posts views Thread by diadia | last post: by
5 posts views Thread by Alfonso Morra | last post: by
4 posts views Thread by Alex Vinokur | last post: by
7 posts views Thread by matish | last post: by
8 posts views Thread by puzzlecracker | last post: by
3 posts views Thread by gieforce | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.