CS360 -- Systems Programming

Jian Huang --- Fall, 2022

Teaching Assistants:

Hunter Price, Master's Student (Head TA)
Office Hour Time: Fridays 10:00AM - 11:30AM
Office Hour Location: Minkao 416
Joshua Anantharaj, Undergraduate
Office Hour Time: Thursdays 11:00AM - 12:30PM
Office Hour Location: Minkao 416
Neh Patel, Undergraduate
Office Hour Time: Tuesdays 2:30PM - 4:00PM
Office Hour Location: Minkao 416
Nima Tayefeh, Undergraduate
Office Hour Time: Wednesdays 1:00PM - 2:30AM
Office Hour Location: Minkao 416

FAQ about Labs

Where are lab writeups and due dates?
For all lab writeups and due dates please refer to Dr. Huang's CS360 labs!
Where can I see my grade on a lab?
All lab grades will be posted on Canvas.
How do I submit my lab?
All labs will be submitted via Git repository rather than a submit script. Please see the Git Guide for a walkthrough on using Git. This guide covers pretty much everything in Git, but you really only need chapters 1 & 2 for this class. Dr. Stephen Marz has also written a guide to Git that will cover the things you need for this class.

We will use the EECS-hosted Gitlab instance to host your Git repositories in this class. We also provide a list of steps you can follow each time you need to make a repository for a lab. The only thing you need to do to submit a lab on time is to have it in the corresponding Git repository by 11:59 PM on the due date.

What do I need to do if my lab is going to be late?
If you have to submit a lab late, make sure you follow the procedures for late submissions!
What files should I submit as part of my lab?
Only submit neccesary files as part of your lab. You will lose points if you don't. Be sure to get rid of any .o files, executables, or other non-essential files in your repository. If you don't know if a file should be submitted, ask a TA.

You must also submit a makefile with every lab! It must have a clean function (i.e., typing make clean should result in the removal of any .o files or executables. Please see this Makefile tutorial and Dr. Plank's lecture notes on makefiles. If you need further help writing a makefile, ask a TA.

Lab Grading

Early Submission:
Early submissions grant a 5% bonus per day (max of 15% for 3+ days early) to your grade on that lab. Please note that this is a 5% bonus and not a bonus of 5 points. If you wish to submit your lab early, please email Hunter with the subject line "[COSC360] Early Lab Submission" along with the commit hash of the commit that you want us to consider as your submission. We will consider your submission to be on the day that you email us and not on the day that the commit you specify was made.
Short Code Competion:
If your submission is within the top 30% of students with the fewest lines of code, you will recieve a 10% bonus to your grade on that lab. Keep in mind if you submit your code with all whitespace removed you will be docked on the code quality section of the rubric.
Late Policy:
Late submissions incur a 10% penalty per day. All labs are due by midnight (11:59PM) on the due date. No exceptions can be made, unless an extension was given via the class mailing list or compelling reasons such as significant illness exist.
One-Time Waiver:
Every student is entitled to a waiver of the late submission penalty for one lab assignment. It must be submitted before the final exam. Please use your lab waiver wisely.
Lab Completion:
All lab assignments must be completed to a degree deserving more than 60% credit, be it a late submission or not, for a student to pass this course. If a student fails to meet this requirement by the time the final exam is held, the student automatically fails this course!
Mistakes and Appeals:
If you think a mistake has been made, contact your grader for that lab. Either explain why you think a mistake has been made or arrange a time to meet with them.

All grade appeals must be initiated within ONE WEEK after receiving your lab grade. It is not necessary that the grade appeal be taken care of within that week, but you must have at least contacted your TA and expressed your desire to appeal your grade.


Grading on labs will slightly vary depending on if we test for memory leaks or not in that lab:

Testing for Memory Leaks

  • Gradescripts: 80%
  • Memory Leaks: 10%
  • Code Quality: 10%

Not Testing for Memory Leaks

  • Gradescripts: 80%
  • Code Quality: 20%
You will earn a percentage of the 80 points equal to whatever percent of the gradescripts your code passes.
Memory Leaks
If a successful run of your program leaks any memory, you will lose this full 10%. We say successful because not freeing memory when an error would cause your program to exit isn't a leak, the OS will reclaim it on program exit.
Code Quality
This includes everything covered in the Code Guidelines section below.

Code Guidelines

All lab source code must adhere to the following style guidelines. If it doesn't, points will be deducted or (in extreme cases) that lab submission will not be graded until a clean version is submitted. The late policy still applies if this is the case. Please feel free to see any of the TAs if you have questions or are unsure if your source code is conforming properly.
Use whitespace to make your code easier to understand. We will not grade you on any particular formatting style, but our personal recommendation is a 4-space indent for each nesting level.
Variable Naming
Use descriptive variable names. i, j, and k are ok for iterators, but generally try to avoid 1-letter variable names outside of that. For a general rule: If you get someone else to read your code and they have to figure out or ask what information a variable is representing, you should give it a better name.
Use block level commenting. Your comments should give an overview of your code and provide additional information that is not readily understandable from the code itself. It is not neccessary that you comment every line in your code. When documenting a program, say only what needs to be said without leaving important things out. We should be able to read only your comments and get a general idea of what your code is doing and how it is doing it.
Function Documentation
All functions need to have a header that includes the following information (example below):
  • Function Name
  • A brief description of the what the function is doing
  • Parameter names and brief descriptions
  • Brief descriptions of the return values of the function and when they are returned
/** * @name add_numbers. * @brief Adds two numbers, stores the result in a pointer, and then returns the result as a double. * @param[in] x The first number to add. * @param[in] y The second number to add. * @param[out] z Pointer with result stored. * @return The result of the addition cast to a double. */ double add_numbers(int x, int y, int* z) {     *z = x + y;     return x + y; }
Modularity / Function Decomposition
Most of your COSC360 labs are going to require more lines of code than in previous courses, so it is important to break your code into functions. A function should perform a specific task or a collection of small highly related tasks. Do not stuff all your code into the main function. Doing so will make your code harder to read and debug when you run into a problem.
Error Checking
We expect you to implement robust error checking into every lab. The following things will be checked with our grading scripts.
  • Value of command line arguments
  • Number of command line arguments
  • Return values of system calls
If an error occurs, be sure to output a meaningful error message to stderr and have your program exit gracefully.
Global Variables
Use global variables appropriately and only when neccesary. This means that you should not under any circumstances make all of your variables global. In general, if using a local variable is possible, use it.

Memory Leaks

Good programming is efficient and tidy. Your program should only allocate as much memory as is needed and should free any dynamically allocated memory as soon as it is no longer needed. The best way to accomplish this is to always write the corresponding free code as you are writing the code that allocates. To be able to do this, you must be cognizant of functions that you are using that call malloc. You can test your program for leaks using Valgrind or Address Sanitizer. Both of these tools are extremely useful for tracking down memory errors that lead to segfauls and other strange behavior.
Address Sanitizer

Ed Discussion

You should have recieved an invitation to Ed our discussion platform. Click here to go to the page.