Ben,
Let's just hope that the code isn't compiled with -O3 or similar,
creating an unintended bug. :)
http://isc.sans.org/diary.html?storyid=6820
Brings back memories -- the first day on the job as a summer intern I
had to track down a bug in a UNIX device driver. Turned out the
optimizer was clobbering a jump -- the driver worked fine unoptimized.
I quit believing tools like compilers were flaw-free after that!
Most people got it quickly.
Getting it and applying it IRL are of course two completely different
things. I still find it somewhat absurd that we even need to have this
discussion still after how many decades of curriculum development? :)
Oh, I don't -- I think it's all too understandable. A story first, to
provide some background.
One of my grad students (a security type, of course :-)) was my TA for
the undergraduate operating systems class. We had the students form
teams, and each team modified a kernel. The TA then graded
interactively, asking the students about what they did and why, as he
went through their code. My TA was appalled at the poor quality of the
code of most teams -- it worked, but was not robust and was sloppy.
So, he told each group that if they turned in code that poor the next
time, he'd deduct 20% on general principles. So what do students do in
that case? Right -- complain to the professor (me). I said something
to the effect that I strongly disagreed with the TA, and felt he
should have handled the situation differently; but since he said he'd
only take off 20%, instead of the 40% I would have taken off, I'd
support his decision. The students got the message. On the next
assignment (and for the res of the class), the code was much better.
This suggests to me the problem is not so much a failure to teach
robustness; in fact, I suspect most intro to programming teachers do
mention it (although to different degrees of thoroughness and probably
not using that name). The *real* problem is that we don't keep
reinforcing it throughout the student's career.
And that's an artifact of a lack of resources for the type of grading.
Give classes the support to do this, and I suspect you'd see people
get in the habit of writing better code. Better, use students and
people from industry who know this stuff to staff a clinic analogous
to a writing clinic for English and law schools -- that would
reinforce it not just for the students, but for the clinic staff as
well.
Anyone who's interested in this idea can read about a small experiment
I did in a paper at
http://nob.cs.ucdavis.edu/~bishop/papers/2006-cisse-2/
The results of having students use such a clinic, on a very small
scale, led to some pretty good improvements in their code. The
problem, of course, is that supporting such a clinic requires a lot of
people time, and getting people to donate their time, or the resources
(read: cash) to pay for it, isn't easy.
Matt
_______________________________________________
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
_______________________________________________
