Not so much bungled as got bitten by a change in behavior. Amusingly, “Return Values” still states the old behavior, to which standard the program is correct.
I'll fix the program.
By the way, the zip archives include a Makefile with correct compiler configuration (namely -std=c99). I tried downloading them after seeing this thread and it didn't work; I've re-uploaded them and now they download correctly, Makefiles and all. No more having to run the compiler by hand.
Ouch. Now the article isn't just advocating overengineering, it's just plain wrong - have you contacted the author to let him know? Probably best for him to fix this up asap.
mturmon hasn't (so far), but a friend just passed me the link to this thread. Thanks nonetheless.
I'll fix it in a few minutes.
And I hope all this criticism isn't too down-heartening... at least from my part (though I strongly believe it is the same for others too) it's intended as friendly and genuine constructive criticism.
Not at all. I always welcome constructive criticism; any opportunity to improve myself, I much appreciate. For my part, any criticism I offer, including the linked article itself, I likewise intend to be constructive.
fputs() now returns a non-negative number (as opposed to 0) on successful completion. As a result, many tests (e.g., "fputs() == 0", "fputs() != 0") do not give the desired result. Use "fputs() != EOF" or "fputs() == EOF" to determine success or failure.
That's the price for over-engineering.