(Please note that access to project related information is
restricted. You should have received a password in your e-mail.)
The first 2 project assignments are considered warm-ups.
The final project assignment is divided in 2 parts.
The warm-up projects must be done individually.
(Although you are encouraged to discuss programming assignments
with other students, when it comes time to code, you must
not look at any shared code and write all your code
on your own.)
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 and copy your e-mail to your
Basically, you have to agree to getting the same score as your
partner no matter what happens.
for Programming Assignments
- 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.)
- 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
- Please also note that regrades can only be done
from the grading account on nunki.usc.edu.
- 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:
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.
- 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.)
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 with the next 24 hours,
you will receive 75% of your grade.
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).
- 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
- 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.
- 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.
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 such as an e-mail
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.
Questions to the Instructor about Projects
[BC: Section added 3/21/2008]
Clarification type questions about the projects are always welcome
But, please do not ask the following types of questions in your e-mail about
projects (although they are appropriate for office hours):
- Here is my understanding of X. Am I right (or is this correct)?
(You can do this for just about everything and in many different ways.
I do not have the bandwidth to deal with too many questions like this.)
The type of questions you should ask is,
"this doesn't make sense to me for the following reasons".
- Here is what I am thinking of or doing... is it acceptable
(or is this okay)?
(What you are really asking is whether you will receive full
credit or not. Wouldn't it be great if you can ask this during
exams? It's not an appropriate question for assignments
for the same reason it is not appropriate for exams. Although
there is a difference between programming assignments and exams,
but since you are asking about grading, it's inappropriate.)
You should try your best and not trying to cut corners!
You should also consult the grading guidelines!
- I don't understand X. Could you explain X to me?
(It's your responsiblity to come to lectures and ask questions
during lectures if there is something you do not understand.)
Modifications after Deadline
You are allowed to submit modifications via
e-mail to the instructor, within 24 hours
of the submission deadline.
One line (128 characters max) of change is defined as
one of the following:
where x is a line number and y is a specified file.
The first 3 lines of modifications are free
of charge. Additional modifications cost 3 points per
line (each project submission is worth 100 points).
- 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.
Segmentation Faults and Bus Errors
I often get questions regarding segmentation faults and bus errors.
Sometimes, these occue when one calls library functions such as
gethostbyname(). Some students think this is some kind of
a networking bug. Well, it's often not. I will try to answer
this type of questions here once and for all.
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:
/* comment out the above line when you are done debugging */
#endif /* 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
I have not tried this library and I do not know if it's
suitable for our projects. But I've heard good things
and bad things about it. Please try it at your own risk.
If you develop your code on a Linux, you can try
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.