5 ms·

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 conside

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.
        zvrba 15y ago
        And how are you going to make sure that the length specified is correct?
        jballanc 15y ago
        This is a borderline straw-man argument. Size (length) is one of the few things that you must be very aware of and control when programming C. You cannot "malloc" without knowing the length to malloc. You cannot create an array on the stack without knowing its size. In each case, you may not use the full memory allocated, but at least you can set an upper bound on the memory that you own. Thus, however you created or ingested the string to copy (and the memory to copy it to), you will have an upper bound on how much memory it is safe to copy.
- ori_b 15y ago
  There's a difference between 'difficult to use correctly' and 'broken'. It would be a good idea for you to learn it.
- simias 15y ago
  First, there's no need to be aggressive. I don't really get what you're trying to say. I would understand if you said that strncat is broken (since it can output non \0 terminated strings, unlike the non-standard strlcat, breaking the principle of least astonishment) but I fail to see the problem here. It's just garbage-in/garbage-out: strcpy expects a C string, and the char array you give it is not a C string, so it fails by triggering an undefined behaviour. The function has no way to detect this problem, so it's not even laziness. Pascal strings embed the count within the string, but then you could forge a bogus pascal string with an incorrect size and trigger the same kind of problem.
  - wazoox 15y ago
    > First, there's no need to be aggressive. He isn't aggressive, he simply is the inimitable Zed Shaw :) > The function has no way to detect this problem, so it's not even laziness. His point : therefore you should not use this function, but strlcpy instead. Or course the K&R has the excellent excuse of predating about every alternative secure version of strcpy. > Pascal strings embed the count within the string, but then you could forge a bogus pascal string with an incorrect size and trigger the same kind of problem. I don't think that you could easily forge such a string using Pascal standard functions, but last time I wrote Pascal there was neither syntax highlighting in the editor nor hard drive in my PC. Anyway, strlcpy should be immune, because it will truncate whatever string of bytes to the required length, see: http://www.manpagez.com/man/3/strlcpy/ http://www.manpagez.com/man/3/strlcpy/ It doesn't preclude any implementation error (preperly a bug), of course.

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.
      - zvrba 15y ago
        And how are you going to make sure that the length specified is correct?
        jballanc 15y ago
        This is a borderline straw-man argument. Size (length) is one of the few things that you must be very aware of and control when programming C. You cannot "malloc" without knowing the length to malloc. You cannot create an array on the stack without knowing its size. In each case, you may not use the full memory allocated, but at least you can set an upper bound on the memory that you own. Thus, however you created or ingested the string to copy (and the memory to copy it to), you will have an upper bound on how much memory it is safe to copy.
ori_b 15y ago
There's a difference between 'difficult to use correctly' and 'broken'. It would be a good idea for you to learn it.
simias 15y ago
First, there's no need to be aggressive. I don't really get what you're trying to say. I would understand if you said that strncat is broken (since it can output non \0 terminated strings, unlike the non-standard strlcat, breaking the principle of least astonishment) but I fail to see the problem here. It's just garbage-in/garbage-out: strcpy expects a C string, and the char array you give it is not a C string, so it fails by triggering an undefined behaviour. The function has no way to detect this problem, so it's not even laziness. Pascal strings embed the count within the string, but then you could forge a bogus pascal string with an incorrect size and trigger the same kind of problem.
- wazoox 15y ago
  > First, there's no need to be aggressive. He isn't aggressive, he simply is the inimitable Zed Shaw :) > The function has no way to detect this problem, so it's not even laziness. His point : therefore you should not use this function, but strlcpy instead. Or course the K&R has the excellent excuse of predating about every alternative secure version of strcpy. > Pascal strings embed the count within the string, but then you could forge a bogus pascal string with an incorrect size and trigger the same kind of problem. I don't think that you could easily forge such a string using Pascal standard functions, but last time I wrote Pascal there was neither syntax highlighting in the editor nor hard drive in my PC. Anyway, strlcpy should be immune, because it will truncate whatever string of bytes to the required length, see: http://www.manpagez.com/man/3/strlcpy/ http://www.manpagez.com/man/3/strlcpy/ It doesn't preclude any implementation error (preperly a bug), of course.