Hacker News new | ask | show | jobs
by heja2009 1826 days ago
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.

3 comments

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.

[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

Kudos to you for providing an explanation where the dot info people couldn't be bothered.
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.