C's problem is not a "feature" per se. To understand what is wrong with C, you have to ask why it takes six lines or more to do simple things like retrieve a single line from the console and convert it to an integer:
char buffer;By comparison, in Perl it'd be:
fgets(buffer, sizeof(buffer), stdin);
if (*buffer==0 || *buffer=='\n')
num = atoi(buffer);
num = int(<>);C suffers from stagnancy. If one wants to create a directory, he/she or he\she has to worry about conflicting standards. Functions for creating and traversing through directories are not standardized across the major platforms. Unix doesn't even have a function call for copying a file (if you do it the manual way with fread/fwrite, that still doesn't compensate for sparse files). Even the language itself has similar issues. Can I use typeof or not? Is long 32 or 64 bits? Is long long even available? I need not discuss creating a window or displaying an Open dialog.
How do programmers deal with this? Most flock to Java, Python, and other low-performance languages. Others rely on toolkits such as Qt to abstract those details while sacrificing the portability of C. Few put up with it by learning the details, and even when they do, they end up with messy (and likely still incorrect) code.
Nevertheless, C has crucial benefits. It is the lingua franca of compiled programming languages. If you write a library in C, it can easily be adapted for use in C++, D, eC, etc.. Most importantly, C and its compile-to-machine-code brethren are fast. If you want an operating system package manager to be quick, you write it in C, not Python.
The reason it is so hard to program in C is because C has an inadequate, obsolete standard library. I believe CCAN, by providing a standard repository for C libraries (analogous to CPAN for Perl and Boost for C++), will soundly overcome this obstacle.