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

121–130 of 136 posts

Re: Deconstructing "K&R C"

#121

Post by Roboprog »

tylerc230 wrote: post #38

"Before the switch to heap memory, this program probably ran just fine because the stack allocated memory will probably have a '\0' character at the end on accident." Stack memory is not preinitialized to '0' either so using stack memory would show this 'defect' as well (as others have pointed out this is a defect in the calling code, not in copy).

Even if the stack was 0 filled at startup, it won't be after you call something else, and that other code returns. The stack will simply be loaded with the final values of auto vars from the called routines, as well as return addresses and other such stack frame tracking.

Re: Deconstructing "K&R C"

#122

Post by tptacek »

Roboprog wrote: post #118
zedshaw wrote: post #79

Earlier quoted context omitted.

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…

That's a hell of a good idea. As somebody pointed out, it might not stop you from corrupting neighboring items in an array or structure, but it would let you find the size of an array allocated by itself, AND, it would stop you from corrupting the heap itself!

If you're concerned about corrupting the heap, use an allocator hardened against heap corruption. The default WinAPI allocator, even for optimized production code, is hardened that way. Userland code doesn't need to do anything to get the feature, which is as it should be, because people who write userland code don't know enough to defend the heap against memory corruption.

Re: Deconstructing "K&R C"

#123

Post by tptacek »

Roboprog wrote: post #119
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 would happily trade C ASCIIZ strings for Pascal/Perl/Java out of band length indicated strings, even at the cost of those edge cases. Especially if there were a way to internalize immutable string data, and share the bytes of common fragments. (this of course doesn't work well if you plan on modifying the string data)

So make the trade. I'm sorry, I can see I'm communicating some kind of disdain for alternate string representations, but every C programmer I know --- every single one of them --- has used some form of counted string at some point.

I'm just saying there's a reason the default in C is ASCIIZ. Most of what you do with strings is lightweight; compare 'em, search 'em, tokenize 'em, copy 'em. For that 80% of use cases, ASCIIZ is superior.

Should ANSI C libc provide a heavyweight counted string alternative? Sure, I think so; in fact, it's possible that the only reason it doesn't is that it would take 300 years to resolve all the disputes about exactly what such a library should like like, since every professional C programmer has their own now.

Re: Deconstructing "K&R C"

#124

Post by tedunangst »

bonzoesc wrote: post #116
ori_b wrote: post #114

Earlier quoted context omitted.

Calling string manipulation functions buggy and broken because they fail when you don't pass them a string is both wrong and silly.

How do you test that something in C is a string?

You don't, because you can't. That's basically the same as the beginner question, "How can you test if a pointer has been freed?"

Re: Deconstructing "K&R C"

#125

Post by SeanLuke »

zedshaw wrote: post #78
SeanLuke wrote: post #24

Earlier quoted context omitted.

I'm probably the last person in the world to prefer: while ((len = getline(line, MAXLINE)) > 0) if (len > max) { max = len; copy(longest, line); } if (max > 0) /* there was a line */ printf("%s", longest); I fear this may be literally true: this brace style is called Whitesmith's, and I was reporting bugs to the cc-mode indenter for emacs a while ago. BSD/Allman and K&R styles never made sense to me.

Add a new statement to the while-loop. Now you've figured out why that style isn't so hot. You now have to remember to go add the new braces, and typically people are mentally putting them in so they forget. Same with the last if-statement. You'll go, add the new line, indent and go "cool done". Then scratch your head for hours wondering why it's not working.

Oh, well there are two issues here: whether to always include braces, and what brace style to use. Whitesmiths is a brace style, that's what I was pointing out. The decision to include braces or not is a different thing. I tend to omit braces in obvious situations, but am not beholden to it.

Re: Deconstructing "K&R C"

#126

Post by bonzoesc »

tedunangst wrote: post #124
bonzoesc wrote: post #116

Earlier quoted context omitted.

How do you test that something in C is a string?

You don't, because you can't. That's basically the same as the beginner question, "How can you test if a pointer has been freed?"

It was a rhetorical question. What's the sense in having functions that operate on "strings" if you can't figure out what a "string" is at runtime? It's much saner to have functions operate on "strings that are 80 characters or less" or "a structure containing a integer `length` and an array of `length` chars."

Re: Deconstructing "K&R C"

#127

Post by bonzoesc »

tptacek wrote: post #120
bonzoesc wrote: post #115

Earlier quoted context omitted.

I dug out my 29th printing copy for this :) Dated: the "Hello world" on page 6 produces warnings when compiled "> gcc -ansi -o hello hello.c -Wall" c.f. http://c-faq.com/ansi/maindecl.html Buggy but only to a pedant with infinite time: the word count on page 18 that uses a `double` which will run out of accuracy once you count more words than there are atoms in the universe. ( `double toot = 1000000000000000000; toot…

