Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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.

share|improve this question

closed as not constructive by gnat, Giorgio, thorsten müller, GlenH7, Jalayn Apr 20 '13 at 13:45

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.If this question can be reworded to fit the rules in the help center, please edit the question.

9  
Start with Stack Overflow's C questions and see if there's anything you don't know. –  chrisaycock Feb 15 '11 at 20:43
3  
A C programmer should probably know that 2 + 2 = 4 –  Crazy Eddie Feb 15 '11 at 20:48
19  
They should know of a store that sells bullet-proof shoes. –  Adam Crossland Feb 15 '11 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 '11 at 21:39
2  
Another programming language? –  Muhammad Alkarouri Feb 15 '11 at 23:31

7 Answers 7

up vote 18 down vote accepted

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

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.

share|improve this answer

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.

share|improve this answer
  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
share|improve this answer
    
+1 for GOTO not being evil :) –  zvrba Feb 16 '11 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.

share|improve this answer

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

share|improve this answer
1  
If it gets so complex, perhaps this belongs in a comment? –  Job Feb 15 '11 at 21:27
6  
maybe he should learn how to avoid writing like that? –  FabianB Feb 15 '11 at 22:56

Understand pointers and you will understand computers.

share|improve this answer
9  
Nah, you will simply get an illusion that you understand computers. –  Job Feb 15 '11 at 21:24

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