Strings in C: pitfalls and techniques

Question

I will be coaching an ACM Team next month (go figure), and the time has come to talk about strings in C. Besides a discussion on the standard lib, strcpy, strcmp, etc., I would like to give them some hints (something like str[0] is equivalent to *str, and things like that).

Do you know of any lists (like cheat sheets) or your own experience in the matter?

I'm already aware of the books for the ACM competition (which are good, see particularly this), but I'm after tricks of the trade.

Thank you.

Edit: Thank you very much everybody. I will accept the most voted answer, and have duly upvoted others which I think are relevant. I expect to do a summary here (like I did here, asap). I have enough material now and I'm certain this has improved the session on strings immensely. Once again, thanks.

Answer 1

It's obvious but I think it's important to know that strings are nothing more than an array of bytes, delimited by a zero byte. C strings aren't all that user-friendly as you probably know.

• Writing a zero byte somewhere in the string will truncate it.
• Going out of bounds generally ends bad.
• Never, ever use strcpy, strcmp, strcat, etc.., instead use their safe variants: strncmp, strncat, strndup,...
• Avoid strncpy. strncpy will not always zero delimit your string! If the source string doesn't fit in the destination buffer it truncates the string but it won't write a nul byte at the end of the buffer. Also, even if the source buffer is a lot smaller than the destination, strncpy will still overwrite the whole buffer with zeroes. I personally use strlcpy.
• Don't use printf(string), instead use printf("%s", string). Try thinking of the consequences if the user puts a %d in the string.
• You can't compare strings with

  if( s1 == s2 )
              doStuff(s1);

  You have to compare every character in the string. Use strcmp or better strncmp.

  if( strncmp( s1, s2, BUFFER_SIZE ) == 0 )
           doStuff(s1);

Answer 2

Abusing strlen() will dramatically worsen the performance.

for( int i = 0; i < strlen( string ); i++ ) {
    processChar( string[i] );
}

will have at least O(n²) time complexity whereas

int length = strlen( string );
for( int i = 0; i < length; i++ ) {
    processChar( string[i] );
}

will have at least O(n) time complexity. This is not so obvious for people who haven't taken time to think of it.

Answer 3

The following functions can be used to implement a non-mutating strtok:

strcspn(string, delimiters)
strspn(string, delimiters)

The first one finds the first character in the set of delimiters you pass in. The second one finds the first character not in the set of delimiters you pass in.

I prefer these to strpbrk as they return the length of the string if they can't match.

Answer 4

str[0] is equivalent to 0[str], or more generally str[i] is i[str] and i[str] is *(str + i).

NB

this is not specific to strings but it works also for C arrays

Answer 5

The strn* variants in stdlib do not necessarily null terminate the destination string.

As an example: from MSDN's documentation on strncpy:

The strncpy function copies the initial count characters of strSource to strDest and returns strDest. If count is less than or equal to the length of strSource, a null character is not appended automatically to the copied string. If count is greater than the length of strSource, the destination string is padded with null characters up to length count.

Answer 6

strtok is not thread safe, since it uses a mutable private buffer to store data between calls; you cannot interleave or annidate strtok calls also.

A more useful alternative is strtok_r, use it whenever you can.

Answer 7

confuse strlen() with sizeof() when using a string:

char *p = "hello!!";
strlen(p) != sizeof(p)

sizeof(p) yield, at compile time, the size of the pointer (4 or 8 bytes) whereas strlen(p) counts, at runtime, the lenght of the null terminated char array (7 in this example).

Answer 8

kmm has already a good list. Here are the things I had problems with when I started to code C.

1. String literals have an own memory section and are always accessible. Hence they can for example be a return value of function.

2. Memory management of strings, in particular with a high level library (not libc). Who is responsible to free the string if it is returned by function or passed to a function?

3. When should "const char *" and when "char *" be used. And what does it tell me if a function returns a "const char *".

All these questions are not too difficult to learn, but hard to figure out if you don't get taught them.

Answer 9

I have found that the char buff[0] technique has been incredibly useful. Consider:

struct foo {
   int x;
   char * payload;
};

vs

struct foo {
   int x;
   char payload[0];
};

see https://stackoverflow.com/questions/295027

See the link for implications and variations

Answer 10

I'd point out the performance pitfalls of over-reliance on the built-in string functions.

char* triple(char* source)
{
   int n=strlen(source);
   char* dest=malloc(n*3+1);
   strcpy(dest,src);
   strcat(dest,src);
   strcat(dest,src);
   return dest;
 }

Answer 11

I would discuss when and when not to use strcpy and strncpy and what can go wrong:

char *strncpy(char* destination, const char* source, size_t n);

char *strcpy(char* destination, const char* source );

I would also mention return values of the ansi C stdlib string functions. For example ask "does this if statement pass or fail?"

if (stricmp("StrInG 1", "string 1")==0)
{
    .
    .
    .
}

Answer 12

perhaps you could illustrate the value of sentinel '\0' with following example

char* a = "hello \0 world"; char b[100]; strcpy(b,a); printf(b);

I once had my fingers burnt when in my zeal I used strcpy() to copy binary data. It worked most of the time but failed mysteriously sometimes. Mystery was revealed when I realized that binary input sometimes contained a zero byte and strcpy() would terminate there.

Answer 13

You could mention indexed addressing.

An elements address is the base address + index * sizeof element

Answer 14

A common error is:

char *p;
snprintf(p, 3, "%d", 42);

it works until you use up to sizeof(p) bytes.. then funny things happens (welcome to the jungle).

Explaination

with char *p you are allocating space for holding a pointer (sizeof(void*) bytes) on the stack. The right thing here is to allocate a buffer or just to specify the size of the pointer at compile time:

char buf[12];
char *p = buf;
snprintf(p, sizeof(buf), "%d", 42); 

Answer 15

Pointers and arrays, while having the similar syntax, are not at all the same. Given:

char a[100]; char *p = a;

For the array, a, there is no pointer stored anywhere. sizeof(a) != sizeof(p), for the array it is the size of the block of memory, for the pointer it is the size of the pointer. This become important if you use something like: sizeof(a)/sizeof(a[0]). Also, you can't ++a, and you can make the pointer a 'const' pointer to 'const' chars, but the array can only be 'const' chars, in which case you'd be init it first. etc etc etc

Answer 16

If possible, use strlcpy (instead of strncpy) and strlcat.

Even better, to make life a bit safer, you can use a macro such as:

#define strlcpy_sz(dst, src) (strlcpy(dst, src, sizeof(dst)))