5 ms·

Your question is addressed by the author at the end of the book: http://c.learncodethehardway.org/book/learn-c-the-hard-waych55.html http://c.learncodethehardw

by nikuda 15y ago

Your question is addressed by the author at the end of the book: http://c.learncodethehardway.org/book/learn-c-the-hard-waych55.html http://c.learncodethehardway.org/book/learn-c-the-hard-waych...

Locke1689 15y ago
Great, thanks! I'll admit that I don't think I've ever used K&R C code verbatim[1] so I never saw how outdated all the stylistic code was. I would never recommend this primitive style in modern projects. Thanks for your insight Zed! [1] Really, if you start dealing with the complexities of C at all K&R will no longer do it. First you'll need to read the ANSI C specification to understand what's supposed to be going on, then you'll need to read your compiler's documentation to figure out how they have actually done what the specification says they should do.
pantaloons 15y ago
He brings no pedagogical issues to bare, it's simply a facile critique of "style", I don't think that answers the question why not K&R at all. Some may consider the points well taken, not surprisingly K&R had the foresight to respond in kind, two decades earlier: Our aim is to show the essential elements of the language in real programs, but without getting bogged down in details, rules, and exceptions.
- Tloewald 15y ago
  The charge of being excessively clever is, I think, spot on, and exactly points to pedagogical issues. I think a lot of the examples in K&R are more amusing to those glancing through it who already know C, than to the novice trying to learn it.
- zedshaw 15y ago
  Wrong, I make a clear example of the copy() function being broken, give a demonstration of fuzzing it to break it, and show how to do it yourself. And, if you think the copy() function is valid, then you also think strcpy() function is valid, and therefore you don't know what you're talking about. Everyone who is aware of secure C coding knows strcpy() is buggy and the cause of most buffer overflows.
  - angersock 15y ago
    Dude, stop saying it's broken. For higher level languages where we have intelligent string objects, yeah, bounds checking is assumed--but this is something originating in assembly-level stuff. If you call it with broken memory, of course it won't work correctly. You're doing a good job spreading knowledge--don't spread misinformation. Everyone who is aware of secure C coding knows strcpy() is buggy and the cause of most buffer overflows. If strcpy() was truly buggy and unpredictable in its implementation, it wouldn't be nearly so useful as an attack vector. Be accurate--strcpy() is unsafe, not buggy. Sheesh.
    - thebigshane 15y ago
      I think he meant the use of strcpy() is buggy.
    - zedshaw 15y ago
      No, it's defective and buggy. You can't prove logically that the while loop inside will end given any random input. An implementation with a length will end given any input. That is a bug. If you wrote code like that then I'd flag it as a bug, so how is it that strcpy is somehow reclassified as "unsafe" but yeah totally not a bug? It's so poorly designed that it should be considered wrong, buggy, defective, unsafe, and removed. To go around saying "it's totally alright" when even Microsoft, bringer of more virii than a whore house, has deprecated it: http://msdn.microsoft.com/en-us/library/kk6xf663%28v=vs.80%29.aspx http://msdn.microsoft.com/en-us/library/kk6xf663%28v=vs.80%2... Is idiotic thinking. Go ahead and come up with all the distinctive classifications you want, it's a defect to use strcpy because it's buggy, and copy() in that code is the same.
      - unwind 15y ago
        So, how does one of the "safe" string-copying functions work safely given "any random input"?
        jballanc 15y ago
        By requiring that the length of the string be given as one of the arguments, just like strlcpy does.
comex 15y ago
Of course the completed portion only includes two examples and they are both stupid. ;) while (...) if (...) { ... } if (...) ...; "A quick glance makes it seem like this while-loop will loop both if-statements, but it doesn't." How could you possibly conclude that, considering the indentation?
- prophetjohn 15y ago
  I don't think it's intuitively clear to a non-programmer and maybe not even to a non-C-like-language programmer why that while loop encompasses the first if and not the second.
- lucisferre 15y ago
  I've always been ok with no braces for one line statements. But they have to actually fit on one line and not be another nested block. I recently found a style guide for javascript that recommended only leaving braces out for statements that could be fit on the same line eg: if (something) doSomething(); for (...) repeatSomething(); What I will disagree with is that braces are completely free. I believe that code which is vertically succinct is a good thing. It allows you to see more context at once which is particularly useful with well designed, well structured short methods and classes. I've always been opposed to excess white space, like the random blank lines within methods that programmers seem to put arbitrarily with no rhyme or reason, other than their personal aesthetics of course. Also spaces around arguments, putting the opening brace on it's own line (which I find terribly redundant anyone can see when a block has started). I've always liked the K&R style aesthetically, but again I'll agree that Zed has found a decent example of where not using braces just because you can is taken too far.

