Actually, "what bothers [...] the most about C" for me is not pointers or leaks. It is people who blame the language for their inability to keep track of the memory they allocate and use.
"Accessing the null pointer is very dangerous, as it might crash your program. Always make sure that you are not accessing null pointers."<p>If you're going to read or write through an invalid pointer, the NULL pointer is your friend, and an immediate segfault is the best thing that could happen. The worse thing that could happen is that the program keeps chugging along and you never notice the bug.<p>"Always use memset along with malloc, or always use calloc"<p>That's a good way to defeat checkers like Valgrind. I'm not saying it's a bad idea, but not something a programmer should be instinctively doing without thinking about it. In fact, excepting stylistic stuff, "always" is a poor way to approach programming. You should do nothing which isn't deliberate and well thought out.
I wonder why the link made it to the front page. Everything in there is absolutely basic knowledge which every programmer who specifically chooses C over other languages for a task knows anyway. If you choose C you know that you have to be careful about dynamic memory. Somewhat obvious, no?
Sadly it doesn't address the debugging problem at all. Mentioning very useful tools like valgrind and address sanitizer (asan), which can help to save lots of debugging time.
<p><pre><code> char *name = (char *) malloc(11);
// Assign some value to name
memcpy ( p,name,11); // Problem begins here
</code></pre>
"In this example, the memcpy operation is trying to write 11 bytes to p, whereas it has been allocated only 10 bytes."<p>I'm sorry, but I see it as having malloc'd 11 bytes...