It's a bit like claiming memcpy() is bugged because it can crash your program. Well, true, it is good style to program defensively against memory corruptions, buffer overflows etc, and in that respect K&R may teach students bad habits.
I think it's a bit much to say that it should never have been written like that, as at the time people knew so much less about building complex projects, sources of error and defensive programming.
Keeping a book up to date takes a lot of effort, as I'm sure Zed (npi) appreciates. It's an old book, it has warts. As you stated, the density of information was what many people like about the book, so any replacement for it will have to replicate that. I don't think the criticism is unfounded though.
Nah, memcpy shouldn't exist (just not for buffer overflow reasons). memcpy is there because someone got their knickers in a twist over possibly being a few cycles faster than memmove, even though the chances that actually matters is tiny, while the chances that you'll accidentally use memcpy when your memory overlaps is much larger.
actually that justification for memcpy is quite poor. usually, performance wise, it is quite easily beatable once you start using the hardware. most implementations I've seen loop byte copies in the most naïve way possible... almost every architecture supports 32-bit copies, most support more... :)
incidentally I've saved some .2-.8ms per frame in a "AAA" (I use the term loosely and with disgust) game title by replacing compiler generated assignment operator in one struct with an explicit 128-byte copy. copying individual bytes is slow, and the compiler is never as sufficiently smart as people claim.
in analagous cases involving memcpy, the fact that memcpy is not memmove saves much less than actually copying the data in a way that squeezes everything out of the data buses. :)
"almost every architecture supports 32-bit copies"
How much of that was true at the time that function was created?
Also, on 'just use memmove': it would not surprise me if ancient Unices used memcpy instead of inlining it to copy really small buffers (such as 14-byte-max filenames), not for speed, but for the byte savings (even if singular 'byte' is the correct way to phrase that). With small buffers, the overhead of that 'if' can become substantial.
Yes I guess that would be more appropriate. Again, it comes down to the "give it the right inputs" argument. At some point you have to trust the user of the function to call it correctly.
Your argument with permutations of inputs is wrong IMO - this argument can be used to claim that any functionality which calls user code (through callbacks, inheritance, whatever, functors) is also defective. Strictly it may be so, but the defectiveness is massively outweighed by the convenience - the most obvious example is calling a late-binding function - but it extends to easier to grasp examples like the C qsort function or EnumWindows in Win32.
Should we not make library calls because the programmer who wrote the library might have, maybe, possibly, screwed us over in some way perhaps, or because the mechanism can be broken with faulty input?
You trust, potentially, the same programmers every time you trust an executable loader to start running your code... which is pretty much every single time.
Aren't you as the person providing the application ultimately responsible for knowledge of what library calls work well and, thus, which you should use? I think Zed's cautionary statements are merely summarizing a bunch of his experiences, ultimately that this library call isn't worth using.
Permutations of input is not "wrong", its a valid mechanism for exposing unexpected/undefined behavior. "Massively outweighed by the convenience" is subjective and, in many circumstances, very suspect.
Your argument does not follow and is an illogical extension. I simply prove that it has a while-loop that won't terminate and use permutations to prove that. The logic proof is valid because I found an instance of the input that would cause it to not terminate.
You can't then extend my argument to mean that all functions should not be called. All functions with unterminated while-loops shouldn't be called, but not all functions.
I remember the gist of the critique being that the K&R book was perfect for the assumptions of its era, but can mislead people who aren't experienced enough to apply its lessons to the modern networked world
heh heh. Who would have expected mercy and respect from the guy that made the (paraphrased) "pro-mo-fo" website (first saw it at Atlassian conference about 2 weeks ago, pretty funny though perhaps a bit rude). I think the guy is more than willing to point out any practices now deemed harmful, tradition be damned. I'm over it.
I think it's a bit much to say that it should never have been written like that, as at the time people knew so much less about building complex projects, sources of error and defensive programming.
Keeping a book up to date takes a lot of effort, as I'm sure Zed (npi) appreciates. It's an old book, it has warts. As you stated, the density of information was what many people like about the book, so any replacement for it will have to replicate that. I don't think the criticism is unfounded though.