Question

Is strncpy() secure for iPhone development?

If not, what is a better String API to use that is recommended to be secure?

Answer 1

If you know the limitations of strncpy(), then it is OK. I avoid it because I don’t like its limitations, which are two-fold:

• It does not guarantee null termination
• It always writes to every byte of the target buffer

This means that if you write:

char little[10];
char large[20480];

strncpy(little, sizeof(little), "abcdefghijklmnopqrstuvwxyz");
strncpy(large,  sizeof(large),  "abcdefghijklmnopqrstuvwxyz");

Then little is not a null-terminated string, though no buffer overflow has occurred, and large had 20454 nulls copied to its tail end. Both are troublesome.

• Consider whether strlcpy() and strlcat() are available on iOS; they are on Mac OS X.

If you’re coding in C++, you shouldn’t be using C strings at all, or only in the most limited circumstances where a system service requires the use, and then you should have a cover function (inline) that takes a C++ string and passes the somestring.c_str() value to the system service.

If you’re coding in Objective-C, you’ll use the NS* strings.

So, only consider strncpy() if you are coding in C. Treat it with caution even so.

I have a thesis (and I don’t lay any claim to novelty in it — I collected the idea from others):

• You can only use functions like strcpy(), strncpy(), strcat() and strncat() safely if you know the lengths of the strings, both the target buffers and the source strings (and you know the foibles of the function you’re calling — quickly, what does the length passed to strncat() represent?⁽¹⁾).
• If you know how long everything is, you don’t need to use functions like strcpy(); you can use memmove() (or memcpy()).
• So the string copy and move functions should be irrelevant; you don’t need them in safe code because you know how long everything is and can therefore use the memory routines instead.

---

⁽¹⁾ The length is the space available in the target buffer after the current string is accounted for. So, to be able to use strncat(), you must know how long the string is in the target string, and the total length available, so that you can have strncat() skip over the initial segment of the string and then concatenate some or all of the second string. But, if you know that, you could have used:

strncpy(target + curr_target_strlen, source, target_size - curr_target_strlen);

which would be ‘more efficient’ because it doesn’t involve skipping over the leading part of the string (which, incidentally, can lead to quadratic behaviour if you’re building a long string with lots of strncat() or strcat() operations). Or, given that you know all the sizes, you could use memmove():

size_t copy_length = target_size - curr_target_strlen;
if (copy_length > source_strlen)
    copy_length = source_strlen + 1;
memmove(target + curr_target_strlen, source, copy_length);

And, unless I’ve got an off-by-one error in code written on the spur of the moment, that avoids most of the problems with strncat(). If you always use strncat() with the first argument pointing to the null at the end of a string, it has its uses (and may be optimized in assembler. Otherwise, it is not a good choice — IMNSHO.