[dllthomas]

"I've mostly used a subset of C features to solve many problems."

Sure. What about code written by others? What about when you're debugging and something just isn't working the way you expect because you've unknowingly stepped outside that subset? (Most of the important concepts here aren't syntactic constructions you can avoid trivially by typing Y instead of X, and may or may not be detectable statically). Also, maybe you're missing opportunities to better insure your code is correct at compile time - I'm not sure whether it falls within your subset, but for instance I recently put together a macro that asserts statically that two expressions have the same type (and without any runtime cost).

"I've also seen some C 'experts' fail to come to a proper solution even if they know all the features."

Obviously. Knowledge of the spec and your compiler aren't the only thing that matter, by a long shot. I'm just saying they most emphatically are helpful.

[chr13]

I guess you summed it up. Indeed having more depth in a language is very important and useful, I was just trying to make a point that these aren't the only things. Here is how I perceive a language,

It is made up of syntax and behaves in a certain way. If you read the documented features you'll know all of it. There may be some undocumented things which may not be of utmost importance. However, this is just the base of programming. And when you start dealing with 5-6 languages you can forget things if you don't have a good memory but the good thing is it's all documented and known features. Whereas while programming, one can often be involved in solving unknown problems, which can't be figured out just by googling.