3

Here i want to know about strcpy() and strcat() disadvantages

i want to know about these functions danger area in embedded domain/environment.

somebody told me we never use strcpy,strcat and strlen functions in embedded domain because its end with null and sometimes we works on encrypted data and null character comes so we cant got actual result because these functions stop on null character.

So i want to know all things and other alternative of these functions. how we can use other alternatives functions

sam_k
  • 5,887
  • 13
  • 73
  • 108

7 Answers7

14

The str* functions works with strings. If you are dealing with strings, they're fine to use as long as you use them correctly - it's easy to create a buffer overflow if you use them incorrectly.

If you are dealing with binary data, which it sounds like you are, string handling functions are unsuitable (They're meant for strings after all, not binary data). Use mem* functions for dealing with binary data.

In C , a string is a sequence of chars that end with a nul byte. If you're dealing with binary data, there might very well be a char with the value 0 in that data, which string handling functions assume to be the end of the string, or the data does not contain any nul bytes and is not nul terminated, which will cause the string functions to run past the end of your buffer.

nos
  • 215,098
  • 54
  • 400
  • 488
  • If we are not working with binary data than strlen() is fine ? but if we are going for other alternative or made one other function to findout string length than this function also use same logic as per strlen(). so its functions also stops at NULL character. – user1089679 Feb 07 '12 at 07:40
3

Well, these functions indeed copy null-terminated strings and not only in embedded domain. Depending on your need you may want to use mem* functions instead.

Michael Krelin - hacker
  • 131,515
  • 23
  • 189
  • 171
2

As others have already answered, they work fine for strings. Encrypted data can't be regarded as strings.

There is however the aspect of using any C library function in embedded systems, particularly in high-integrity real-time embedded systems, such as automotive/medical/avionics etc. On such projects, a coding standard will be used, such as MISRA-C.

The vast majority of C libraries are likely not compatible with your coding standard. And even if you have the option (at least in MISRA-C) to make deviations, you would still have to verify the whole library. For example you will have to verify the whole string.h, just because you used strlen(). Common practice in such systems is to write all functions yourself, particularly simple ones like strlen() which you can write yourself in a minute.

But most embedded systems don't have such high requirements for quality and safety, and then the library functions are to prefer. Particularly memcpy() and similar search/sort/move functions, that will likely be heavily optimized by the compiler.

Lundin
  • 174,148
  • 38
  • 234
  • 367
1

If you are worried about overwriting buffers (which everybody really should be), use strncpy or strncat instead. I see no problem with strlen.

Some programmer dude
  • 380,411
  • 33
  • 383
  • 585
1

This issue is specific to the system you describe, not to embedded systems per-se. Either way the string functions are simply not suited to the application you describe. I think you should simply have been told that you can't use string functions on the encrypted data in your particular application. That is not an issue with embedded systems, or even the string library. It is entirely about the nature you your encrypted strings - they are no longer C strings once encrypted, so any string library operation would no longer be valid - it becomes just data, and it would be your responsibility to retain any necessary meta-data regarding length etc. You could use Pascal style strings to do that for example (with a suitable accompanying library).

Now in general the C string library, and C-strings themselves present a number of issues for all systems, not just embedded. See this article by Joel Spolsky to see why caution should be used when using C strings functions, especially strcat().

Clifford
  • 82,791
  • 12
  • 81
  • 153
0

The reason is just what you said:

because its end with null and sometimes we works on encrypted data and null character comes so we cant got actual result because these functions stop on null character.

And for alternatives, I recommend strn* series like strncpy, strnlen. n here means the maximum possible length of string.

You may want to find a C-standard library reference and seek for some details about those strn* functions.

starrify
  • 13,651
  • 4
  • 33
  • 48
0

As others have said str* functions are for strings, not binary data.

However, I suggest that when you do come to use strings, you should consider functions such as strlcpy() instead of strcpy(), and strlcat() instead of strcat().

They're not standard functions, but you'll be able to find copies of them readily enough (or really just write your own). They take the size of the destination buffer as an extra parameter to their standard cousins and are designed to avoid buffer overflows.

It probably seems like an imposition to have to pass around the size of a pointer's block wherever you use it, but I'm afraid that's what programming in C is about.

At least until we get smarter pointers that is.

Craig Mc
  • 169
  • 1
  • 2