8 ms·

// use heap memory as many modern systems do char line = malloc(MAXLINE); char longest = malloc(MAXLINE); assert(line != NULL && longest != NULL

by eliben 14y ago

// use heap memory as many modern systems do char *line = malloc(MAXLINE); char *longest = malloc(MAXLINE); assert(line != NULL && longest != NULL && "memory error"); // initialize it but make a classic "off by one" error for(i = 0; i < MAXLINE; i++) { line[i] = 'a'; } So, you create something that does not fulfill the C library invariant of what constitutes a "string", and then pass it to a copy function that assumes this invariant? It isn't a fair thing to do, and frankly, I doubt it many beginner programmers care about things like this. Yes, they may run into such a "defect" and be very miserable for a while, but that will just teach them about debugging, and most important, invariants. Zed, I appreciate your work, but if this is the direction you'll be taking with these articles, then don't bother.

chj 14y ago
You are being too kind. I was expecting some earth shaking discoveries, only to find the author doesn't understand C.
- PommeDeTerre 14y ago
  Zed and his writings are not to be taken too seriously.
  - to3m 14y ago
    I suspect this one is a diversionary tactic. I guess Zed Shaw suffers from nerd burnout. As in, a sort of more emotional burnout from having had to deal with them all the time in the past - or at least, that's what I get from some of his writings anyway. So I imagine him popping this stuff in as a sort of early warning system. It's all true enough to be right, and true enough to get his point across, BUT IT'S NOT TRUE ENOUGH FOR A NERD. So any time somebody complains about his strcpy example, or 0-terminated C strings, or whatever, that's his nerd alert. This person is not worth dealing with, and now he can block them, or set up a mail filter to put their email in the junk folder, or whatever, without having had to invest any time in finding this out the long way. There was also a bit in one of his essays about the way ruby fans were always these stupid armchair pop psychologists.
    - Evbn 14y ago
      Yeah, when your entire career and persona is built around being the only intelligent person in an industry full of idiots, it is natural to need to drive all the knowledgeable people out of your personal space.
    - jlgreco 14y ago
      I think it functions less as a "nerd" alert but more as a "recognizes I may not be as profound as I like to imagine myself" alert. I mean, he's right.. but he's not being profound. You may as well tell me that I should be careful about losing precision while using floats. Yes... no shit?
  - tangue 14y ago
    "C is a ghetto"
- eliben 14y ago
  I'm not trying to be "kind". I usually like reading Zed's technical work and just express my opinion about this particular piece. I agree that debating the theoretical provability of correctness of programs may be interesting in some academic courses, but using it to bash K&R for their book's contents is, as I said, unfair.
- primitur 14y ago
  I concur, I wonder honestly whether this is a matter of hubris becoming more important than accuracy. The accurate fact is that K&R C is a book about C. It is not the end-all, but rather an introduction to the language. Sure, it has thorns. Sure, you'd be a fool to adopt the style from it; this speaks more of the culture of its readership than the book itself, however. The authors are very honest that their samples are an attempt to engage the readers attention in the Language; especially the Ingenue, new-comer, non-Professional C programmer. To that end, the book succeeds; new C programmers get an introduction, a light read, a good set of nomenclature to understand the topic further, and so on. It is not intended, in spite of the cultural proclivity towards these things, to be "A Bible of C". And if it were, no professional C coder worth their salty words these days would be without the New Testament, right alongside K&R on the neglected end of the bookstack, which book is of course: "Advanced C Programming - Deep C Secrets" which explains rather a lot more about the thorns of Professional C, and more, in an equally comfortable manner as both K&R, the Authors of C as well as books about C, have done. In my opinion, Peter Van Linden has already done to K&R what Zed doesn't seem to have the humility to do; proven its value to the newcomer in becoming one step closer to a professional.
  - vvhn 14y ago
    agreed. Once you know C, deep C secrets takes it to a whole new level and is an great body of work. My 3 C books are 1- K&R 2- C Traps and pitfalls 3- Deep C secrets.
- pretoriusB 14y ago
  Yes, we are all sure you understand C better than ZShaw. I expect you will point us to your prodigal output in the language, and that it was only by accident that you forgotten to add any points of critique in your comment.
- vidarh 14y ago
  He certainly understand C programmers well enough to understand that when they write code like the one he critiqued, it's like handing a kid a loaded shotgun. It will lead to misery.
