1. 8

  2. 5

    Some people don’t like Shaw’s tutorial


    Whatever floats your boat, right?

    1. 7

      While many people seem to like Zed’s Python book, his C book does a lot of damage. It’s clear he doesn’t actually understand C.

      For a rebuttal to his deconstruction of K&R read:


      1. 3

        I think I (dis)agree with both of them. As a practical matter, programmers have had remarkable difficulty ensuring the destination of strcpy is large enough. Rarely, however, are there problems with the source being unterminated. And while it’s possible to enter the wrong size for the destination, that too is much rarer than source/dest size mismatches; many such mistakes come from not thinking as opposed to incorrect thinking. Aka, the strlcpy debate in a nutshell.

        1. 4

          Do you have any resources you recommend for an intermediate-level C programmer who wants to get up to speed on modern practices?

          1. 2

            I think a lot of “modern” practice is really the recognition that bugs are rarely one off, and if one programmer screwed up strcpy (e.g.), then probably somebody else did too. And if you find that second programmer in a reasonably short amount of time, then the probability is more like everybody screwed up. Repeat for format strings. Repeat for multiplication overflow. Repeat for temp files. Repeat for random numbers.

            C, perhaps more than most languages, benefits from a “don’t fix bugs; change practices” approach. I think when people hear that, they typically assume something like “I should change my testing strategy” etc. The normal “fix it twice” strategy. Something external to the bytes in the source file. For C it applies to the text of the program too. If you change an int from signed to unsigned, you should immediately ask how many other ints should be converted and how you will find them.

        2. 1

          Yet, I’d have to see an argument for that. The wiki page just lists it as “to avoid”.

          It isn’t on http://www.cs.technion.ac.il/users/yechiel/CS/BadBooksC+C++.html or any other list that makes an effort to describe their problems with it. Either that or I am bad at googeling.

      2. 3

        K&R is also short (i.e., does not look impressive on shelf) and has no pictures (i.e., not manager friendly). You need something ten times longer with pictures (free pdf download)