CS 262 Intro. to Low-level Programming
Spring, 2018

Section -001    Class Day/Time:  MW 9:00-10:15 a.m.      Class Location: Lecture Hall 2
Section -002    Class Day/Time:  TR 12:00-1:15 p.m.        Class Location: Art & Design 2003
Section -004    Class Day/Time:  MW 1:30-2:45 p.m.        Class Location: Merten Hall 1200
Instructor: Prof. John Otten
Email address:  jotten2@gmu.edu
Office Location: ENGR, Room 5335;
Office Phone: 703-993-1669
Office Hours: Tuesdays and Thursdays 1:30-3:00 p.m., or by appointment

Graduate Teaching Assistants:
                Section 001 - Divya Vajja - dvajja@gmu.edu
                Section 002 - Yimeng Li - yli44@gmu.edu
                Section 004 - Wanwan Li - wli17@gmu.edu

Undergraduate Teaching Assistants:
William Tiffany - wtiffany@masonlive.gmu.edu
Oleg Menyaylenko- omenyayl@masonlive.gmu.edu
Adrian Calciu - acalciu@masonlive.gmu.edu
Shane Polisar - spolisar@masonlive.gmu.edu
Stephen Hull - shull4@masonlive.gmu.edu

Textbook: Kernighan and Ritchie, The C Programming Language, 2nd ed., Prentice Hall, 1988

Class Description:  Most high-level programming languages (and particularly Java) insulate the programmer from the realities of the hardware on which the programs will run. C is the exception since it was originally designed to implement the Unix operating system. C offers the programmer direct access to much of the underlying hardware and, for programs running under Unix, direct access to operating system services. For these reasons C remains the language of choice for systems programming.

Prerequisite: C or better in CS 211 or CS 222.

Course Topics:  This is a course on "low-level" programming using C. We will learn C with heavy emphasis on pointer operations.

Planned schedule of topics (In no particular order. May change without warning.): Course outcomes:

1.    Be able to implement, test and debug a designed solution to a problem in a low-level programming language, specifically the C programming language.
2.    Demonstrate a good understanding of C language constructs such as pointers, dynamic memory management, and address arithmetic.
3.    Demonstrate a good understanding of C libraries for input and output, and the interface between C programs and the UNIX operating system.
4.    Demonstrate an ability to use UNIX tools for program development and debugging.

Grading:  In addition to the labs and projects there will be a midterm exam and a final. There will be no makeups on exams except under exceptional circumstances (as judged by me), and any such makeup must be arranged in advanced. Grades will be computed using a weighted average of these scores with the weights:
In addition, to get a passing grade in the course your average grade for the two exams must be at least 60% AND you must submit all projects and labs.

Labs:  Attendance at labs is required. A short programming assignment will be given at the beginning of each lab.  The lab instructor and one or more UTAs will be available to help students with the assignment. If not completed, the lab may be taken home. Lab assignments will be due either at the designated time for submission on Blackboard or, if no due date is given on Blackboard, at the beginning of the following lab period. Late lab assignments will automatically be assessed a 50% penalty. All labs must be submitted for a passing grade in the course.

Attendance: Attendance at both class lectures and labs is required.  Exams will stress material covered in class and lab sessions.

Projects:  In addition to the labs there will be several larger programming projects.  Programming assignments will be posted on Blackboard as they are assigned and must be submitted on Blackboard by the assigned due date.  If your program is incomplete, you may still submit it for partial credit.  However, your code must run without obvious errors (even if all functionality is not present).  Building your programs in a modular fashion and debugging as you go are crucial concepts in program development.  Additionally, your TA relies on running your program as part of your grade determination.  Accordingly, any programming assignment that is submitted but does not compile will receive no more than 25% credit. A programming assignment submission that has major errors when it is run (such as segmentation faults) will receive no more than 50% credit.  All projects must be submitted for a passing grade in the course.

Late Projects: Late projects will be penalized 10 points per day (incl. weekend days/holidays) for the first five days past the due date. After that time, late projects will be penalized 5 points per day for the next five days. The maximum late penalty will be 75 points. You should recognize that late work can cause major penalties, so start work early! If your program isn't the way you'd like it to be when the deadline is near, submit it anyway for partial credit. In fact, submit early and often! The system permits you to retrieve and resubmit your assignment until the due date, so you may resubmit if you improve your program prior to the deadline.   Resubmissions after the deadline require approval of your TA (s/he may already have graded your project). If you know that you wish to resubmit a new version after the deadline, it is your responsibility to notify your TA no later than the time of the deadline, so s/he will not grade the on-time submission. No resubmissions may be made after a project has been graded.

