Author: Stan Eisenstat
Subject: Debugging and Office Hours
Date: Tuesday, 11 Feb 2020, 13:27:58

SHORT VERSION
Please do not expect the staff to debug your program
for you; that is your responsibility.

LONG VERSION
One measure of programming proficiency is one's ability
to debug one's own programs.  Thus one goal in 223 is to
improve your debugging skills and thereby make the
process less frustrating.

Ideally at this point you should have learned how to

* understand most error messages from gcc, and modify
  your code to eliminate them;

* identify where your program produces invalid output,
  causes a segmentation fault, or goes into an infinite
  loop; and

* use print statements or gdb to trace the flow of
  execution back to the source of the problem (this is
  the point of origin) and fix it.

To offer assistance, the staff hold office hours to

* answer questions about

  + material covered in lecture and the readings,
   
  + C syntax and the use of library functions,

  + the Zoo programming environment (incuding make, gcc,
    and gdb), and

  + what the specification of each assignment requires;
   
* critique your plans for writing a program that meets
  the requirements and your programming style; and

* offer suggestions that will help you to debug your
  program, such as

  + where the error is likely to be,

  + what extra information to print to find that error
    (e.g., the bin to which each item is assigned), and

  + the use of scaffolding code to print data structures
    in a human-readable form (e.g., the arguments to the
    function that implements -opt).

However, they are not there to

* write your program for you;

* tell you how to write your program, other than the
  general overviews of the specification offered during
  walk-throughs; or

* debug your program, other than by asking YOU questions
  that will help you to identify the problem.

Please do not expect them to do so.

Thanks for your cooperation.

--Stan-