The "if (a = b)" syntax is among the first things newcomers to C are warned about. It's not a big problem.
Null terminated strings are a bigger problem. What do you do if you want to embed nulls in a string? Not use the entire string.h library for starters, have to write your own routines. It really is better to store the length in a simple integer, as long as it's not stupidly small like in Turbo Pascal where they set aside one measly byte, thus making the maximum length a paltry 255 characters. There are simply too many use cases where length information is needed. Having the length makes a strlen function trivial and run in constant time, instead of a time dependent upon the data. We now have the String class in the Standard Template Library which addresses these problems.
Bigger yet are the limitations of the function call syntax. This is not just C, but most programming languages that originated in those times. Most functions have a fixed number of parameters. If it's known how many parameters there are, it is not necessary to enclose the list. Basic math is done without that, eg. c = a +b instead of something gross like equal(&c,add(a,b)), Why can't functions be done the same way? Because they decided to allow variable numbers of parameters, with the printf function being the most prominent example of such a function. This was done in a very awkward manner. Consequently, most programmers avoid it. But we still have to include the parentheses even for functions with a fixed number of parameters. C enshrined parentheses as basically a sigil to distinguish function names from variable names. What does C gain from this? The ability to curry? No. Recursive functions? No, don't need variable length parameter lists for that, it does recursion anyway. The good in C's function syntax is that the programmer doesn't have to use a key word like "call" to call a function, and C has no unnecessary distinction between a function and a "procedure" as in Pascal. Can sort of do some functional style programming by passing pointers to functions. But they didn't get functions good enough. Operator overloading is an ugly hack that tries to address these inherent deficiencies. It doesn't succeed, can't go far enough. Same with polymorphism and name mangling. And C++'s addition of prefacing a parameter with an ampersand is nice, but merely a syntactic shortcut. The latest C/C++ standards also nibble at this problem with things like the introduction of "auto". But it still has the fundamental problem of excessive parentheses, like in LISP. C is all about brevity and economy, in both syntax and compiled code, but in this, they didn't do as well as they could have.
Then there's parallel programming. C wasn't designed for it, and can't do it clearly and cleanly. To be fair, there isn't a general purpose language that really nails parallel programming. Does it make sense to have to clear an array by using a loop, as in "for (i=0; i<MAX; i++) a[i] =0;"? Not if you're trying to use the massive parallelism of current commodity graphics cards. To this day, parallel programming remains a sort of black art, to be attempted only by the most skilled and intrepid programmers. Similar to the reputation that assembler still has in some programming circles, or that network programming used to have (sockets, ooh, scary!) Just include the magic library and call the magic functions, let them handle the complexities.
And that brings me to the next point, the libraries. The language designers didn't put enough consideration into libraries, or they would have realized how huge the entire set of libraries could get and made some provisions for that. Instead, years later namespaces were added. The next problem with the libraries is related to the problems with function calls. The library interface is too language specific. Those header files are a mess that makes it much harder for another language to use the related functions. A common solution is to resort to "wrappers", like much of CPAN for the Perl language. SWIG is another approach. There are also things like f2c and p2c. What's very badly needed is some kind of standard library interface. Not easy to do, not with the variety of programming paradigms out there, but maybe now we know enough to do it.