This book is on "Stuff that should be avoided" list[0].
[0] http://iso-9899.info/wiki/Main_Page#Stuff_that_should_be_avo...
[0] http://iso-9899.info/wiki/Main_Page#Stuff_that_should_be_avo...
This book uses gets() which is a function that can not be used safely. Any input that exceeds the buffer length will corrupt memory. The conventional wisdom in the C community is to NEVER use gets. I personally stopped reading in chapter 4 where this is done.
Unfortunately strictly avoiding memory issues is somewhat involved und thus often ignored in C beginner books. It is also hard to see unless you are pretty familiar with C's pitfalls. IMHO this is why this list of bad books is desperately needed.
The aforementioned list for example has Jed Shaw's Learn C The Hard Way as having "[t]oo many factual problems and a presentation that gets you to do things wrongly before being shown how to do it correctly, and not even always then". This is an opinion held by the ##c channel, not necessarily every (competent) C programmer. LCTHW itself did a great service by introducing valgrind very early, and most criticisms [1] seem to be presentation issues that might be partly necessary for beginners and partly a matter of taste. (I personally think LCTHW was in particular unfairly attacked because of its merciless treatment of K&R. It's a shame that Jed Shaw gave up then.) To this date I don't have any good beginner-level C book to recommend, including K&R.
[1] as judged by famous Don't Learn C the Wrong Way essay by Tim Hentenaar: http://hentenaar.com/dont-learn-c-the-wrong-way
/* Read a line of user input of maximum size 2048 */
fgets(input, 2048, stdin);
Maybe they updated? Also I'd understand not trying to be 100% safe in the code here to make the code easier to read, unlike in a production version of the tool.
The language allows too much freedom for a beginner and things can go bad quickly if you aren't rigorous about developing the right habits.
Years of experience helping people and seeing it happen first-hand is what leads to these strong opinions that you interpret as gatekeeping.
It goes beyond matters of style and straight to things like memory leaks that can cause security issues.
Then I wondered, "If these are the resources to avoid, where do these people recommend I find the good information?"
Alas, those links are mostly broken.
As a long time programmer recently learning C, I've been surprised by how prickly and unhelpful C culture tends to be.
The concensus seems to be that no published information is good enough, and none of the critics are willing to publish the good information.
Maybe I just haven't found the right groups?
Is it? As far as I saw, this is just the web site of the ##C channel on Freenode.
It would be nice if they actually bothered to explain. I'm inclined to trust Build Your Own Lisp over blah blah dot info if the latter is going to engage in nonspecific mudslinging.
MPC for a lisp? No macros? No GC? No readline but editline, but not on Windows? fgets? A lisp is fine with a readchar() and putchar() alone. The rest should be done in a safe and more expressive language, lisp. Compare to a good and small Lisp instead. It need not to be "Lisp in Small Pieces", rather your typical lisp in 10 days or in 1K project.
* https://github.com/rui314/minilisp/blob/master/minilisp.c
* SIOD Scheme in one day
Whilst "A Modern Approach" is a great book, it's hard for me to keep focused as I'm not really implementing anything other than the exercises and projects (for which there are too many IMO, and I struggle to get them all done).
I've been working through Build Your Own Lisp in parallel, and it's great fun. I get to work on an actual project, and any holes I find in my knowledge can usually be filled in via A Modern Approach.
The books were triaged based on the feedbacks we heard, the kind of questions that are asked on the channel, or how confused those readers are after reading through them.