thristian 14y ago
> So, you create something that does not fulfill the C library invariant of what constitutes a "string", and then pass it to a copy function that assumes this invariant? From the article: > Some folks then defend this function (despite the proof above) by claiming that the strings in the proof aren't C strings. They want to apply an artful dodge that says "the function is not defective because you aren't giving it the right inputs", but I'm saying the function is defective because most of the possible inputs cause it to crash the software. Zed's point is not that K&R is bad because their example code doesn't match C library invariants, he's saying it's bad because it encourages people to write code that blindly assumes C library invariants will always hold. Certainly, if you're going to write C code there's some things that really do require blind trust (for example: that your code will be compiled by a conformant C compiler), but "all strings are safely null-terminated" is incorrect so often, and the cause of so many historic security vulnerabilities and crashes, that perhaps we shouldn't be encouraging new C programmers to do it.
- revelation 14y ago
  So in a dynamically typed language, we then add type checks everywhere? Because we wouldn't want a function to accidentally process data that wasn't meant for it, no?
  - jfager 14y ago
    The equivalent errors in dynamically typed languages don't lead to critical security vulnerabilities like they do in C. You get a nice exception and a clean crash, not a hook to grab root.
    - PommeDeTerre 14y ago
      Realistically, just about every mainstream dynamic language today has its major implementation(s) written using C or C++. Some of them have significant amounts of C code underlying their common libraries, as well. Some of the most popular third-party libraries or modules are in fact nothing more than thin wrappers over existing C or C++ code. Don't think that you're escaping C or C++ just because you're using Ruby, or JavaScript, or Python, or Perl, or Tcl, or even Java. Don't think that you aren't as vulnerable using a dynamic language as you are using C or C++ directly. Furthermore, it is quite easy for dynamically typed languages to suffer from very serious security vulnerabilities. There was one affecting Ruby and Ruby on Rails widely publicized just a few days ago. You can read more about it at: http://news.ycombinator.com/item?id=5002006 http://news.ycombinator.com/item?id=5002006
pretoriusB 14y ago
>So, you create something that does not fulfill the C library invariant of what constitutes a "string", and then pass it to a copy function that assumes this invariant? It isn't a fair thing to do Well, life as a program is not fair either. The problem is your function can be used in many contexts, including by other people. You should not expect them to be fair, you should make your function robust.
chernevik 14y ago
"if this is the direction you'll be taking with these articles, then don't bother" But this thread on the book is a pretty good resource on issues and gotchas for newbies. I largely use Python, I've dabbled in C and always mean to learn more. K&R to me is the touchstone for that, just because so much of programming culture stems off of it. I find knowing these historical patterns helpful for understanding how programmers talk. For someone like me, respectful critique of its style and decisions helps separate the good from the less-helpful. Whether Zed intended to start that discussion or not, it's still helpful.

// use heap memory as many modern systems do char *line = malloc(MAXLINE); char *longest = malloc(MAXLINE); assert(line != NULL && longest != NULL

by eliben 14y ago

chj 14y ago

You are being too kind. I was expecting some earth shaking discoveries, only to find the author doesn't understand C.

PommeDeTerre 14y ago
Zed and his writings are not to be taken too seriously.
- to3m 14y ago
  I suspect this one is a diversionary tactic. I guess Zed Shaw suffers from nerd burnout. As in, a sort of more emotional burnout from having had to deal with them all the time in the past - or at least, that's what I get from some of his writings anyway. So I imagine him popping this stuff in as a sort of early warning system. It's all true enough to be right, and true enough to get his point across, BUT IT'S NOT TRUE ENOUGH FOR A NERD. So any time somebody complains about his strcpy example, or 0-terminated C strings, or whatever, that's his nerd alert. This person is not worth dealing with, and now he can block them, or set up a mail filter to put their email in the junk folder, or whatever, without having had to invest any time in finding this out the long way. There was also a bit in one of his essays about the way ruby fans were always these stupid armchair pop psychologists.
  - Evbn 14y ago
    Yeah, when your entire career and persona is built around being the only intelligent person in an industry full of idiots, it is natural to need to drive all the knowledgeable people out of your personal space.
  - jlgreco 14y ago
    I think it functions less as a "nerd" alert but more as a "recognizes I may not be as profound as I like to imagine myself" alert. I mean, he's right.. but he's not being profound. You may as well tell me that I should be careful about losing precision while using floats. Yes... no shit?
- tangue 14y ago
  "C is a ghetto"
