Project Assignments -

The first 2 project assignments are considered warm-ups. The final project assignment is divided in 2 parts.

• Warm-up project #1, due 11:45PM, . 10% of total project grade. Electronic submissions only.
• Warm-up project #2, due 11:45PM, . 10% of total project grade. Electronic submissions only.
• Final project, part (1) due 11:45PM, . 45% of total project grade. Electronic submissions only.
• Final project, part (2) due 11:45PM, . 35% of total project grade. Electronic submissions only.

Group projects (group of two students) are allowed for both parts of the final project if each group members e-mails a commitment form (please modify with your information) to the instructor. Basically, you have to agree to getting the same score as your partner no matter what happens.

1. The class project will be C/C++ code to be developed on a UNIX environment. No other programming language will be accepted and your program must compile and run with a Makefile as is on a nunki.usc.edu. You must be familiar with the UNIX development environment (vi/pico/emacs, cc/gcc or g++/cxx, make, etc.)

2. You should use your USC accounts and preferably work on the Solaris machines in the ISD computer rooms for testing. The final (submitted) program must run on nunki.usc.edu because we are going to test it in that environment. Please note that we can only grade your submission from the grading account on nunki.usc.edu. It would be a good idea to test your program in another student's account to make sure that it runs everywhere. By the way, you should not do the whole program development there, as nunki is a general purpose server - under heavy use by many students. But you should definitely test your program there.

3. [BC: Paragraph added 11/15/2007]
   Please also note that regrades can only be done from the grading account on nunki.usc.edu.

4. [BC: Paragraphs added 11/30/2007]
   Please do not hardcode any directory path in your code! If you hardcode something like "/home/scf-..." or "/auto/home/scf-..." in your code to access something in your home directory and the grader cannot access these directories during grading, we will not be able to make changes to the overall filesystem on nunki. You may only get a score of 1 point as a result of this. So, please make sure you are not doing this. All path should be specified externally, as far as your code is concerned.

   The only path that you can hardcode is probably "/tmp", and even that is not a great idea. What you can do is to define such a path as a compile time variable and pass it to your program. For example, you can use the following to define TMPDIR to be equal to "/tmp":

       gcc ... -DTMPDIR=\"/tmp\" ...

   Then in your code, you can do:

       char tmpfile[256];
   
       snprintf(tmpfile, sizeof(tmpfile), "%s/XXXXXX", TMPDIR);
       ... mkstemp(tmpfile) ...

   Basically, using a compile time variable is the same as doing the following in your code:

       #define TMPDIR "/tmp"

   The difference is that you are doing it outside of your code, and this is cleaner.

5. We will make grading guidelines available at least one week before an assignment is due. We will grade based on the grading guidelines (may be with minor adjustments). Since you know exactly how we are going to grade, the grading will be harsh. Also, you do not get credit for coding. You only get credit for getting your code to work correctly according to the spec. (Please do not ask the grader to look at your code so you can get more points because you have done a lot of coding and your code looks like it should work.)

6. Late submissions will receive severe penalties. Due to clock skews, electronic submissions of projects and homeworks assignments will be accepted within 15 minutes after the specified deadlines without penalties. If you submit within the next 24 hours, you will receive 75% of your grade. [BC: Changed 10/10/2007] Although in the first 50 minutes of this period, you will only lose 1% of your grade every 2 minutes. You will receive a score of zero after the first 24 hours (and your assignment will not be graded).

7. All submissions will be timestamped by the submission server and receipts (known as tickets) will be issued. Whether your submission arrived to the server by the deadline is determined by the timestamp. Please keep your receipts/tickets.

8. If you signs up late for this class, you are still required to turn in the warm-up projects on time or you will receive a score of zero for the applicable assignments. No exceptions! This requirement also applys to students on the wait list.

9. You must follow the Electronic Submission Guidelines when you submit project assignments. Please note that this is a brand new procedure and very different from previous procedures. [BC: Added 10/2/2007] Please make sure you read the output of the bsubmit program carefully. It should look similar to the sample output given on the bsubmit page. The timestamped upload ticket issued by the Bistro server is a proof that the server has received your submission (and you do not need additional proof). You should also verify what you have submitted is what you intended to submit by following the Verify Your Submission procedure. Please note that it is your responsibility to ensure that you have submitted valid submissions and that you have received timestampted upload tickets for them.

One line (128 characters max) of change is defined as one of the following:

• Add 1 line before (or after) line x of file y
• Delete line x of file y
• Replace line x of file y by 1 line

Afterwards, additional modifications cost 12 points per line until 7 days past the submission deadline. After 7 days past the submission deadline, an additional modification costs 30 points per line.

Please note that this applies to source code, Makefile, and README files.

Chances are that you have corrupted memory. This usually means that you have corrupted memory a while back. It just happened that when you call gethostbyname(), the corrupted memory caused a bus error or the execution of an illegal instruction. Bus errors and illegal instructions are basically the same thing as segmentation faults.

How does one corrupt memory? You can write beyond an allocated memory block. You can free the same object twice. You can free an object that was not allocated. You can write to an object that's already freed. These bugs are hard to find because most of the them you only see that there is problem long time after you have corrupted memory. If you have access to a professional/expensive debugging tool, it may be helpful. Otherwise, you just need to do binary search and see where the bug(s) might be. There's no magical cures in debugging memory corruption bugs.

One thing you might try is to temporarily turn off memory deallocation (if you suspect that you have freed the same object twice or freed an object that was not allocated). You can do the following to define free() as a no-op in a common header file when you are debugging:

    #define DEBUGGING_MEMORY_CORRUPTION
    /* comment out the above line when you are done debugging */
    #ifdef DEBUGGING_MEMORY_CORRUPTION
    #ifdef free
    #undef free
    #endif /* free */
    #define free
    #endif /* DEBUGGING_MEMORY_CORRUPTION */

As your code gets more and more complicated, and you are not very careful in managing your resources, you may get more of these. This is one reason why you want to keep your code nice and clean.

On nunki, you can try efence. There is a copy installed in:

    ~csci551b/public/efence/2.2/ElectricFence-2.2.2-15

    ~csci551b/public/efence/2.2/README-solaris

If you develop your code on a Linux, you can try valgrind. I have not tried this tool and I do not know if it's suitable for our programming assignments. But I've heard good things (e.g., easy to use) and bad things about it (e.g., it only runs on Linux). Please try it at your own risk.

Also, if you want to try these, incorporate them in your programs as early as possible. Don't start learning it when bugs are happening and deadlines are approaching.