1. You're singling out the first "hello world" program in the book which is making an effort to show C using the fewest concepts necessary; flip elsewhere in the book and notice the other main() functions return int values. (The default "int" is C89; the "warning" is for C99; the second edition of K&R is ANSI C89, not C99). 2. First the nit misses the spirit of the example which is simply to demonstrate that "double"…

> Not that you have anything to prove to me, but I reject all your examples, and think you were too cavalier about judging K&R.

I don't think it's necessarily cavalier. If I was asked to review code that aligned with the K&R examples today, I'd kick it back.

I'd much prefer a codebase that compiles with -Wall -Werror today than one that doesn't, one that doesn't use floats for integers, one that doesn't use strcpy even from a literal string to the heap, and one that doesn't put a braceless `if` inside a braceless `for`, and I suspect you would too.

It's a good book to learn 1988 C, and if you're just going to learn it for your classes and go off into the exciting world of Java and C# it's probably fine, but it's not the right book to teach someone to write production-quality C.

Re: Deconstructing "K&R C"

#128

Post by Roboprog »

tptacek wrote: post #123
Roboprog wrote: post #119

Earlier quoted context omitted.

I would happily trade C ASCIIZ strings for Pascal/Perl/Java out of band length indicated strings, even at the cost of those edge cases. Especially if there were a way to internalize immutable string data, and share the bytes of common fragments. (this of course doesn't work well if you plan on modifying the string data)

So make the trade. I'm sorry, I can see I'm communicating some kind of disdain for alternate string representations, but every C programmer I know --- every single one of them --- has used some form of counted string at some point. I'm just saying there's a reason the default in C is ASCIIZ. Most of what you do with strings is lightweight; compare 'em, search 'em, tokenize 'em, copy 'em. For that 80% of use cases, AS…

Fair enough. Started something like that, not sure I'll ever finish it, though :-(

https://github.com/roboprog/buzzard/blob/master/bzrt/src/bzr...

Re: Deconstructing "K&R C"

#129

Post by Teckla »

adavies42 wrote: post #20

> Braces Are Free, Use Them I disagree. Braces have a cognitive load, particularly if they're given whole lines to themselves. Which is easier to read, while ((len = getline(line, MAXLINE)) > 0) if (len > max) { max = len; copy(longest, line); } if (max > 0) /* there was a line */ printf("%s", longest); or while ((len = getline(line, MAXLINE)) > 0) { if (len > max) { max = len; copy(longest, line); } } if (max > 0) /…

When it comes to assignment and comparison in constructs such as while loops, I think this variation adds readability:

while (len = getline(line, MAXLINE), len > 0) ...

I've never seen anyone else use it, though.

Re: Deconstructing "K&R C"

#130

Post by tptacek »

bonzoesc wrote: post #127
tptacek wrote: post #120

Earlier quoted context omitted.

1. You're singling out the first "hello world" program in the book which is making an effort to show C using the fewest concepts necessary; flip elsewhere in the book and notice the other main() functions return int values. (The default "int" is C89; the "warning" is for C99; the second edition of K&R is ANSI C89, not C99). 2. First the nit misses the spirit of the example which is simply to demonstrate that "double"…

> Not that you have anything to prove to me, but I reject all your examples, and think you were too cavalier about judging K&R. I don't think it's necessarily cavalier. If I was asked to review code that aligned with the K&R examples today, I'd kick it back. I'd much prefer a codebase that compiles with -Wall -Werror today than one that doesn't, one that doesn't use floats for integers, one that doesn't use strcpy ev…

If you reject code that, for instance, strcpy's string literals (because they could have used strncpy to be extra safe), you're rejecting most professional code today.

I wish it was a best practice that strcpy() was never used, because it would make static source code analysis a lot easier: see strcpy()? Flag it! But no: lots of excellent C code properly relies on the assumption that string literals don't change their size at runtime.

Similarly, yours is a stylistic standard for braces that rejects OpenBSD KNF. Good luck with that. You're entitled to an opinion and, on your own dev teams, it's perfectly reasonable to demand consistency with an "always use braces" style. But it's not reasonable to call style fouls on other people's code that adheres to style(9).

Really strong disagree that K&R isn't a good first book for writing production C. I could go on & on, but since I'm echoing the commanding majority of all C programmers in sharing that sentiment, there's probably no need.

Post reply on HN