CSE 303: Concepts and Tools for Software Development, Winter 2008
  CSE Home   About Us   Search   Contact Info 
 
Course Home
 Home
Administation
 Overview
 Course Wiki
 Email archive
 Anonymous feedback
 View feedback
 Homework Turnin
 
Most Everything
 Schedule
 
Other Information
 UW/ACM Tutorials
 303 Computing: Getting Started
   

CSE 303 (Optional) Homework 6

Due: Tuesday, 2/19/08
Turnin: None (optional exercises).

FAQ

  • HW6 Q&A Wiki Page
  • Overview

    The idea of this exercise is to get a little more practice with C programming, and to get enough exposure to gdb, the (or, rather, "a") debugger to see what it can do for you.

    Exercise 1. The Debugger: gdb

    We're going to use gdb to monitor the execution of a C program:
    attu:/cse/courses/cse303/08wi/hw6Dist.tar.gz
    The program solves Soduko puzzles.
    1. To compile: gcc -g -Wall -o sudoku *.c. The '-g' switch causes the compiler to put information into the executable that is needed by the debugger. If you forget to use that switch, the debugger is almost useless.
    2. To run without the debugger: ./sudoku puzzle.txt. That will seg fault.
    3. To use the debugger to help find the seg fault, first start gdb: gdb soduko.
    4. To run the program from inside gdb: run puzzle.txt.
    5. When it segfaults, the command bt will show you where it is.
    6. The command p [variable name] will display the value of a variable. (If you want to see it in decimal, p/d [variable name].) For example, p message.
    7. To start the program over, just issue the run command again.
    8. To set a breakpoint at entry to main, do this: b main.
    9. To execute one line of your C program, use either s (step) or n (next). The difference between them has to do with how method invocations are handled. Step will step into the method -- execution will stop at a the first line of the invoked method. Next will step over the method -- execution will stop at the source line following the method invocation.
    10. Command c (continue) resumes execution.
    11. Once you've found and fixed the seg fault issue, you'll notice that the program doesn't actually work - it always reports that there is no solution. (In fact, there is at least one solution to the board described by file puzzle.txt.)
    12. At this point, the problem is to figure out what is wrong.
    13. I suggest beginning by having a look at the code in solve.c.
    14. I'd then do a b doSolve and then some step/next to try to see what the problem might be.

    Other resources:

    • An alternative set of exercises from an earlier version of this course.
    • A full-blown gdb manual.
    • Integration of gdb with emacs is possible. The main advantage is more convenient setting of breakpoints, and more natural feedback when stepping through execution.

    Exercise 2. A Tiny Bit of C Programming

    The idea of this part is to implement and debug the code answering the final question from the midterm. Rather than doing that literally, we'll just use that question as the basis for a bit of programming exercise. What follows is a slightly modified form of that question. This is an exercise, though, and so you should feel free to (and should) invent your own variations.

    The program takes a single argument, the name of a file containing an unknown number of lines of grade data for one student. The program is invoked like this:

    $ ./a.out gradeFile
    Each line in the file has three fields, two giving the course and one the grade. A sample input line is
    CSE 303 4.0
    Once the file has been read, the program sits in a loop reading "commands" from stdin. The two commands it knows about have these forms:
    • d [dept] asks for the average GPA of all courses taken in "dept." Example command: d PHYS.
    • lt [grade] asks to list all courses in which the grade was less than "grade." Example command: lt 3.0

    The program has two logical phases. In the first, the data is read from a file into a data structure your program can get at conveniently. In the second, each command causes the program to traverse the now stored data, extract some relevant portion and perhaps compute some result from what was extracted, and print something.

    It might be surprising, but I think you can get a lot of useful experience out of doing this, even though this genre of problem is by now undoubtedly so repetitious that you can hardly stand to think about it. What would be especially useful would be to implement code for the basic problem (above), and now think of little things to add to the problem defintion that aren't just trivial copy-paste-edit's of what you already have.

    As an example, I'll offer one idea: each line in the file has not only the three fields mentioned above, but also the quarter and year, so that the full line would have this form:

    CSE 303 4.0 Autumn 2007
    Now add some command that let's the user list/compute by year. (Once that's done, let them compute by year-interval -- from 2006 to 2008, for example.) Etc.

    The point of this example is that it is minor, in the sense of not making any wholesale change to the intent of the program, but isn't just more of the same: the "input field" is now two fields, according to how scanf() works, and (more importantly) not all commands are now two tokens long. (Another example: extend the 'd' command to allow listing any number of departments, and print the average GPA in all courses in any of the listed departments.)

    Attempting to make changes to an existing program will help you appreciate the distinction between "clean" code, at one extreme, and a mess, at the other.

    This might seem tedious, but one way or another you're going to go through this process. I think exercises now will be a lot more pleasant, on the whole, than trying to go through it as part of completing the sequence of assignments that lies ahead (in other CSE courses, I mean - the CSE 303 assignments will all be a joy, of course).

    Getting Help

    There is a Wiki page, as always. You are also encouraged to communicate with the course staff.

    Computer Science & Engineering
    University of Washington
    Box 352350
    Seattle, WA  98195-2350
    (206) 543-1695 voice, (206) 543-2969 FAX
    [comments to zahorjan at cs.washington.edu]