C programming - luckily in my opinion - has a culture of very rigorous evaluation of programming techniques especially towards memory-unsafe programming, arguably the biggest weakness of C as a programming language.
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.
Unfortunately, there are not a single but a multitude of cultures within the C programming community that compete with others, most of them claiming they are safer than others.
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.
I see usages of fgets in Ch4, not bare gets (didn't check thoroughly)
/* Read a line of user input of maximum size 2048 */
fgets(input, 2048, stdin);
So that fgets does not read in too much data we also must also supply the size of the buffer 2048.
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.
At least some of the things on that list have long been bugbears and known as sources for either incorrect/erroneous explanations and code (most of Schildt's output for instance). So it may be an attempt at gatekeeping but on the face of it seems a reasonable one.
I have little C experience. I've always wanted to learn it properly to broaden my horizons, so I really respect the opinions of the gatekeepers: C is a small footprint language with plenty of footguns.
It goes beyond matters of style and straight to things like memory leaks that can cause security issues.
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.