On Wed, 27 Apr 2016, Toby Thain wrote: > Modern languages can indeed wipe out large classes of bugs (including > many of those that lead to vulnerabilities). But *every* advance in > abstraction does.
While I follow your thesis here, I would also point out that the reason that a lot of C programmers roll their eyes when folks start talking about abstraction is that generally increases code size and overhead. Those two mandates (get out of my way, but don't let me make mistakes) are tough to achieve at the same time. People want the features they find in scripting languages (no memory management, no hassling with pointers) but they don't want to pay for them. It's a matter of debate among experts as to how much fat abstraction adds, or the value of the abstraction itself but it's the primary reason why many C coders are dubious of too much abstraction. C, in my opinion balances the two in one of the least-ugly ways (not that it's all that glamorous, it just works). Those on the "maximum abstraction" bus have already arrived at their stop in C++ land or have moved on to RubyTown etc... (not slamming them, just saying - I do C++ too). I stick with C because I don't want (much) more abstraction than it offers for the applications I write or maintain. > I like Professor Benjamin Pierce's way of putting it: "Mechanical checks > of simple properties enormously improve software quality." Well, I definitely agree with this in general. The question again is how much are you willing to spend to get them done? There is always the guy who will say "Oh gawd we have 6Ghz machines with 4TB of RAM now. Who cares." That will always be followed by the person who says "Wait, I still do embedded code on a Z80 with 4k of RAM!" One thing that I'd point out about C is that once you learn it, you can do both (some would say poorly, but not me). > The virulence, level, and number, change. Just think of the change in > the nature and frequency of mechanically missed bugs going between: > assembler to C; C to Java; Java to Haskell; etc. True. However, when I look at http://benchmarksgame.alioth.debian.org/ and other such comparisons, and compare those languages doing real work I can see what the cost is to do so. Maybe some would assert that all this safety can come for free. My response to that would be "Excellent. Please write us all a new compiler, then." For the record, I do know about things like gcc-ssp, propolice, stackguard, etc.. I've used most of those where needed. > I'd rather be dealing with only the bugs that get through that sieve, > than deal with malloc/free bullshit or buffer overflows in C. I write quite a bit of C. I don't claim for a second to be "good" ('cause I've met people who are *really* good). In my experience there are several things that you can bring to bear which will result in you hardly every chasing pointers or malloc() issues. Here's what I do to help myself (BTW, I'm sure you are all better coders. I'm just sharing my experience): 1. Early on I wrote myself a reference counter. There are all kinds of easy ways to do this. Then you can catch yourself when you use a null reference or let a loop run off the edge of a cliff. Once you feel comfy, remove the #include'd wrappers. I've done the same thing using LD_PRELOAD mechanisms to preempt things like malloc(). 2. When in doubt I've used tools like ElectricFence and Valgrind to also aid greatly in finding problems that might lead to buffer overflows or string format exploits. I also use tools like "rats" to hunt down bugs. 3. I started getting burned enough that I simply figured out what kind of design patterns I was using that got me into trouble. Once I applied myself to stopping that behavior, the issues I was having with memory shell games basically went away. 4. Kind of along with the philosophy you are talking about (perhaps) I do check the livin' snot out of everything I get back from non-deterministic operations. Some of these are just using my knowledge of the code's actual logic path to do the checks at the *exact* spot they are needed without some compiler trying to out-guess me or check absolutely everything. YMMV, but that's how I live with my dirty C programming self. :-) > Productivity, security, reliability, correctness all demand that we wipe > out as many tiers of bug as we can, with better/more high level tools... > imho of course... That's what I hear from folks who love Haskell and Erlang. As I'm sure you know, those languages have some really interesting properties similar to the kind of philosophy. You guys are going to be the type of people who move the whole industry forward as you push innovative (or maybe old & innovative) ideas. Guys like me just try to get the code done as fast as possible before our jobs get offshored to India. :-/ -Swift
