Jump to content
  • Advertisement
Sign in to follow this  
raydog

strcat, strcpy, strcrap functions

This topic is 4874 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I think I have a memory leak problem, but I can't track it down. It has to do with the runtime string functions strcat() and strcpy(). Strcat is cutting off my string. It's never the full string I'm expecting. I even get stranger results when I move the declaration of certain strings around. I'm just doing simple things like: CHAR temp1[256]; CHAR temp2[256]; strcpy( temp1, "Some text" ); strcpy( temp2, "Some text" ); strcat( temp1, temp2 ); This is almost impossible to debug. When I put in some logging functions, the leak goes away. When I take them out, I get corrupted strings again. And I don't want to use strncat or strncpy. I've had really bad experiences with those functions. Can't use MFC CString either. I'm just wondering can these two functions be internally corrupted somehow, so even if I call them with 'good' strings, they will still give me back bad results? Does anyone write their own string functions because they get corrupted strings from using these runtime functions?

Share this post


Link to post
Share on other sites
Advertisement
It is highly unlikely that the functions are internally corrupted. If adding logging functions appears to make the problem go away, it is usually an indication that your are overwriting a local pointer or writing too many bytes to a local string/array. The problem may be with asking strcpy/strcat to copy more bytes than you've allocated for the target. Or it could be something somewhere else in your code.

Share this post


Link to post
Share on other sites
Try these simple examples...if they work then it's your code that's wrong.

/* strcpy example */
#include <stdio.h>
#include <string.h>

int main ()
{
char str1[]="Sample string";
char str2[40];
char str3[40];
strcpy (str2,str1);
strcpy (str3,"copy successful");
printf ("str1: %s\nstr2: %s\nstr3: %s\n",str1,str2,str3);
return 0;
}


Output:
str1: Sample string
str2: Sample string
str3: copy successful

/* strcat example */
#include <stdio.h>
#include <string.h>

int main ()
{
char str[80];
strcpy (str,"strings ");
strcat (str,"have been ");
strcat (str,"concatenated.");
puts (str);
return 0;
}


Output:
strings have been concatenated.

Share this post


Link to post
Share on other sites
The problem must have to do with some other portion of your code. When I compiled this, it worked:

#include <stdio.h>
#include <stdlib.h>

int main()
{
char temp1[256];
char temp2[256];
strcpy(temp1, "Some Text ");
strcpy(temp2, "Some Text");
strcat(temp1,temp2);
printf("%s\n",temp1);
printf("%s\n",temp2);
return 0;
}

Share this post


Link to post
Share on other sites
I am using the MSVC++ 6.0 optimizer. I always set it to maximize speed.
I wrote my own strcat and strcpy functions, and it works now. How strange
is that?

Share this post


Link to post
Share on other sites
Quote:
Original post by raydog
I am using the MSVC++ 6.0 optimizer. I always set it to maximize speed.
I wrote my own strcat and strcpy functions, and it works now. How strange
is that?


There is nothing wrong with the snippet of code you posted, and strcpy and strcat cannot be "internally corrupted". I think the fact that you have had "bad experiences" with strncpy and strncat when those functions are safer versions of strcpy and strcat indicates something about your code.

Anyway, I agree that it is strange (though not suprising) that your bugs went away even though you didn't fix them.

Share this post


Link to post
Share on other sites
Ah, voodoo coding practices.

If I was staffing a team, I wouldn't hire you. You didn't solve the problem, electing to rewrite instead - and to rewrite a standard library function at that! - and you didn't even debug properly.

Take responsibility for your code rather than seeking to blame someone or something else at the first opportunity.

Share this post


Link to post
Share on other sites
Quote:
Original post by Oluseyi
Ah, voodoo coding practices.

If I was staffing a team, I wouldn't hire you. You didn't solve the problem, electing to rewrite instead - and to rewrite a standard library function at that! - and you didn't even debug properly.


I agree.

Quote:
Original post by Oluseyi
Take responsibility for your code rather than seeking to blame someone or something else at the first opportunity.


This is probably the best advice any software engineer can take on board. It can take years to erase the mentality of "I am right, let us look for the problem elsewhere first", but once you have, you will be light years ahead of many others in your field.

Share this post


Link to post
Share on other sites
Though Oluseyi's comments may have seemed harsh, I do believe that he has made the point that needed to be made.
The more experience you gain, the more you realise that all those times you blamed the compiler, it was you're own fault all along.

Those strxxx functions do not actually allocate any memory. They therefore cannot leak as such. A likely explanation is that your code has a buffer overrun that is writing over the value of some pointer, thus losing the address and trying to free garbage instead later.

You're problem IS caused by your own code. These so called bad experiences you've had in the past with strnxxx functions, and now strcpy functions, are almost certainly the result of other bugs you have written.
Don't underestimate the value of the knowledge gained, by spending countless hours tracking down the cause of mysterious bugs. You must understand the problem in order to not repeat it.

I highly recommend reading the book "Writing Solid Code" By Steve Maguire.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!