eliben 14y ago
I'm not trying to be "kind". I usually like reading Zed's technical work and just express my opinion about this particular piece. I agree that debating the theoretical provability of correctness of programs may be interesting in some academic courses, but using it to bash K&R for their book's contents is, as I said, unfair.
primitur 14y ago
I concur, I wonder honestly whether this is a matter of hubris becoming more important than accuracy. The accurate fact is that K&R C is a book about C. It is not the end-all, but rather an introduction to the language. Sure, it has thorns. Sure, you'd be a fool to adopt the style from it; this speaks more of the culture of its readership than the book itself, however. The authors are very honest that their samples are an attempt to engage the readers attention in the Language; especially the Ingenue, new-comer, non-Professional C programmer. To that end, the book succeeds; new C programmers get an introduction, a light read, a good set of nomenclature to understand the topic further, and so on. It is not intended, in spite of the cultural proclivity towards these things, to be "A Bible of C". And if it were, no professional C coder worth their salty words these days would be without the New Testament, right alongside K&R on the neglected end of the bookstack, which book is of course: "Advanced C Programming - Deep C Secrets" which explains rather a lot more about the thorns of Professional C, and more, in an equally comfortable manner as both K&R, the Authors of C as well as books about C, have done. In my opinion, Peter Van Linden has already done to K&R what Zed doesn't seem to have the humility to do; proven its value to the newcomer in becoming one step closer to a professional.
- vvhn 14y ago
  agreed. Once you know C, deep C secrets takes it to a whole new level and is an great body of work. My 3 C books are 1- K&R 2- C Traps and pitfalls 3- Deep C secrets.
pretoriusB 14y ago
Yes, we are all sure you understand C better than ZShaw. I expect you will point us to your prodigal output in the language, and that it was only by accident that you forgotten to add any points of critique in your comment.
vidarh 14y ago
He certainly understand C programmers well enough to understand that when they write code like the one he critiqued, it's like handing a kid a loaded shotgun. It will lead to misery.

thristian 14y ago

> So, you create something that does not fulfill the C library invariant of what constitutes a "string", and then pass it to a copy function that assumes this invariant? From the article: > Some folks then defend this function (despite the proof above) by claiming that the strings in the proof aren't C strings. They want to apply an artful dodge that says "the function is not defective because you aren't giving it the right inputs", but I'm saying the function is defective because most of the possible inputs cause it to crash the software. Zed's point is not that K&R is bad because their example code doesn't match C library invariants, he's saying it's bad because it encourages people to write code that blindly assumes C library invariants will always hold. Certainly, if you're going to write C code there's some things that really do require blind trust (for example: that your code will be compiled by a conformant C compiler), but "all strings are safely null-terminated" is incorrect so often, and the cause of so many historic security vulnerabilities and crashes, that perhaps we shouldn't be encouraging new C programmers to do it.

revelation 14y ago
So in a dynamically typed language, we then add type checks everywhere? Because we wouldn't want a function to accidentally process data that wasn't meant for it, no?
- jfager 14y ago
  The equivalent errors in dynamically typed languages don't lead to critical security vulnerabilities like they do in C. You get a nice exception and a clean crash, not a hook to grab root.
  - PommeDeTerre 14y ago
    Realistically, just about every mainstream dynamic language today has its major implementation(s) written using C or C++. Some of them have significant amounts of C code underlying their common libraries, as well. Some of the most popular third-party libraries or modules are in fact nothing more than thin wrappers over existing C or C++ code. Don't think that you're escaping C or C++ just because you're using Ruby, or JavaScript, or Python, or Perl, or Tcl, or even Java. Don't think that you aren't as vulnerable using a dynamic language as you are using C or C++ directly. Furthermore, it is quite easy for dynamically typed languages to suffer from very serious security vulnerabilities. There was one affecting Ruby and Ruby on Rails widely publicized just a few days ago. You can read more about it at: http://news.ycombinator.com/item?id=5002006 http://news.ycombinator.com/item?id=5002006

pretoriusB 14y ago

>So, you create something that does not fulfill the C library invariant of what constitutes a "string", and then pass it to a copy function that assumes this invariant? It isn't a fair thing to do Well, life as a program is not fair either. The problem is your function can be used in many contexts, including by other people. You should not expect them to be fair, you should make your function robust.

chernevik 14y ago

"if this is the direction you'll be taking with these articles, then don't bother" But this thread on the book is a pretty good resource on issues and gotchas for newbies. I largely use Python, I've dabbled in C and always mean to learn more. K&R to me is the touchstone for that, just because so much of programming culture stems off of it. I find knowing these historical patterns helpful for understanding how programmers talk. For someone like me, respectful critique of its style and decisions helps separate the good from the less-helpful. Whether Zed intended to start that discussion or not, it's still helpful.