The array iteration code is also solid. Seems like a pretty good programmer, judging from the code you cite here at least.
While I personally like to put a few assertions just to find my typos quicker, adding additional fluff here is mostly detrimental. The kind of bugs that can happen with this sort of "dangerous" code are the ones that you basically just typos that you catch on the first run. I.e. it's not like there are any rarely occurring edge cases that are unhandled, since the code is extremely straightforward. The "complexity" is very low.
Shouldn't there be a NULL at the end of the array and do a null check in the iteration?
Then again this is just some example code on a website, so it's natural that it has to be done a little more straightforwardly than you would write it in actual practice.
There are phases programmers go through. One phase occurs about after 10 years of professional programming. I call this the "no mercy" phase, where these newly-minted senior programmers think defensive programming is for noobs, and scrunch their C code down to the fewest number of lines and characters. And when someone objects, the reply is, paraphrased (as seen in the replies): "You're just not as good a programmer as me." Sadly, it takes another 10 years for this arrogance to dissipate.
Have you taken a look at some major C codebases? It's not justification but an appeal to authority seems pretty unnecessary :)
Also function parseAndExecute (). The way he deal with invalid input is, epic: