PREV INDEX NEXT

Author: Stan Eisenstat
Subject: Debugging and Office Hours
Date: Friday, 04 Sep 2020, 15:01:00


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 323 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 gdb or print statements 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 full
    name of the current file), and

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

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-
PREV INDEX NEXT