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

Learn C The Hard Way

c.learncodethehardway.org

Post reply on HN
Print view View original

31–40 of 69 posts

Re: Learn C The Hard Way

#31

Post by angersock »

zedshaw wrote: post #28
pantaloons wrote: post #23

Earlier quoted context omitted.

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.

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.

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.

Re: Learn C The Hard Way

#32

Post by shadowmint »

zedshaw wrote: post #29
shadowmint wrote: post #14

Earlier quoted context omitted.

I have some pretty serious issues with the content in LCTHW, and I would say that reading this book is absolutely not going to give you a deep understanding of how modern c programming is done. K&R is an excellent reference, and LCTHW covers some new topics like valgrind, which is great. However, it fails to point out that some of the exercises are just that; exercises. For example, creating a custom type system in C…

Excellent critique, but you show your hand here: > K&R is an excellent reference, and LCTHW covers some new topics like valgrind, which is great. Wrong, I already demonstrate that they have an example that is basically strcpy() and I show why it's broken. By the time I'm done with the book I'll have taken apart the entire book and shown that it's the source of most security holes through poor examples. > However, it…

Hey, sorry if you took it the wrong way. I'm just pointing out some flaws I see in the text, and I fully acknowledge it's a work in progress and these may be solved over time.

However, I will repeat.

K&R is an excellent text. If you disagree, I dispute your credibility.

I also stand by my comment. Smart people have created strong type systems like gobjects and ctypes in C.

As a programmer, you should unequivocally _never_ do this yourself. C is about reuse, and not reinventing the wheel. Sure, if you want to use a strong type system instead of C++, do so. Do not write one yourself.

Re: Learn C The Hard Way

#33

Post by ori_b »

zedshaw wrote: post #28
pantaloons wrote: post #23

Earlier quoted context omitted.

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.

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.

There's a difference between 'difficult to use correctly' and 'broken'. It would be a good idea for you to learn it.

Re: Learn C The Hard Way

#34

Post by thebigshane »

angersock wrote: post #31
zedshaw wrote: post #28

Earlier quoted context omitted.

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.

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

I think he meant the use of strcpy() is buggy.

Re: Learn C The Hard Way

#35

Post by farslan »

babarock wrote: post #11

Wasn't this same book on the front page of HN just a few weeks ago? It just seems so random to see it appear again today? Was there a special release announcement that I'm not seeing?

The page that was on the front page a few weeks ago was just a respond to K&R's C book from the author itself.

Re: Learn C The Hard Way

#36

Post by zedshaw »

angersock wrote: post #31
zedshaw wrote: post #28

Earlier quoted context omitted.

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.

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

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%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.

Re: Learn C The Hard Way

#37

Post by zedshaw »

shadowmint wrote: post #32
zedshaw wrote: post #29

Earlier quoted context omitted.

Excellent critique, but you show your hand here: > K&R is an excellent reference, and LCTHW covers some new topics like valgrind, which is great. Wrong, I already demonstrate that they have an example that is basically strcpy() and I show why it's broken. By the time I'm done with the book I'll have taken apart the entire book and shown that it's the source of most security holes through poor examples. > However, it…

Hey, sorry if you took it the wrong way. I'm just pointing out some flaws I see in the text, and I fully acknowledge it's a work in progress and these may be solved over time. However, I will repeat. K&R is an excellent text. If you disagree, I dispute your credibility. I also stand by my comment. Smart people have created strong type systems like gobjects and ctypes in C. As a programmer, you should unequivocally _n…

> As a programmer, you should unequivocally _never_ do this yourself.

Bullshit. You guys going around throwing your platitudes, shoulds, and nevers at people rarely have any evidence supporting your claims, and usually it just hides a lack of real knowledge.

Re: Learn C The Hard Way

#38

Post by unwind »

zedshaw wrote: post #36
angersock wrote: post #31

Earlier quoted context omitted.

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

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, a…

So, how does one of the "safe" string-copying functions work safely given "any random input"?

Re: Learn C The Hard Way

#39

Post by judofyr »

zedshaw wrote: post #36
angersock wrote: post #31

Earlier quoted context omitted.

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

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, a…

> You can't prove logically that the while loop inside will end given any random input.

C is all about layers, and at the bottom you just assume that "all input given to this function is safe". If you're passing random input (without any error checking) to pretty much any of the built-in functions, You're Doing Something Wrong.

Whether you call strcpy/copy buggy or unsafe doesn't really matter. The implementation on all platforms pretty much follows the standard, with its well-known issues. Sometimes it's the right tool for the job; sometimes not.

It's also important to remember that strcpy_s doesn't just magically solve all your problems. Someone might think that this code is safe:

    strcpy_s(src, 10, dst)
But if dst is shorter than 10, you'll have a problem.

Going from ASCIIZ to length-encoded strings isn't something you can just do in the middle of a function; it requires changes all over the place. K&R was written with ASCIIZ and low-level programming in mind. There's nothing inheritly wrong about this; it has both its advantages and disadvantages. Your book is written with length-encoded strings in mind. (Which I think is the best way to teach today).

I love the concept of this chapter, and I pretty much agree with you in your critisms to strcpy/copy, but suddenly you go from "this code has issues" to "this code is bad, bad, bad; never use this code; only silly people would write this code" and so on (at least that how I feel when I'm reading it). I think you should place more emphasis on "this code was written to only work with certain input; look how bad it performs under fuzz-testing; see how easy we can fix it!".

Re: Learn C The Hard Way

#40

Post by o2sd »

OK. NOT TROLLING, but can I ask why anyone would want to learn C, other than to develop device drivers, kernel modules or other arcane software that is yet to be replaced by C++?

I asked this question of a younger programmer the other day, because it seemed to me, that to HIM, learning C was a rite of passage, and that he was less of a man for not knowing it.

I find macho philosophies in software development both amusing and counter-productive.(If you really want to be macho, become a lisp hacker). My amusement may be personal, but the counter-productivity of using C, when better abstractions (i.e. programming languages) already exist, is real. It creates fiefdoms and priesthoods that are counter-evolutionary and hard to maintain, and leads the death of much software.

Personally, I would rather std::string be pored over by many eyeballs and evolved than change strcpy to _strcpy or strlcpy. Unless I am working for NASA on an embedded device for a satellite, I would rather Moore's law or SMP or DSMP give me the speed I need, than give up productivity to squeeze every last CPU cycle. Developer time is a lot more expensive than hardware (except on satellites and space stations).

Apologies if it is your ambition to work for NASA on embedded devices in space stations, I just think you may as well learn C++. You get most of C, plus some really useful and productive abstractions as well.

If you want speed, learn inter-process communication and the principles of symmetric multi processing. With C++, you also get to abstract away the problems of strcpy and strlen, replace Byzantine function references with class methods, and 35 parameter functions with polymorphism. Best of all, most of the programming world will still think you are manly if you know C++, so you get that too.

Post reply on HN