{"id":2816,"date":"2017-11-25T00:01:41","date_gmt":"2017-11-25T08:01:41","guid":{"rendered":"http:\/\/c-for-dummies.com\/blog\/?p=2816"},"modified":"2017-12-02T08:48:10","modified_gmt":"2017-12-02T16:48:10","slug":"safe-coding-practices-string-handling-i","status":"publish","type":"post","link":"https:\/\/c-for-dummies.com\/blog\/?p=2816","title":{"rendered":"Safe Coding Practices – String Handling I"},"content":{"rendered":"

C offers a smattering of string-manipulation functions, but it leaves many of the critical issues up to you. Specifically, you must ensure that a string doesn’t overflow its buffer and that all strings are capped with the null character, '\\0'<\/code>.
\n
\nI’m guilty of violating both these rules and I’m not alone. Unsafe code often runs just fine under some circumstances. The compiler doesn’t check for buffer overflows and sometimes you’re lucky that a null character is lurking in memory right where a string ends. Fortune’s winds don’t always blow in a favorable direction, which is why you must avoid these two unsafe conditions.<\/p>\n

In C, the programmer must perform the error-checking for strings, a process that’s automatic in other programming languages.<\/p><\/blockquote>\n

The two functions at issue here are strcpy()<\/em> to copy a string and strcat()<\/em> to stick one string on the end of another. Both functions require that the strings manipulated terminate with the null character, '\\0'<\/code>. Both functions assume in a deadly manner that the buffers manipulated can hold all the characters copied.<\/p>\n

Consider the following code that uses the strcpy()<\/em> function to copy a string from one buffer to another:<\/p>\n

\r\n#include <stdio.h>\r\n#include <string.h>\r\n\r\nint main()\r\n{\r\n    char buf1[] = \"Goodbye!\";\r\n    char buf2[3];\r\n\r\n    strcpy(buf2,buf1);\r\n\r\n    printf(\"'%s' and '%s'\\n\",\r\n            buf1,\r\n            buf2\r\n          );\r\n\r\n    return(0);\r\n}<\/pre>\n
Array buf1[]<\/code> holds nine characters, eight for the string Goodbye!<\/code> and one for the null character at the end (which you don’t see). The buf2[]<\/code> array, however, has room for only 3 characters. The strcpy()<\/em> function won’t error because of the overflow.<\/p>\n
When I run this code, I see this output:<\/p>\n
'dbye!' and 'Goodbye!'<\/code><\/p>\n
I’m not sure what’s going on, but I saw this output on both the PC and my Linux systems. The string dbye!<\/code> is 3 characters too long for the buffer. On my Mac, however, I get the message Abort trap: 6<\/code>. Obviously the Mac is more aggressive with its overflow checking.<\/p>\n
It’s up to you to ensure that a buffer doesn’t overflow. Only when the size of buf2[]<\/code> is changed to fully accommodate the string in buf1[]<\/code> does the code run safely. Yet, imagine a large program where you innocently change the size of one buffer and forget to change the size of another: You’ve just written risky code.<\/p>\n
In the preceding example, the string size is know; it won’t change at runtime. So, you could manually set both buffers to the same size or something large enough to accommodate the known text. When the string size is unknown, you must properly size the buffer at runtime. In the following code, the second buffer is a pointer. Its size is set when the code runs:<\/p>\n
\r\n#include <stdio.h>\r\n#include <stdlib.h>\r\n#include <string.h>\r\n\r\nint main()\r\n{\r\n    char buf1[] = \"Goodbye!\";\r\n    char *buf2;\r\n\r\n    \/* allocate storage *\/<\/span>\r\n    buf2 = (char *)malloc( strlen(buf1) + 1 );\r\n    if( buf2 == NULL)\r\n    {\r\n        fprintf(stderr,\"Unable to allocate buffer\\n\");\r\n        exit(1);\r\n    }\r\n\r\n    strcpy(buf2,buf1);\r\n\r\n    printf(\"'%s' and '%s'\\n\",\r\n            buf1,\r\n            buf2\r\n          );\r\n\r\n    return(0);\r\n}<\/pre>\n
At Line 11, the statement (char *)malloc( strlen(buf1) + 1 )<\/code> allocates the proper amount of storage for the string in buf1<\/code> and assigns that memory location to the buf2<\/code> pointer. The +1<\/code> is necessary because the strlen()<\/em> function counts only characters in the string, not the null character at the end.<\/p>\n
This same type of solution must be used when concatenating strings. I cover that problem and its solution in next week’s Lesson<\/a>.<\/p>\n","protected":false},"excerpt":{"rendered":"
When copying strings, be mindful of buffer overflows. Continue reading →<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[2],"tags":[],"class_list":["post-2816","post","type-post","status-publish","format-standard","hentry","category-main"],"_links":{"self":[{"href":"https:\/\/c-for-dummies.com\/blog\/index.php?rest_route=\/wp\/v2\/posts\/2816","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/c-for-dummies.com\/blog\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/c-for-dummies.com\/blog\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/c-for-dummies.com\/blog\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/c-for-dummies.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=2816"}],"version-history":[{"count":9,"href":"https:\/\/c-for-dummies.com\/blog\/index.php?rest_route=\/wp\/v2\/posts\/2816\/revisions"}],"predecessor-version":[{"id":2858,"href":"https:\/\/c-for-dummies.com\/blog\/index.php?rest_route=\/wp\/v2\/posts\/2816\/revisions\/2858"}],"wp:attachment":[{"href":"https:\/\/c-for-dummies.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=2816"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/c-for-dummies.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=2816"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/c-for-dummies.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=2816"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}