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