[FrontPage] [TitleIndex] [WordIndex

Note: You are looking at a static copy of the former PineWiki site, used for class notes by James Aspnes from 2003 to 2012. Many mathematical formulas are broken, and there are likely to be other bugs as well. These will most likely not be fixed. You may be able to find more up-to-date versions of some of these notes at http://www.cs.yale.edu/homes/aspnes/#classes.

Here are some notes from a helpful Zoo denizen about debugging programs in 223. (Note: these have been edited slightly from the original.)

Date: Thu, 10 Feb 2005 06:02:23 -0500 (EST)
From: James Terry <james.c.terry@yale.edu>
Subject: 223 coding feedback

Hi Jim,

Several of your students for 223 were up late last night in the Zoo
working on their assignments, and they seemed to be getting hung up on
some coding issues.  They were pretty frustrated with some standard
language/debugging issues, so I helped them get the type-checker and
Valgrind to stop yelling at them.  I noticed some recurring problems and I
thought I'd pass them on to you.  They're pretty standard mistakes, and
I've made most of them myself at some point, either in your class or in
Stan's.  It occurred to me that there might be more confused people than
were around last night, and they'd probably appreciate it if someone told
them about these sort of things.  I'm not trying to intrude on how you
teach the class; I just thought this feedback would be helpful and I
wasn't sure that it would find its way to you otherwise.  I'm sure you've
already taught them several of these, and I understand that sometimes
students just don't pay attention.  Still, these seem like good points to
hammer down:

Recurring debugging/coding problems:

1.  If you want a debugger/Valgrind to give you line numbers, you must 
compile with debugging info turned on, i. e. using the -g[level] flag.
2.  On the Zoo, pointers and int's are 4 bytes; char's are 1.  (Some 
people didn't seem to realize that a char* is 4 bytes rather than 1.)
3.  I think it would be helpful if you explained why, when using 
realloc(), it's a good idea to increase the allocated size 
multiplicatively rather than additively.  Besides, everyone loves the 
"tearing down the hotel" metaphor.  :) 
4.  If they use call-by-reference, they had better make sure that they 
keep the same reference.  So if they pass in a pointer as an argument to a 
function, they shouldn't call malloc() or realloc() on that function.  
(Mention the double pointer as another option.)  Most people will make 
this mistake eventually if no one warns them about it.  When I was 
learning C, I sort of viewed malloc() and realloc() as magical 
memory-increasing functions; that is to say, I didn't think very hard 
about the meaning of assigning a pointer to malloc()'s return value.  I 
suspect some of your students would benefit from having the details 
spelled out.  (Or spelled out again, if you've already done that.)  
5.  It's possible to get through a lot (but not all) of the CS major 
without learning basic Unix shell syntax, but that's really just wasted 
time.  Pipes, backgrounding, man, scp, and grep really help even at the 
intro level.  I realize the purpose of the class isn't to teach Unix, but 
in past years I think there was a TA help session on these things.  They 
don't need to know how to write their own Emacs modes, but the basics 
would definitely be helpful.  
6.  malloc/free -- If Valgrind/gdb reports a problem inside of malloc() or 
free(), chances are that the student has *not* discovered a bug in gcc.  
(I just heard how one of Zhong's students' proved the correctness of the 
libraries for his thesis; that's pretty cool.)  Explain why you can't 
malloc() twice on the same pointer.  Explain how with multidimensional 
pointers, you must malloc/free each dimension separately.  Drill down the 
one-to-one correspondence between malloc'ing and free'ing.
7.  Null characters: It's not obvious to newbies that some library functions 
require them, particularly null-terminated strings.  Tell them that 
char*'s must be null terminated in order for <string.h> 
functions to work.
8.  Off-by-one errors: Tell people that when all else fails, take a hard 
look at their comparison operators; i. e. make sure that > shouldn't 
really be a >=.
9.  This is probably another thing for a help session or workshop, but I 
feel almost everyone could benefit from basic software engineering 
methodology.  Stylistic awkwardness I noticed: 
        --Using a mess of if-then-else's instead of nested control 
        --Using while-loops with iterators that get initialized right 
before the beginning of the loop and get incremented with each iteration, 
when they could be using for-loops.  
        --Doing the setup work for a loop right before the beginning of 
the loop and then at the end of every iteration, instead of at the 
beginning of every iteration.  Conversely: doing the cleanup work at the 
beginning of every iteration and then after the loop has completed.
10.  Tell them to use assert().  (Frequently.)  When you cover binary 
search, using placement of debugging statements in code in order to pin 
down an error might be an instructive example.  
11.  Tell them to use either printf statements or a debugger to debug. I 
think they can figure out how to do this on their own, they just need to 
be told it's a good idea.

Hopefully some of these suggestions will be helpful.  I won't be offended 
if you don't pass them on to your students, and I understand if you put a 
higher teaching priority on non-coding subjects, but all the things I 
mentioned were things I wish someone had told me.  I'd be happy to run a 
help session on this stuff if you and the TAs are too busy, but otherwise 
I wouldn't presume.  



2014-06-17 11:58