Instructors: Ryan Eberhardt and Armin Namavari
Email: [email protected]
Office hours: TBD
Lectures: Tuesday/Thursday 10:30am-11:20am
Units: 2 units, satisfactory/no credit
This class is focused on safety and robustness in systems programming: Where do things often go wrong in computer systems? How can we avoid common pitfalls? We will use the Rust programming language as a vehicle to teach mental models and paradigms that have been shown to be helpful in preventing errors, and we will look at how these features have made their way back into C++. The first three weeks will focus on preventing many of the types of problems that you encountered in CS 107: how can we prevent buffer overflows, memory leaks, use-after-free bugs, and other sorts of memory errors? Then, we will focus on preventing common mistakes that arise in the programming settings CS 110 covers: how do we write safe code when multiprocessing and multithreading are involved? Check out the syllabus to see an overview of course material.
Outside of lecture, there will be small weekly programming exercises to help you reinforce the material; we expect these will take 1-3 hours to complete. In addition, there will be two projects throughout the quarter that will involve implementing something that you can be proud of. (Tentatively, the first project will involve implementing a simple version of gdb, and the second project will involve implementing a high-performance server.) There are no exams.
This class is designed to be taken along CS 110. If you have taken CS 110 in the past, you may still enroll in CS 110L, but you may need to periodically refresh your memory of CS 110 material. We will draw on some CS 107 material in the first half of the quarter, but it’s okay if you’re a bit rusty. (Can you find two bad puns in that sentence?)
Most of this class will be taught in Rust, and you are not expected to have any prior exposure to Rust. However, we will refer to examples written in C and C++ throughout the class to compare different approaches of solving problems.
This class is graded on a CR/NC basis; you need to earn a 70% to pass. The grade breakdown is:
- Project 1: 30%
- Project 2: 30%
- Weekly exercises: 20%
- Participation: 20%
If you are interested, you may replace any weekly exercise by writing and publishing a blog post about your experience with something in the class. Did you find a feature of Rust particularly hard to wrap your mind around? Was there an idea we talked about that you found especially compelling? We think it would be beneficial for you – and for the world! – if you shared these reflections.
Additionally, you may replace any project with a project of your own that relates more to your background or interests. If you have experience with computer graphics, for example, you might be more interested in implementing a raytracer in Rust. We are happy to suggest project ideas, and can help you through the implementation process. Please let us know before you start if you wish to pursue your own idea.
Late weekly exercises will not be accepted, although you can email us for an extension if something comes up. Late projects will be accepted with a 10% penalty per 24-hour late period, up to three days late.
We want this to be an enjoyable class for you. If you make a reasonable attempt at all the work, you will have no problem passing.
We’re a small class, and part of the fun of taking a small class is getting to know other people. The move to online classes has made this difficult, but we have created a class Slack to restore some of that community aspect. Please email us if you are taking the class and did not receive a Slack invite.
If you would like to follow along on your personal computer, you may install
the Rust toolchain on your computer by following the instructions
here. However, the Rust toolchain is
also installed on
myth.stanford.edu, and you can work on assignments there
just as you do in CS 107 and CS 110. We recommend working on
myth, because it
can be tricky to get tools such as
gdb to run properly on your own computer.
However, you are not required to do so.
Textbooks and Resources
This portion was adopted from the CS 110 course information handout.
The honor code policy for this class is the same as that of CS 110. Although you are encouraged to discuss ideas with others, your work is to be completed independently and should represent fully original work. Whenever you obtain help, you should credit those who helped directly in your program, e.g. in a program comment. Any assistance that is not given proper citation is considered plagiarism, and a violation of the Stanford Honor Code. The following activities are examples of what we consider to be honor code violations:
- Looking at another student’s code.
- Showing another student your code.
- Discussing assignments in such detail that you duplicate a portion of someone else’s code in your own program.
- Uploading your code to a public repository (e.g.
bitbucket.com) so that others can easily discover it via word of mouth or search engines. If you’d like to upload your code to a private repository, you can do so on Github or some other hosting service that provides free-of-charge private hosting.
Unfortunately, the CS department sees more than its fair share of Honor Code violations. Because it’s important that all cases of academic dishonesty be identified for the sake of those playing by the rules, we exercise our right to use software tools to compare your submissions against those of other students.