Noble goals. And now that you said that I don't understand how I could have overlooked that in the first place.
Maybe it would be a good idea to put a bit more stress on the "no" in "no sacred cows", that's an important point beyond just K&R. Nothing should be sacred, including "Learning C The Hard Way" - and a "question everything and everyone" mindset is generally a good thing to have as a programmer [I think I read that in "The Pragmatic Programmer" ;-)]. But other than that I now think that chapter is fine. I do apologize for the somewhat passive-aggressive form of my question.
I don't see his point, really. Yes, C doesn't have a statically testable string type. And yes, the convention is that a C "string" is just an array of character data with a trailing NUL-Byte. He constructs an array without a trailing NUL-Byte - so that's not a string, but an array of characters.
The fact that copy() now happily runs through memory is the expected result of the bug in the calling code. No, it's not useful. Yes, there are problems with the whole approach of using a terminating value - but this doesn't seem to be his point (otherwise he would also have mentioned the linear runtime complexity of strlen() and the problems that arise when a string itself contains a NUL-byte, I suppose).
Now, what is his point? This is chapter 55 [!] in a book called "Learn C The Hard Way" and the author complains about well-know problems with the standard-lib string convention, optional braces, and the common C idiom of doing assignment and value-testing at the same time, _and_ calls all of this 'Deconstructing "K&R C"'?
Maybe a "What I personally don't like about C" would have been a better title. The K&R examples are flawless. The language and stdlib are not. That's well-known. What is new?
Also, he uses low-contrast grey text on a white background (might be better readable on a better screen, but on my shitty laptop it makes things harder to read than necessary) + the navigation links on top have no text at all on them (this might be intentional, due to his server having problems).
I, for one, like my advices best from people with at least basic skills in the area. Or from people who at least try to adopt the things they say/just learned/want to pass on.
I'd like to second this. Especially the "why". I do recognize a good design when I see it, and there's an overwhelming wealth of tutorials on the web. But, for me, the link is missing - _why_ does this look good?
Why is Helvetica better than Comic Sans? There must be a reason other than "obviously, it looks better". Don't hesitate to show me the math, and the formulas. I got a machine with me. It can calculate pretty good.
Maybe it would be a good idea to put a bit more stress on the "no" in "no sacred cows", that's an important point beyond just K&R. Nothing should be sacred, including "Learning C The Hard Way" - and a "question everything and everyone" mindset is generally a good thing to have as a programmer [I think I read that in "The Pragmatic Programmer" ;-)]. But other than that I now think that chapter is fine. I do apologize for the somewhat passive-aggressive form of my question.
Thanks a lot!