{"id":3195,"date":"2018-08-04T00:01:18","date_gmt":"2018-08-04T07:01:18","guid":{"rendered":"https:\/\/c-for-dummies.com\/blog\/?p=3195"},"modified":"2018-07-28T10:13:47","modified_gmt":"2018-07-28T17:13:47","slug":"ten-c-programming-mistakes","status":"publish","type":"post","link":"https:\/\/c-for-dummies.com\/blog\/?p=3195","title":{"rendered":"Ten C Programming Mistakes"},"content":{"rendered":"

I’m certain that more than 10 C programming mistakes are common, but for some reason people enjoy lists with 10 items. My list of Ten C Programming Mistakes isn’t a top-ten list, so nothing is ranked. These are just a collection (cut off at 10) of the problems and issues I find most frequently when coding in the C language.
\n
\nMatching Braces and Parentheses<\/strong><\/p>\n

This mistake isn’t a problem, providing that you use a source code editor that highlights braces, parentheses, and square brackets. Even then, you may ignore this issue, wonder why the one brace is highlighted, and attempt to compile.<\/p>\n

If you format your code consistently, finding a missing brace is easy. Ditto for finding a missing parentheses, which is why I try to add spaces around functions as arguments and other complex statements.<\/p>\n

Forgetting Semicolons<\/strong><\/p>\n

This issue has cropped up for me recently, and probably for other coders as well, especially when I switch between C and other languages that don’t bother with statement terminating characters. In C. all statements end with a semicolon. Newer languages, such as Python and Swift, don’t require a terminating character. So when you return to C, you may find yourself coding without adding the semicolon. Fortunately, a smart text editor goes bonkers when you forget the semicolon. The compiler is also good about flagging this oversight.<\/p>\n

Misplacing a Semicolon<\/strong><\/p>\n

Just as you might forget a semicolon at the end of a statement, you may accidentally add a semicolon after an if<\/em> or while<\/em> condition, as in:<\/p>\n

if( a == b );<\/code><\/p>\n

Or:<\/p>\n

while( x < 66 );<\/code><\/p>\n

Such a thing is permissible and often necessary. The clang<\/em> compiler flags such statements as a warning, but the preferred format is:<\/p>\n

while( x < 66 )\r\n    ;<\/code><\/pre>\n
When not flagged, such stray semicolons can lead to hours to bug-hunting.<\/p>\n
Using = instead of ==<\/strong><\/p>\n
This booboo happens in most programming languages: The =<\/code> is the assignment operator. The ==<\/code> is a comparison operator, which is why I pronounce it \"is equal to\" as opposed to \"equals.\" Even then, I still mess up and use =<\/code> for a comparison. Fortunately, the clang<\/em> compiler is good about flagging this mistake.<\/p>\n
Signed Integers in Loops<\/strong><\/p>\n
A signed integer flips from positive to negative, wrapping around and eventually incrementing back to zero. If you use a signed integer in a loop, and you're expecting an unsigned value to terminate the loop, you've just created an endless loop.<\/p>\n
For example, say you're using a char<\/em> variable to loop from 0 to 200:<\/p>\n
\r\n#include <stdio.h>\r\n\r\nint main()\r\n{\r\n    char x;\r\n\r\n    for(x=0;x<200;x++)\r\n        printf(\"%d \",x);\r\n    putchar('\\n');\r\n\r\n    return(0);\r\n}<\/pre>\n
The for<\/em> loop in this code is eternal. In fact, the clang<\/em> compiler generates a warning because signed char<\/em> variable x<\/code> can only hold the value 127 before it \"increments\" to -128.<\/p>\n
Forgetting a Loop's Exit Condition<\/strong><\/p>\n
Specifically with a while<\/em> loop, some statement within the loop must alter the exit condition. If you forget to, say, modify variable x<\/code> for while(x<66)<\/code>, the loop never ends. Rare is the loop that doesn't require an exit condition.<\/p>\n
Not Terminating a String<\/strong><\/p>\n
A string must terminate with the null character, \\0<\/code>. All C string library functions maintain the null character terminator. Strings you declare in your code obey this rule. It's only when you mess with a string on your own that you can forget about the null character terminator. When you do, chaos ensues.<\/p>\n
Forgetting to Initialize a Pointer<\/strong><\/p>\n
Not only pointers, but every variable type in C must be initialized before it's used. In C, variables are declared and allocated in two steps. It would nice if every variable declared were initially allocated to zero or NULL<\/code>, but that's just not the case. It's up to you, Mr. C Coder, to initialize a variable, especially pointers.<\/p>\n
Manipulating Pointers in Functions<\/strong><\/p>\n
Unlike other arguments passed to a function, a pointer's value cannot be manipulated within the function itself. This concept is weird, but understanding how it works helps you to avoid trouble: A pointer is memory address and you can access and use that address within a function, but you cannot change the address. To change the address, you must pass a pointer-pointer, or the address of the pointer, instead of its value directly. This solution is correct, but it adds a higher level of complexity to the code.<\/p>\n
Writing Pointers to a File<\/strong><\/p>\n
When storage is allocated and assigned to a pointer, and that storage is written to a file, you must remember to write the storage itself and not the pointer variable. The pointer is a (typically) 4-byte address. Too many coders send that 4-byte address to a file and wonder why the file doesn't contain the contents desired. Write the pointer's contents, the stuff stored in memory, and not the pointer variable.<\/p>\n","protected":false},"excerpt":{"rendered":"
You can program for years, yet you still find yourself making at least one of these mistakes at some point in your code. 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-3195","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\/3195","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=3195"}],"version-history":[{"count":7,"href":"https:\/\/c-for-dummies.com\/blog\/index.php?rest_route=\/wp\/v2\/posts\/3195\/revisions"}],"predecessor-version":[{"id":3228,"href":"https:\/\/c-for-dummies.com\/blog\/index.php?rest_route=\/wp\/v2\/posts\/3195\/revisions\/3228"}],"wp:attachment":[{"href":"https:\/\/c-for-dummies.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=3195"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/c-for-dummies.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=3195"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/c-for-dummies.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=3195"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}