by nikuda 15y ago

Your question is addressed by the author at the end of the book: http://c.learncodethehardway.org/book/learn-c-the-hard-waych55.html http://c.learncodethehardway.org/book/learn-c-the-hard-waych...

Locke1689 15y ago

Great, thanks! I'll admit that I don't think I've ever used K&R C code verbatim[1] so I never saw how outdated all the stylistic code was. I would never recommend this primitive style in modern projects. Thanks for your insight Zed! [1] Really, if you start dealing with the complexities of C at all K&R will no longer do it. First you'll need to read the ANSI C specification to understand what's supposed to be going on, then you'll need to read your compiler's documentation to figure out how they have actually done what the specification says they should do.

pantaloons 15y ago

He brings no pedagogical issues to bare, it's simply a facile critique of "style", I don't think that answers the question why not K&R at all. Some may consider the points well taken, not surprisingly K&R had the foresight to respond in kind, two decades earlier: Our aim is to show the essential elements of the language in real programs, but without getting bogged down in details, rules, and exceptions.

Tloewald 15y ago
The charge of being excessively clever is, I think, spot on, and exactly points to pedagogical issues. I think a lot of the examples in K&R are more amusing to those glancing through it who already know C, than to the novice trying to learn it.
zedshaw 15y ago
Wrong, I make a clear example of the copy() function being broken, give a demonstration of fuzzing it to break it, and show how to do it yourself. And, if you think the copy() function is valid, then you also think strcpy() function is valid, and therefore you don't know what you're talking about. Everyone who is aware of secure C coding knows strcpy() is buggy and the cause of most buffer overflows.
- angersock 15y ago
  Dude, stop saying it's broken. For higher level languages where we have intelligent string objects, yeah, bounds checking is assumed--but this is something originating in assembly-level stuff. If you call it with broken memory, of course it won't work correctly. You're doing a good job spreading knowledge--don't spread misinformation. Everyone who is aware of secure C coding knows strcpy() is buggy and the cause of most buffer overflows. If strcpy() was truly buggy and unpredictable in its implementation, it wouldn't be nearly so useful as an attack vector. Be accurate--strcpy() is unsafe, not buggy. Sheesh.
  - thebigshane 15y ago
    I think he meant the use of strcpy() is buggy.
  - zedshaw 15y ago
    No, it's defective and buggy. You can't prove logically that the while loop inside will end given any random input. An implementation with a length will end given any input. That is a bug. If you wrote code like that then I'd flag it as a bug, so how is it that strcpy is somehow reclassified as "unsafe" but yeah totally not a bug? It's so poorly designed that it should be considered wrong, buggy, defective, unsafe, and removed. To go around saying "it's totally alright" when even Microsoft, bringer of more virii than a whore house, has deprecated it: http://msdn.microsoft.com/en-us/library/kk6xf663%28v=vs.80%29.aspx http://msdn.microsoft.com/en-us/library/kk6xf663%28v=vs.80%2... Is idiotic thinking. Go ahead and come up with all the distinctive classifications you want, it's a defect to use strcpy because it's buggy, and copy() in that code is the same.
    - unwind 15y ago
      So, how does one of the "safe" string-copying functions work safely given "any random input"?
      - jballanc 15y ago
        By requiring that the length of the string be given as one of the arguments, just like strlcpy does.

comex 15y ago

Of course the completed portion only includes two examples and they are both stupid. ;) while (...) if (...) { ... } if (...) ...; "A quick glance makes it seem like this while-loop will loop both if-statements, but it doesn't." How could you possibly conclude that, considering the indentation?

prophetjohn 15y ago
I don't think it's intuitively clear to a non-programmer and maybe not even to a non-C-like-language programmer why that while loop encompasses the first if and not the second.
lucisferre 15y ago
I've always been ok with no braces for one line statements. But they have to actually fit on one line and not be another nested block. I recently found a style guide for javascript that recommended only leaving braces out for statements that could be fit on the same line eg: if (something) doSomething(); for (...) repeatSomething(); What I will disagree with is that braces are completely free. I believe that code which is vertically succinct is a good thing. It allows you to see more context at once which is particularly useful with well designed, well structured short methods and classes. I've always been opposed to excess white space, like the random blank lines within methods that programmers seem to put arbitrarily with no rhyme or reason, other than their personal aesthetics of course. Also spaces around arguments, putting the opening brace on it's own line (which I find terribly redundant anyone can see when a block has started). I've always liked the K&R style aesthetically, but again I'll agree that Zed has found a decent example of where not using braces just because you can is taken too far.