What should a C programmer know? [closed]

Question

What are some concepts/techniques/language features that every decent C programmer should know/be aware of (exclude general software engineering and similar and focus only on C specific stuff). I would like to know so that I would be able to fill in some possible gaps in my C knowledge.

Answer 1

Specific to C? Aside from standard constructs common to most procedural languages, I'd have to say:

• (ab)using the preprocessor
• linker vs compiler
• Pointers Pointers Pointers!
• How arrays are pointers are arrays
• How C strings work, and how they are also pointers and arrays
• How bad C string use can result in buffer overflows
• How to cast anything to anything (its all just 1s and 0s after all :) )
• Manual memory management malloc/free
• Stack vs Heap
• Pointer aliasing, (why its illegal in C99)
• Thinking about development in terms of modules (.h/.c files) with a set of publicly exposed functions instead of strictly classes
• Unions
• Why sprintf can blow your foot off
• Function pointers

Answer 2

Understand pointers and you will understand computers.

Answer 3

In addition to pythagras's excellent answer,

how to write (or at least read) complicated declarations, such as char (*(*funcs[4])())[10]

funcs is an array[4] of pointers to a function returning pointer to array[10] of char

Answer 4

A C programmer should know... other languages! ;-) It is always fruitful to know concepts from others languages of various paradigms, like OOP, functional programming, and so one.

More seriously, a look at the obfuscated programming contest is fun and, curiously, a good experience too.

Answer 5

1. Integer promotion rules
2. Initialize everything to a known value
3. GOTO is not evil especially when used to handle exceptions/failures
4. malloc and/or calloc can return NULL...make sure your check return values
5. Frequent small memory allocations can cause fragmentation on the heap.
6. Pointer arithmetic
7. Bit masks are your friend
8. x >> 1 is equivalent to x/2 for unsigned integers

Answer 6

I mentioned "buffer overflows" in a comment to Pythagras's answer, I should probably clarify what I meant a bit. In C, it's not enough to know that working directly with memory is dangerous - you should also understand the precise ways in which it's dangerous. I don't really like the "shooting yourself in the foot" metaphor for all of these cases - a lot of the time, it's not you pulling the trigger, but often it's an actor with interests contrary to yours and/or your users'.

For example, in an architecture with a descending stack (most popular architectures fit this bill - x86 and ARM generally included), when you call a function, the return address for the function will be placed on the stack after the local variables defined in the body of the function. So if you declare a buffer as a local variable, and expose that variable to the outside world without checking for buffer overflow, like this:

void myFn(void) {
    char buf[256];
    gets(buf);
}

an external user can send you a string that overwrites the return address from the stack - basically, he can change your program's run-time idea of the call-graph that lead to the current function. So the user gives you a string that's the binary representation of some executable code for your architecture, enough padding to overflow the stack from myFn, and some additional data to overwrite the return address for myFn to point to the code he gave you. If this happens, then when myFn would ordinarily have returned control to its caller, it will instead branch to code that the malicious user provided. If you write C (or C++) code that has the potential to be exposed to untrusted users, you need to understand this attack vector. You should understand why a buffer overflow against the stack is often (but not always) more easily exploitable than one against the heap, and you should understand how the memory in the heap is laid out (not in too much detail, necessarily, but the idea that a malloc()'ed region has control structures surrounding it can help understanding why your program crashes in another malloc(), or in free()).

C exposes you to low-level details about how your machine works, and it gives you more direct control over your machine than any other user-edited language in widespread use today. With great power comes great responsibility - you actually need to understand those low-level details in order to work with C safely and effectively.

Answer 7

In addition to the other good answers I would like to add defensive programming techniques to the list.

E.g. using asserts at start/end of functions to verify contract.