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.

  • 9
    Start with Stack Overflow's C questions and see if there's anything you don't know. Feb 15, 2011 at 20:43
  • 3
    A C programmer should probably know that 2 + 2 = 4 Feb 15, 2011 at 20:48
  • 21
    They should know of a store that sells bullet-proof shoes. Feb 15, 2011 at 20:50
  • 1
    There are hundreds of books written on this subject. Your question is really fairly vague. You're going to have to be more specific to get decent answers which aren't just a list of stuff. And seeing the answers gengerated so far from this question I would think it needs to be reworked or closed.
    – Walter
    Feb 15, 2011 at 21:39
  • 2
    Another programming language? Feb 15, 2011 at 23:31

7 Answers 7


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
  • I'd add "buffer overflows" to the list. Feb 15, 2011 at 22:20
  • @Aidan, good catch. Added.
    – Doug T.
    Feb 15, 2011 at 22:59
  • 2
    How C arrays and pointers are not the same : books.google.ca/…
    – Matthieu
    Feb 16, 2011 at 13:36
  • pointers should have been repeated at least 3 times more
    – Gaurav
    Feb 16, 2011 at 13:59

Understand pointers and you will understand computers.

  • 12
    Nah, you will simply get an illusion that you understand computers.
    – Job
    Feb 15, 2011 at 21:24

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

  • 1
    If it gets so complex, perhaps this belongs in a comment?
    – Job
    Feb 15, 2011 at 21:27
  • 7
    maybe he should learn how to avoid writing like that?
    – FabianB
    Feb 15, 2011 at 22:56
  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
  • +1 for GOTO not being evil :)
    – zvrba
    Feb 16, 2011 at 8:21

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.


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];

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.


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.

Not the answer you're looking for? Browse other questions tagged or ask your own question.