Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Deconstructing "K&R C"

c.learncodethehardway.org

Post reply on HN
Print view View original

81–90 of 136 posts

Re: Deconstructing "K&R C"

#81

Post by zedshaw »

CJefferson wrote: post #21
kisielk wrote: post #11

Earlier quoted context omitted.

One problem with it is that on most compilers if you compile with optimizations it will remove the assertion. Now the code is no longer guarded against malloc failures and will just segfault. If the intent is to teach people how to handle malloc failures gracefully, it's not that great of an example.

Why do you think the compiler with optimizations will remove the assertion? The compiler will realise that: assert(assert(line != NULL && longest != NULL && "memory error"); Is equivalent to: assert(line != NULL && longest != NULL); But there doesn't seem anything wrong with that.

In the earlier chapters they setup a Makefile with full debugging on so these don't get removed. It's mostly just for this one exercise, and in the rest of the book they use a set of debug macros I wrote:

http://c.learncodethehardway.org/book/learn-c-the-hard-waych...

Re: Deconstructing "K&R C"

#82

Post by zedshaw »

tptacek wrote: post #55
bonzoesc wrote: post #46

Earlier quoted context omitted.

Dated, buggy, and un-stylish examples are exactly what diminishes it.

And those dated, buggy, and unstylish examples would be?

Well when my book is finished you can come back read all of the ones I find, but demanding that someone go through the book and write down every example they found to answer your one-liner is a bit unfair.

Re: Deconstructing "K&R C"

#83

Post by zedshaw »

marshray wrote: post #41
blix wrote: post #31

Earlier quoted context omitted.

I'm confused by your comment. strcpy assumes that the string to be copied ends with a NUL. The case described in the link violated that assumption and caused a segfault.

To be pedantic, it's not that strcpy is making assumptions . Its interface is defined such that it is explicitly invalid to pass it some other garbage.

To be both pedantic and correct, there is no way to define a C function to restrict a string input so that it is correctly terminated. So no, it's at best documented that you shouldn't do that and definitely doesn't prevent you from doing this.

Re: Deconstructing "K&R C"

#84

Post by tptacek »

zedshaw wrote: post #82
tptacek wrote: post #55

Earlier quoted context omitted.

And those dated, buggy, and unstylish examples would be?

Well when my book is finished you can come back read all of the ones I find, but demanding that someone go through the book and write down every example they found to answer your one-liner is a bit unfair.

I wasn't replying to you, and wouldn't have written that reply to you. You wrote a whole chapter of a book about your thoughts on K&R. You obviously read it.

I'm guessing the person I replied to has zero, because people who cavalierly call K&R "dated" and "buggy" probably haven't read it. But Bryce has an interesting background. I could be wrong. Calculated risk. Would love an answer from him.

Re: Deconstructing "K&R C"

#85

Post by ori_b »

zedshaw wrote: post #73
mechanical_fish wrote: post #35

Earlier quoted context omitted.

This chapter is explicitly teaching people what the author's idea of bad C code is: It has them read some, then tells them specifically what the gotchas are, then asks them to code up test cases for the flaws and run them through Valgrind. Where's the "avoiding" here? And which of the skills being exercised - imagining what kinds of bad things could happen, writing executable test cases, detecting segfaults - are not…

That's basically the point of this chapter. It's getting people to think like a hacker and try to break the code in unintended ways. That makes them better programmers and helps when avoiding common mistakes in C code. Using K&R to do this is to give people a set of known good C code samples and show how even those can be broken and misused.

Noble goal, but the way the chapter is written doesn't really come across that way, in my opinion.

Re: Deconstructing "K&R C"

#86

Post by tptacek »

zedshaw wrote: post #79
tptacek wrote: post #53

Earlier quoted context omitted.

It's way worse than an extra byte, or the offset of 1 byte for pointers; it also means you need a whole copy of every substring with its own length delimiter, and can't tokenize in place. C code gets into just as much trouble with length-delimited data structures as it does with ASCIIZ; ASCIIZ is a red herring. People have declared over and over again that it's the single worst decision in C and the cause of every bu…

I partially agree with you, but in a different way. I feel that the real problem is the OS doesn't give code access to its own internal accounting of allocated memory. It already knows the size of any heap chunk you make, so why can't we ask it? In most C code we're carrying around either a null terminator (which can get clobbered) or a whole integer for the size. Instead, there should be a way to ask the OS "how big…

Part of the problem here is that the allocator doesn't need to know how big the crap the pointer is pointing at is; it only needs to know that the crap is smaller thank the chunk it allocated.

If you're going to teach people something unorthodox about C programming, writing custom allocators would probably be a great one. In more than one job I've crushed optimization problems on code written by people way smarter than me simply by knowing to profile allocation and replace malloc.

Re: Deconstructing "K&R C"

#87

Post by tptacek »

zedshaw wrote: post #72
tptacek wrote: post #52

Earlier quoted context omitted.

It's not just that the to/from is a hassle, it's also that you have to deeply understand the gotchas of ASCIIZ strings to safely do that bridging at all --- so pretending it doesn't exist is probably not a good teaching strategy. (I have no opinion about the article and am only commenting on this thread because I like C).

I do not pretend anything about null-terminated strings in the book. In fact, I have many exercises and assignments where they use Valgrind to buffer overflow C strings repeatedly and don't introduce bstring until much later.

Sorry, I haven't read your book, meant to be clear that I was talking in the abstract, but I can see after rereading I wasn't clear enough.

Re: Deconstructing "K&R C"

#88

Post by tptacek »

zedshaw wrote: post #61
tba wrote: post #8

I'm confused. What is the "defect" in K&R's "copy(char to[], char from[])" function? The author notes that "the second this function is called...without a trailing '\0' character, then you'll hit difficult to debug errors", but no function with that signature could possibly work in this case. The built-in "strcpy" function has the exact same limitation. Does the author have a problem with it as well? Null-termination…

> but no function with that signature could possibly work in this case. This is the source of the bugs in C. People write functions that only work given all calls to them are never changed, which is absurd. Good modern C code involves trying to protect against bad usage and adding defensive checks. So yes, the built-in strcpy is crap which is why most competent C doesn't use it except in a few rare cases where it's r…

High level string libraries are a win.

But you may be overstating your case a bit.

From my codebase/third-party directory on my laptop (a bit random, I admit), from those projects I'd consider "competent C" (ie, not OpenSSL or MRI ruby):

* dovecot uses ASCIIZ strings and libc string functions

* redis uses ASCIIZ strings and libc string functions

* nginx uses a high-level buffered string library

* lcamtuf's skipfish scanner uses ASCIIZ strings and libc string functions

* libevent uses ASCIIZ strings and libc string functions

* qmail uses djb's string library

* memcached uses ASCIIZ strings and libc string functions

It's probably good to be comfortable with both approaches.

I don't know that you actually made this claim, but you seem to have given people here the impression that you believe functions that work with ASCIIZ strings should be bulletproofed to handle non-ASCIIZ inputs. I couldn't agree with that argument, especially as an argument about K&R's code being rusty.

People here are jumpy though (they're commenting, like me, mostly because they're bored).

Looking forward to more examples from the book.

Re: Deconstructing "K&R C"

#89

Post by aptwebapps »

ori_b wrote: post #85
zedshaw wrote: post #73

Earlier quoted context omitted.

That's basically the point of this chapter. It's getting people to think like a hacker and try to break the code in unintended ways. That makes them better programmers and helps when avoiding common mistakes in C code. Using K&R to do this is to give people a set of known good C code samples and show how even those can be broken and misused.

Noble goal, but the way the chapter is written doesn't really come across that way, in my opinion.

Speaking as someone who doesn't know C, hasn't read K&R, but who (usually!) has decent reading comprehension, it _does_ come across this way.

He's completely explicit about what he's doing and why. I don't understand how people can read that and still feel that he's being unfair.

Maybe I'm just too literal-minded.

Re: Deconstructing "K&R C"

#90

Post by michaelfeathers »

zedshaw wrote: post #67
askmeaboutloom wrote: post #18

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 us…

> I don't see his point, really. The point is three fold: 1. K&R has defects in it when the functions in it are used out of context because they didn't include defensive programming practices considered standard today. 2. People can learn a lot about writing good code by critiquing other code, even from masters, so I'm taking them through doing that. 3. There should be no sacred cows, and people hold K&R on a pedesta…

I'd rather see a book on writing C code the Zed way.
Post reply on HN