<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Apr 21, 2014 at 12:41 PM, Bill Frantz <span dir="ltr"><<a href="mailto:frantz@pwpconsult.com" target="_blank">frantz@pwpconsult.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On 4/21/14 at 6:05 AM, <a href="mailto:pgut001@cs.auckland.ac.nz" target="_blank">pgut001@cs.auckland.ac.nz</a> (Peter Gutmann) wrote:<br>

<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Sorry, nonstandard terminology, I meant constantly auditing your own code,<br>
which in both Wietse's case and mine means taking printouts of code modules<br>
home to read offline at your own pace to check for problems.  That's not just<br>
code you've recently been working on, but selections of older code modules<br>
that you're re-checking in case you see something that didn't pop out the last<br>
time you checked.<br>
</blockquote>
<br></div>
Two things I have found useful in this kind of effort:<br>
<br>
Carefully compare the code with the comments. SInce most of my professional career was writing in assembler, I tended to comment each instruction with a reason for its existence. I frequently found bugs where the comment said one thing and the code something slightly different. Only one time did they seem different, but weren't. That time produced even more comments as to why the comment and the code were both correct. In a sense, my code included an informal proof of correctness in the comments.<br>

<br>
Use an automatic formater to reformat your code for review. (Keep the original format for your source code control system. People make more readable formatting than machines.) Seeing the same code from a different point of view can overcome personal blind spots.</blockquote>
<div><br></div><div>I think that printing the code out as hardcopy is valuable for the "different point of view" aspect of the exercise. I've also found that useful when maintaining large and/or old codebases ("add this feature to this 10 million line/10 year old system"). You can go nuts with a highlighter marking up all of the places a variable that contains externally provided data/state and lay out a LOT of pages to look at them at once. You just aren't going to get as much code displayed at once on monitors as you are on pages spread out on tables. Doing a review like that for commits to openssl would have followed the "payload length" parameter in Heartbleed all the way through and brought it to attention.</div>
<div><br></div><div>-David Mercer </div><div><br></div></div></div></div>