[zedshaw]

It's interesting that you'd use an anonymous account to sling some slander, but I'll answer you:

Yep, that comment thread is great and people should read it for an explanation as to how completely insecure C is. It made me realize that nobody can teach C safely. Not me, not K&R, nobody. The language is completely unsafe by design. If you think K&R could, you should realize that they fixed the code in the book numerous times to make it more secure during it's 40+ printings.

Based on that, I killed my darlings. I should have never started this book as a "C book". I rewrote about 50% of it to instead focus on the things a mere mortal like me can teach:

  0. How to learn any programming language quickly with some tricks I know.
  1. Secure programming and defensive coding skills, which a broken language like C is perfect for teaching.
  2. Testing and reliability.
  3. Most of the C I've found safe and useful, and how to avoid UB when possible.
  4. Algorithms and how to apply them.
  5. And finally building projects as small challenges to get better at C.

So everyone was right, and I adapted the book to denote that. I also started a project, which hopefully I'll find time to do, that is going to catalog all of the UB in C, write a unit test for each one, and then attempt to assess the security failures of it:

https://github.com/zedshaw/cubfail

I'm currently finishing up a book, but this project interests me because what I've seen is most "professional" C programmers end up pulling out UB whenever they are called out on a secure coding practice they fail at. I think a good catalog of how to cause security failure with C UB would be instructive to everyone.

And then we can all just stop using C. It's terrible.

Now that you have this new information, hopefully you'll update your slander.

[anon1385]

I'm just commenting from the position of an observer who has found that your general attitude undermines the work you do, irrespective of whether you are right or wrong about the issue at hand.

We are all wrong at times. There is no shame in that. But finally admitting fault after months of intransigence (I'm taking about from the launch of the book, when people first started criticising it, until that thread) doesn't excuse your behaviour prior to that. With a bit more humility from the beginning none of this would have happened. If you are going to pick a fight with people, C language lawyers are probably about the worst target.

I don't care about "winning" the argument - just about everybody already agreed that C is highly unsafe, and personally I think K&R is quite outdated now, since it doesn't dwell as much as it should on all the dangerous and difficult aspects of C. Much like C itself, it generally assumes superhuman competence on the part of the reader.

Putting that aside, I do think we are lacking in resources that teach people about the many pitfalls of C in one place (if only to scare people away from the idea of using C for anything network facing). Especially in an era when a lot of people learning C are probably already familiar with the basic syntax and control flow, through knowledge of Java or other languages, and will thus probably be tempted to skim through beginner C books. People coming from that direction probably find C deceptively familiar, and aren't aware of a bunch of things like the undefined behaviour of certain integer overflows and shifts, or the strict aliasing rules, or possibly even reading uninitialized variables.

John Regehr has a lot of good blog posts on this topic:

http://blog.regehr.org/archives/1054

http://blog.regehr.org/archives/1136

http://blog.regehr.org/archives/959

As you can see in some of those examples UB can be very difficult to spot, even for experts like compiler engineers or crypto developers who are intimately familiar with the rules. Also some things are just plain tricky to do correctly and efficiently (e.g. http://blog.regehr.org/archives/1063) and in the past compilers were much less aggressive about optimisations that affected code containing undefined behaviour. So you could get away with it, and incorrect code became the accepted way to do some things. This resulted in a lot of gnashing of teeth and a few well known security vulns when old code started to break with newer compilers.

If you are looking to catch bugs and undefined behaviour in test cases you should certainly look into the -fsanitize options in clang. This post gives an introduction: http://blog.regehr.org/archives/905 and the up to date docs are here: http://clang.llvm.org/docs/UsersManual.html#controlling-code...