This course focuses on several aspects of producing commercial-grade system software: reliability, portability, security, and survivability. We will discuss tools and techniques for producing highly-reliable software, how to port it to various Unix and non-Unix platforms, how to avoid typical security pitfalls when writing software, and how to ensure that your software can continue to run despite some failures. The course will also address how to produce software rapidly and debugging techniques of complex bugs. The course will be taught using C, shell programming, and the M4 macro language. A course project or large assignment would be required.
An important part of the course will be C programming assignments on a variety of different systems. (C is still the most popular language for writing highly portable, optimized, system code.) Emphasis will be given to writing clean, safe, and highly-portable code. You will have a chance to write, compile, run, test, and debug the same source code on several different operating systems. Throughout the course we will learn advanced C programming techniques, advanced debugging tricks, avoiding many C programming pitfalls, and more.
If you follow the lectures, course readings, and homeworks, you will come out of this course with a good understanding of what it takes to write and debug complex C programs on several modern operating systems. You will be improve your skills in debugging complex bugs, and making the most of the C language. You will be a more valuable employee in the software industry and improve your chances of securing a better job.
The course outcomes and catalog description are located in the official CSE-376 course description page.
Unfortunately, the university registration system may not validate prerequisites or enforce registrations based on degree programs or department affiliations. Furthermore, we have limited resources available for this class: seating, teaching staff, and laboratory facilities. Therefore, at my discretion, I will collect information about each student who wants to take this class and correlate it with university records. Then I will decide who can take the class. Note that this is independent of whether you are already registered for the class or not. Priority will be given to CS/IS undergraduate students.
Finally, if you wish to audit this class, speak to the instructor first. If you audit this class, you will not get access to the lab facilities, nor will your assignments and exams be graded
Brian Keringhan and Dennis Ritchie
The C Programming Language (2nd ed., ANSI version)
Prentice-Hall Software Series, June 1988.
Brian Keringhan and Rob Pike
The UNIX Programming Environment
Prentice-Hall Software Series, March 1984.
One additional book I would recommend to the class is a book on GNU Autotools. This would be useful in the latter half of the course, when we discuss these GNU tools.
G. Vaughan, B. Elliston, T. Tromey, and I. L. Taylor
GNU Autoconf, Automake, and Libtool
New Riders, October 2000.
Given that there are no mandatory texts for this class, it is ever more important that you attend all lectures and take good notes.
During the semester I will provide you with various handouts with useful information. These references will be made available via the course home page, at the following URL:
The homework in this course will consist of three types of activities:
Reading from the online manuals, man pages, and existing C sources source code. You obviously won't be graded on this part of the homework, but the exams will contain questions to try to determine whether you have done the reading and integrated the reading material into your own understanding of the subject matter.
Programming Exercises in which you will write new code, use system features, make modifications to a existing software systems to make them build and run cleanly on different systems, and more.
Class Project which will span the latter part of the semester. You can consider it a "large" homework assignment.
Reading will take place on an ongoing basis throughout the semester. Programming assignments will be given regularly, with each assignment due about three weeks after it is issued. There are three programming assignments, plus one project (four programming assignments in total). I feel that actual programming experience is extremely important in the systems area, and so I have assigned a fairly high weight to the programming portion of the grade (see Grading below) to help motivate you.
You may work on the programming assignments only alone! Partnerships of any kind are not be permitted.
You must turn the homeworks in on the day they are due and on the time they are due as listed in the course calendar. Since the homeworks will include programming exercises, students are urged to plan ahead to avoid congestion of the computer facilities at the last minute. If your code is incomplete or is not working by the due date, turn in whatever you have. Any homeworks that are submitted after the due date might or might not be graded, at the convenience of the course staff; if we grade them, we may elect to deduct a number of points for lateness, at our discretion. (Our typical policy is to deduct 2 points for every hour that the assignment is late, rounded up.) Late homeworks that are not graded will be held until the end of the semester, in which case I will have a look at them to decide whether you will be receiving a fair final grade. Generally speaking, if your homework assignment is not graded due to late submission, at my discretion you will receive either a zero for that assignment or you will receive a score equal to the average grade you received on all your homeworks that were graded. If some sort of emergency prevents you from submitting your homework on time, supplying me with suitable documentation might influence the choice I make, but please do not ask me to tell you that it is ``OK'' to submit your homework late. It is never ``OK'' to submit your homework late, but you will benefit more from submitting a late homework than if you submit nothing at all.
For the programming assignments and the project, you will work alone and submit your own work. You may discuss the programming assignments with other classmates. In fact, we encourage participation in the class mailing list. However, you may not share code with anyone! The code you submit must be your own work, and only your own work. Any evidence that source code has been copied, shared, or transmitted in any way between students (this includes using source code written by others in previous semesters, or by persons outside of the class or SUNYSB!) will be regarded as evidence of academic dishonesty. (BTW, there are some wonderful tools out there to compare N programing assignments and correlate those that have a shared code basis, even if the code had been changed significantly!)
I am very serious about not tolerating academic dishonesty. In any class, when I am able to establish that academic dishonesty has occurred, I generally assign the student in question a grade of "F" for the course and forward the particulars to the Graduate Program Director for inclusion in the student's folder. If the student is a repeat offender, I ask that the Graduate Program Director initiate proceedings to dismiss the student from the degree program. Besides, we're here to learn. Do you want to get a good job and impress your peers with your programming skills, or get fired by your boss for failing to get the job (or worse, get sued for copying someone else's work).For more information, see the Academic Judiciary Web site.
The following is an official statement required by the Undergraduate Council to be included in any undergraduate syllabi:
Each student must pursue his or her academic goals honestly and be personally accountable for all submitted work. Representing another person's work as your own is always wrong. Any suspected instance of academic dishonesty will be reported to the Academic Judiciary. For more comprehensive information on academic integrity, including categories of academic dishonesty, please refer to the academic judiciary website at http://www.stonybrook.edu/uaa/academicjudiciary/.
Generally speaking, to get at least a B in this class, your overall numeric grade in this class must be above 75% of the total possible number of points (not counting extra credit). Note that this does not mean that everyone who gets less than 75% will automatically get a grade less than B.
To pass this course, you have to get at least 50% of the total numeric cumulative grade, not counting extra credit. Note that if you get less than 50%, it does not mean an automatic failing grade, but the grade will not be a good one either.
Attendance and participation in classes, in particular, will be factors that can offset borderline grades. This includes conversations with the instructor and TA over email, using the class mailing list, and so on.
So that you can get an idea of how you are doing as the term progresses, I will report rough percentile information when I hand back each assignment. Final percentile scores will not be computed until after all grade changes and corrections have been taken into account at the end of the term.
Grading of Programming Assignments: To help you understand how your programming assignments are graded, we will post a detailed grading criteria for each assignment shortly after the assignment is handed out. This will help you focus your efforts based on what we plan to test and grade, as well as ensure equitable grading.
Re-grading: after each grade is given out, you will have a chance to discuss it with the grader and the instructor. You must first discuss your grade with the grader, within the first 48 hours after the grade has been handed back. It's highly recommended that you take some time to review your entire grade before discussing it with the grader. After discussing your grade with the grader, if you wish, you may discuss it with the instructor during office hours or by appointment.
Extra credit: In some instances I may assign extra questions or problems, designated as "extra credit." These will be optional additional points given to students based on extra credit work performed. Any extra credit points accrued by any student will be used as follows. The final course grade will be assigned as a letter grade which excludes all extra credit points. Then I will apply a subjective method to determine how much value to assign to extra credit points. Extra credit points can only be used to raise your final course letter grade. In other words, you are not obligated to do any of the extra credit work, and you can still get an A in this course.
Graduate Students: Graduate students taking this class (if permitted at all) are required to do more work. Generally the extra work I will assign will be to complete the "extra credit" part of the assignments. Graduate students will be graded separately (different curve) than the undergraduates taking this class.
P/NC: The Pass/No Credit (P/NC) option is not available for this course.
If you have a physical, psychological, medical or learning disability that may impact on your ability to carry out assigned course work, I would urge that you contact the staff in the Disabled Student Services office (DSS), Room 133 Humanities, 632-6748/TDD. DSS will review your concerns and determine, with you, what accommodations are necessary and appropriate. All information and documentation of disability is confidential.
This is an evolving course, and the precise topics that will be covered and how much time will be spent on each are updated annually. The topics and pace also depend on the level of preparation of the students in the class. If nearly everybody has some prior C/Unix experience, then we can pursue more advanced topics at a more rapid rate. If not, then we have to go slower and do more basic things.
The list of topics I expect to cover in class (not in this order) are as follows: