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

41–50 of 69 posts

Re: Learn C The Hard Way

#41

Post by Peaker »

o2sd wrote: post #40

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

Not all of us see C++ as an improvement over C.

Sure, C++ has great advantages, but it also great disadvantages.

I use C for many things not because of "macho", but because C is good enough. I can work around the disadvantages using standard techniques. The result is code that is easily FFI'able from any language, quicker to compile, has a smaller footprint, sane error messages, easily debuggable in gdb, etc.

Also, there are some advantages in the abstractions that C encourages you to use. For example, lack of templates pushed C programmers to discover intrusive data structures, and those are better in many ways than templated containers ala STL.

Another example: "virtual" methods may fail to override a base class method if you make a typo - resulting in potentially cryptic bugs. Using a simple macro in C:

  #define MAKE_VTABLE(prefix)  { prefix##foo, prefix##bar }
I can make vtables that are safer than C++, and require no more boilerplate than C++ code. The compiler will guarantee that I implement all of the required vtable methods.

If I want to get speed via multi-core rather than pure uniprocessor speed, why use C++? I can use Haskell and get much easier and safer parallelism with many other advantages.

Re: Learn C The Hard Way

#42

Post by Synaesthesia »

o2sd wrote: post #40

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

Objective-C is a strict superset of C, so learning C helps a lot for any iOS or Mac programming.

C++ is also heavily based on C, so it helps to learn C++.

I agree C is hardly used anymore, and for good reason, but it's still interesting to learn.

Re: Learn C The Hard Way

#43

Post by jballanc »

unwind wrote: post #38
zedshaw wrote: post #36

Earlier quoted context omitted.

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"?

By requiring that the length of the string be given as one of the arguments, just like strlcpy does.

Re: Learn C The Hard Way

#44

Post by jballanc »

judofyr wrote: post #39
zedshaw wrote: post #36

Earlier quoted context omitted.

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…

I'm going to have to side with Zed here. If I'm teaching an introductory class on Chemistry, you'd better believe that when I reach the section on cyanide I'm going to tell students: "bad, bad, bad; never use this chemical"! If those introductory students were to take a more advanced class, then I would probably tell them: "well, ok, cyanide isn't going to kill you instantly and is actually really useful for a wide range of applications".

Part of being a good teacher is recognizing that there are limits to how much you can expect a student to learn at a given level, and then making sure their knowledge is as "complete" as possible within those limits.

Re: Learn C The Hard Way

#45

Post by [deleted] »

zedshaw wrote: post #37
shadowmint wrote: post #32

Earlier quoted context omitted.

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.

[deleted]

Re: Learn C The Hard Way

#46

Post by zvrba »

jballanc wrote: post #43
unwind wrote: post #38

Earlier quoted context omitted.

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

By requiring that the length of the string be given as one of the arguments, just like strlcpy does.

And how are you going to make sure that the length specified is correct?

Re: Learn C The Hard Way

#47

Post by zvrba »

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…

> Wrong, I already demonstrate that they have an example that is basically strcpy() and I show why it's broken.

strcpy() is not broken. You cannot expect a function to work if you violate its preconditions. Exercise for you: enumerate strcpy's preconditions. And once you know them, you design your program in accord with them.

> There's extensive attention to testing

Testing can only prove the presence of bugs, not their absence. Heavy emphasis on testing leads to coding by trial-and-error, which, I argue, is the prime source of bugs (security and others).

"Hey, I tested it, it works!" What's missing in that statement is that it works for usual test cases. Software breaks on unusual/abnormal inputs. If, e.g., strcpy causes buffer overflow in your program, it is YOUR code that is crap because it didn't ensure proper preconditions. Don't project your incompetence/stupidity on strcpy.

THIS is what programmers should learn.

Your quote from K&R "critique": "And, what's the point of a book full of code you can't actually use in your own programs?" This line of thinking is despicable. A book is supposed to teach people ideas and concepts, not give them ready-made code recipes that they can copy-paste in their own programs.

Re: Learn C The Hard Way

#48

Post by o2sd »

Peaker wrote: post #41
o2sd wrote: post #40

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

Not all of us see C++ as an improvement over C. Sure, C++ has great advantages, but it also great disadvantages. I use C for many things not because of "macho", but because C is good enough. I can work around the disadvantages using standard techniques. The result is code that is easily FFI'able from any language, quicker to compile, has a smaller footprint, sane error messages, easily debuggable in gdb, etc. Also, t…

Thanks for your reply.

> Not all of us see C++ as an improvement over C.

I know, but you are the first I've encountered to quantify it.

> The result is code that is easily FFI'able from any language

I agree that this is a big advantage for interoperability. While it's possible to build an interface in C++ with 'extern C', it means maintaining two call APIs rather than one. Still I see this as a current limitation of C++ rather than an advantage of C.

> Using a simple macro in C:

Is generally a pain as the macro is expanded at compile time and causes difficulties debugging. Your point about VTABLEs is well taken however and I have encountered subtle bugs with virtual member functions in C++.

> If I want to get speed via multi-core rather than pure uniprocessor speed, why use C++? I can use Haskell and get much easier and safer parallelism with many other advantages.

You would need to enumerate those advantages for me to answer. Why then wouldn't you use Haskell instead of C?

Re: Learn C The Hard Way

#49

Post by o2sd »

Synaesthesia wrote: post #42
o2sd wrote: post #40

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

Objective-C is a strict superset of C, so learning C helps a lot for any iOS or Mac programming. C++ is also heavily based on C, so it helps to learn C++. I agree C is hardly used anymore, and for good reason, but it's still interesting to learn.

If I wanted to do iOS/Cocoa programming, I would go straight to Objective-C, bypassing C without stopping, but that's me.

I learned C++ without ever learning C. Although, one could make the argument that in learning C++, I learned about 80% of C anyway. I can debug and fix C code, but I don't enjoy it, and avoid it if possible.

C is interesting, in the same way that Cuneiform is interesting. Personally I just find the Roman alphabet a lot more productive.

Re: Learn C The Hard Way

#50

Post by simias »

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.

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.

Post reply on HN