Class Communications:  CS 262 will be using Piazza and Blackboard for most class communications. You are responsible for any notifications or information posted on Blackboard/Piazza either by your instructor, your GTA or the class UTA(s), and you will need to check the systems regularly for such notices. Some information may be disseminated through these systems rather than in class. Individual communications with the professor/GTA/UTA may be done by email using your GMU email account. When you email, please be sure to include your name, the class number and the topic in the subject header. (E.g.: Subject: Jim Jones / CS 262-003 / Project 2)

Special Accommodations: If you are a student with a disability, please see your instructor and contact the Office of Disability Services (ODS) at (703) 993-2474. All academic accommodations must be arranged through the ODS: http://ods.gmu.edu

Honor Code Policies: All students are expected to abide by the GMU Honor Code. This policy is rigorously enforced. All class-related assignments are considered individual efforts unless explicitly expressed otherwise (in writing). Review the university honor code and present any questions regarding the policies to instructor.

Cheating on any assignment will be prosecuted and result in a notification of the Honor Committee as outlined in the GMU Honor Code. Sharing, collaboration, or looking at any code related to programming assignments that is not your own is considered cheating. See Programming Polices below.

The computer science department has an additional, more restrictive CS Honor Code that you are also subject to. Make sure you read and familiarize yourself with these rules.


(1) No sharing or discussion of code. Unless specifically stated otherwise, all assignments are individual projects, not group projects. Students are expected to do their own work, not to share programs with each other, nor copy programs from anyone else. This means you may not discuss program design or solution strategies with anyone except your instructor or a CS262 GTA/UTA. However, you may offer more limited assistance to your fellow students regarding specific questions on their programming assignments by responding to queries on Blackboard. Any sharing of code or discussion of programming projects, except within the parameters of Blackboard, constitutes an honor code violation. Suspected honor code violations are taken very seriously, and will be reported to the Honor Committee. Read the  GMU Honor Code and CS Department Honor Code. You are bound by these codes.

(2) No incorporation of code from any source external to the course. You may not incorporate code written by others, such as code found on the Internet or any of the numerous CS books available. You may freely use any code provided as part of the project specifications, without any need for crediting the source. However, if you use code provided by your instructor or GTA (other than that given as part of the project specifications) or from the course textbook, you must document what portion came from those sources.

(3) Blackboard/Piazza. We encourage the use of Blackboard and/or Piazza to discuss assignments and assist one another with programming questions. You may ask questions or respond to queries on BB/Piazza regarding projects or other assignments, so long as you do not post any C code or detailed pseudocode, and so long as you do not provide specific solutions to the overall problem or algorithm design (even in English). Often, students believe that "simple" code is acceptable to place on Blackboard/Piazza. However, because there is a wide variation in what different students and instructors regard as "simple," we must be very strict about the ban against Blackboard/Piazza code. Only an instructor, GTA or UTA is permitted to place code on blackboard unless it is code that has already been provided to all students (either as part of the assignment specification itself or within the class textbook).

(4) Discussing Blackboard/Piazza postings outside of Blackboard/Piazza. Please note that Blackboard or Piazza assistance must remain on the forum. "Summarizing" Blackboard/Piazza statements or responses to another student verbally regarding an assignment is not acceptable, and is subject to the above ban on discussing assignment solutions. While it may seem harmless, Blackboard/Piazza was set up so that all assistance could be overseen by instructors/TAs/UTAs, and it is nearly impossible to truly duplicate Blackboard/Piazza discussion outside of the actual forum, thus creating the potential for either (unknowing) mistaken advice, or for unfair advantage by certain students. If you truly wish to assist a fellow student, encourage him or her to log onto Blackboard/Piazza, and direct him/her to specific postings you find helpful.

(5) Back up your program regularly. You are expected to back up your program in separate files as you get different pieces working. Failure to do this may result in your getting a much lower grade on a program if last minute problems occur. (Accidentally deleting your program, having problems connecting, etc., will not be accepted as excuses.)

(6) Keep an untouched copy of your final code submission. It is important that you not touch your programs once you have made your final submission. If there are any submission problems, consideration for credit will only be given if it can be verified that the program files were not changed after being submitted.

(7) Code must run on Zeus using gcc. Students may develop programs using any computer system they have available. Please note, however, that submitted projects must run under the gcc compiler (using all specified compiler options) available on Zeus. Your documentation should clearly state which software was used for compilation, and once makefiles are introduced, a makefile should be included with each assignment submission. No extensions will be given due to compiler incompatibilities.