Weird string problem

**kidburla** · 08-04-2006

Hi,

I have been programming in C for about 6 months now and thought I had got pretty used to it but I came across a weird problem which I don't really understand. I wrote a small program to illustrate my problem (really just a cutdown version of a larger application I am writing).

I am using Windows XP Professional with Dev-C++ and GCC.

Here are two almost identical programs:

Code:

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

int main()
{
 char People[][9] = {
  "adam",
  "bridget",
  "celia",
  "claire",
  "eric",
  "faye",
  "fiona",
  "holly",
  "isobel",
  "katie",
  "matthew",
 };
 int ps, pe;
 char fs[7] = "hello ";
 char fe[7] = "hello ";

 srand((unsigned) time(NULL));
 ps = rand() % 11;
 pe = rand() % 11;

 strcat(fs, People[ps]);
 strcat(fs, " is here");
 printf("%s", fs); getchar();

 strcat(fe, People[pe]);
 strcat(fe, " is here");
 printf("%s", fe); getchar();

 return 0;
}

Code:

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

int main()
{
 char People[][9] = {
  "adam",
  "bridget",
  "celia",
  "claire",
  "eric",
  "faye",
  "fiona",
  "holly",
  "isobel",
  "katie",
  "matthew",
 };
 int ps, pe;
 char fs[8] = "\\hello ";
 char fe[8] = "\\hello ";

 srand((unsigned) time(NULL));
 ps = rand() % 11;
 pe = rand() % 11;

 strcat(fs, People[ps]);
 strcat(fs, " is here");
 printf("%s", fs); getchar();

 strcat(fe, People[pe]);
 strcat(fe, " is here");
 printf("%s", fe); getchar();

 return 0;
}

They are written in C for a console application.

Now the only difference is that there is an escaped backslash in the strings in the second version (I have also updated the lengths of the strings in the initialisers). The first version compiles and runs fine, displaying two strings such as "hello matthew is here" and "hello adam is here". However the second version displays one of the strings e.g. "\hello eric is here", then it crashes.

I do not understand this error at all.

Please help!

**itsme86** · 08-04-2006

Code:

char fs[8] = "\\hello ";
...
 strcat(fs, People[ps]);
 strcat(fs, " is here");

You're only allocating 8 bytes for your fs array, which is just fine for holding the string you're initializing it to. But then you're using strcat() to append another string to the end of fs. This appended string is going outside the bounds of the array and is mangling memory. Try making fs able to hold at least 30 chars and see what happens.

The problem actually exists in both programs you posted. You're just getting lucky (some might say unlucky, because a bug that doesn't readily present itself is harder to find) in the first one that the memory mangling isn't so bad that it crashes the program.

At any rate, your fs and fe arrays need to be big enough to hold the "hello" string plus the longest string in your People array plus the "is here" string plus the string terminator character.

**kidburla** · 08-04-2006

Thanks, that's very helpful.

Presumably it would be possible to write a "safe" strcat, which creates a new pointer, mallocs it to the correct size (sum of the strlens, plus one) then strcpys the old string in there, runs the existing strcat function and frees the old pointer.

But I guess the existing strcat doesn't have this functionality because it would be very time-consuming (but more memory-efficient, because you wouldn't have to declare arrays to be larger than they need to be).

**Prelude** · 08-04-2006

>Presumably it would be possible to write a "safe" strcat, which creates a new pointer,
>mallocs it to the correct size (sum of the strlens, plus one) then strcpys the old string in
>there, runs the existing strcat function and frees the old pointer.
That doesn't sound very safe. What if the old pointer is an array? Freeing memory that was never malloc'd is not a good idea at all. It also puts the onus of freeing the memory in the new string to the caller, which has been proven repeatedly to be a mistake since callers tend to forget such things. That idea, while logically sound, has too many restrictions, it seems.

A "safe" strcat would be something more like this:

Code:

char *safe_strcat ( char *dst, const char *src, size_t n )
{
  size_t len = strlen ( dst );

  while ( *src != '\0' && len < n - 1 )
    dst[len++] = *src++;

  dst[len] = '\0';

  return dst;
}

**jafet** · 08-05-2006

safe_strcat() is known by many names. In string.h you will find it called strncat.

**itsme86** · 08-06-2006

Except strncat() will only copy the string terminator into the destination string if it's within the first n chars of src. That's always a big gotcha that gets strncat() beginners.

**fgw_three** · 08-07-2006

Originally Posted by itsme86

Except strncat() will only copy the string terminator into the destination string if it's within the first n chars of src. That's always a big gotcha that gets strncat() beginners.

I believe the variants of BSD Unix have a "safe" strcat called strlcat (and there is a companion strlcpy) both of which are guaranteed to truncate AND null terminate instead of overflowing.

You can probably find source code around on the web.....

I know it doesn't come by default in the Red Hat variants of Linux.

**quzah** · 08-07-2006

Which isn't realy safe, if you don't want your data truncated. Though to be fair, you did put safe in quotes.

Quzah.

**fgw_three** · 08-08-2006

To paraphrase Forrest Gump, "safe is as safe does"

Seriously, I agree with you. If you're in a situation where your data might be truncated anyway, then it is safer to have it null terminated I'd guess. And if you do examine the return value, you can tell that it has been truncated.

But, it's not for every situation....

**Micko** · 08-08-2006

Originally Posted by fgw_three

To paraphrase Forrest Gump, "safe is as safe does"

What Forrest Gump used to say?
"Dumb is..."
This is off topic, but I need to know....
Cheers

**itsme86** · 08-08-2006

Stupid is as stupid does.

**quzah** · 08-08-2006

"Life is like a truncated-not-terminated 'string'..."

Quzah.

**Kennedy** · 08-08-2006

If you really get desperate, you could use the Windows StringCchCopy which supposedly doesn't allow you to copy past the end of the allocated memory location, but I agree with the others about writing your own and malloc'ing the space.

Andy

**Viorel** · 08-09-2006

Maybe at first stage you simply should allocate enough space for destination strings?

Code:

char fs[64] = "\\hello ";
char fe[64] = "\\hello ";

I hope it helps.

Thread: Weird string problem

Thread Tools

Search Thread

Display

Weird string problem

Maybe try strlcat...

OT: Forrest Gump

Similar Threads

C++ string problem

We Got _DEBUG Errors

Sorting problem.. well actually more of a string problem

Program using classes - keeps crashing

Classes inheretance problem...