$ ssh cse29.ucsd.edu
Password:

   ___________ ______ ___   ____
  / ____/ ___// ____/|__ \ / __ \
 / /    \__ \/ __/   __/ // /_/ /
/ /___ ___/ / /___  / __/ \__, /
\____//____/_____/ /____//____/

$ ./letsgo
Initalizating I/O...
Making Memories...
Setting up HTTP server...
Checking password hashes....
Reticulating splines...

UCSD CSE29 FA26 Syllabus and Logistics

Aaron Schulman (Shalev) (Instructor)

CSE 29 introduces you to the broad field of systems programming, including 1) the basics of how programs execute on a computer, 2) programming in C with direct access to memory and system calls, 3) software tools to manage and interact with code and programs. All very cool stuff that makes every programmer better!

Basics

• Lecture:
  • Mon/Wed/Fri 3:00-3:50pm, Warren Lecture Hall 2001
• Discussion:
  • Wednesday 6:00-6:50pm, Galbraith Hall 242
• Labs: Tuesdays (check your schedule!). Either B240 or B250 in the CSE building
• Exams:
  • Weeks 4, 8, and 10: During your regularly-scheduled lab time
  • Finals week: In CSE labs, scheduling instructions coming soon!
• Professor office hours (these are the standard times but check the calendar below for changes!)
  • Wednesday 1:00-2:00pm CSE B270/tables outside labs (CSE29 students only)
  • Thursday 2:30-3:30pm, CSE 3206 (advising focused, open to all students)
• Office Hours: Refer to calendar
• Q&A forum: Piazza
• PrairieLearn: https://us.prairielearn.com
• Textbook/readings: Dive Into Systems, plus additional readings we will assign
  • Free: MIT Missing Semester
  • Not free but pretty cheap: Julia Evans Zines, especially The Pocket Guide to Debugging
• Reference Sheets: Google Doc
• Lecture Review Template (for late submissions): Review Template

Office Hours Calendar

Schedule

• Week 0 – Welcome, Strings and Bitwise Representations

  • Lecture Materials
    • Friday
      • Lecture
      • Code: bits.c, hello.c

• Week 1 – Binary, Printing, and Strings

  • Lecture Materials
    • Monday
      • Lecture
      • Code: print.c hello.c, out_of_bounds.c
    • Wednesday
      • Lecture
      • Code: inspect.c
      • Discussion
    • Friday
      • Lecture
      • Code: uppercase.c
      • Code: is_multibyte.c

• **Week 2 – UTF-8 and Shell **

  • Lecture Materials
    • Monday
      • Lecture
      • Code: utf8analyzer.c, codepoint.c

Course Components

There are three main parts of the course: Assignments, Exams, and Social Learning.

Assignments

The course has 5 assignments that involve programming and writing. For each there will be:

• A problem set that has practice problems related to the assignment
• A programming project where you create a program that does something interesting and that we automatically test
• Design questions about the programming project

Grading: There are 6 points available for each assignment.

• 2 points for the corresponding problem set (2 points for fully correct and complete by the deadline, 1 point for somewhat complete at the deadline, 0 points for incomplete or very little completed at the deadline).
• 2 points for program correctness (2 points for perfect or nearly-perfect, 1 point for significant errors, 0 for programs that work on very few or no examples)
• 2 points for design questions (2 points for perfect or nearly-perfect, 1 point for minor errors, 0 points for major errors or incomplete)

After each assignment is graded, you’ll have a chance to resubmit all components based on the feedback you received, which will detail what you need to do to increase your score. You can increase your score by up to 1 point in each component on a resubmit.

This is also the only late policy for assignments. Unsubmitted assignments are initially given a 0, and can get a maximum of 3 points on resubmission.

Exams

There will be 3 exams during the quarter and retake and make-up opportunities in finals week. The 3 exams will be held during labs in weeks 4, 8, and 10. We will provide a schedule for finals week where you can come in for retakes and makeups.

No study aids or devices are allowed to be used during the exams. You will need only a photo ID and something to write with (scratch paper is available on request).

The exams will be administered through PrairieLearn and PrairieTest. The exams will have a mix of questions; they will typically include some that involve programming and interacting with a terminal.

Exams are (necessarily) cumulative. They typically focus on content that has already had a due date (e.g. PAs, problem sets, design questions, and labs that have their work due before the exam period starts), and typically don’t focus on specific details only found in textbook chapters or mentioned conversationally in lecture. However, that’s only a statement about the overall design, not a hard constraint: we will never promise that course content from any particular week, lecture, assignment, textbook chapter, or other course component won’t appear on an exam. We say this publicly in the syllabus to avoid misunderstandings (“the professor/TA/my friend told me not to study that”) and to make it clear that all the content matters (we wouldn’t assign it if it didn’t).

Social Learning

Learning (in college) is in part, a social process. Your engagement with it forms part of your grade for the class.

Lecture (Social Learning)

Lectures are designed to introduce you to concepts, show how experts in systems design approach problems, and give you a chance to ask questions about content, connect course content to the world outside the classroom, talk to your classmates and the staff, and provide an overarching story for the material.

Most lectures will come with two on-paper activities that are handed in for credit:

• A review check, near the beginning of class. These serve mainly as a way to check in on content from previous lectures before starting the content for the day, and for us to get some information about how everyone is following along with lecture content. Don’t think of them as quizzes, rather as an engagement check. You can discuss these with your classmates, and they are graded on completeness rather than correctness.

We say these will happen in “most” lectures because sometimes we may skip one or both for various timing or logistics reasons.

Grading: Each lecture has 2 social learning points available:

• 2 for the review check (only 1 point if handed in but incomplete)

If you miss either or both during class, you can submit the makeup assignment later for 1 point total. This is the only way to make up credit for missing a lecture.

The makeup assignment requires you to finish the review check, regardless of whether you turned one in during class. So:

• If you only hand in one during class, you can submit the full makeup assignment to earn 1/2 points for that day.
• If you miss lecture entirely, you can submit the full makeup assignment to earn 1 point.

All resubmissions must be before the next lecture to count, with no exceptions.

Labs (Social Learning)

The course’s lab component meets for 2 hours. In each lab you’ll switch between working on your own, working in pairs, and participating in group discussions about your approach, lessons learned, programming problems, and so on.

The lab sessions and groups will be led by TAs and tutors, who will note your participation in these discussions for credit. Note that you must participate, not merely attend, for credit.

Grading: For each lab there are 4 possible points to earn:

• 1 for being present
• 2 for being an active, professional, productive participant while present
• 1 for submitting and/or getting work checked off that was done in lab

If you miss lab, you can earn the submission/check-off point by submitting the check off work before the next Monday (day before the labs) at 11am, but cannot earn the 3 points related to participation. There is no way to make up a lab beyond this 1 point, even for illness, travel, or emergencies. Our preference would be to require all 10 labs for an A, and have some kind of excused absences. However, tracking excused absences doesn’t really scale, so this policy is how we handle it.

Discussions (Social Learning)

There are discussions on Wednesday, led by the course staff, for going over problem set problems and the programming assignments.

Grading: Attendance is taken, and attending discussion gives 1 social learning point.

Grading

Each component of the course has a minimum achievement level to get an A, B, or C in the course. You must reach that achievement level in all of the categories to get an A, B, or C.

• A achievement:
  • ≥85 social learning points (may adjust depending on the total number of available lecture points)
  • ≥27/30 assignment points (≥90%)
  • ≥10/12 exam points (≥83.3%)
• B achievement:
  • 70-84 social learning points
  • 23-26/30 assignment points (76.7-86.7%)
  • 8-9/12 exam points (66.7-75%)
• C achievement:
  • 55-69 social learning points
  • 20-23/30 assignment points (66.7-76.7%)
  • 6-7/12 exam points (50-58.3%)

Below C achievement (in any category) is an F/No Pass.

Pluses and minuses will be given based on performance on social learning and assignments (exam grades will not be used to determine plus and minus grades; this is to avoid extra load on retake testing). We don’t publish the exact cutoffs in advance.

Requests to change this grading policy (for a specific student or class-wide) will be denied with a link to this syllabus section. Consider this: we may, as instructors, decide for academic reasons that the most accurate way of assigning letter grades in the class needs to change (and we tend to only make changes that improve letter grades relative to this starting policy). However, it would be inappropriate for us to do so in response to student requests: that could create an appearance that we give students the grades they ask for rather than the grades they earned.

Policies and Perspective

CSE29, Large Language Models, and You

Evidence suggests that experts can generate (some kinds of) programs more quickly with the assistance of large language models. But, they did not become experts by using them.

We offer the following metaphor as guidance:

Consider physical conditioning, let’s take running for fitness in particular. There are many machines in the world that are remarkably effective at moving people around: electric scooters for example. Taking a scooter for a few miles gets you to your destination more quickly and less sweatily than running, but completely misses the point of the run. The goal of running for fitness has little to do with getting to a destination and everything to do with the changes that happen inside your body. Many people can run the same miles on the same road and get the benefits from it, despite them all doing the same work that a machine (the scooter) could have done.

Fitness is just one example like this. Similar comparisons make sense for learning to play an instrument, perform onstage, or upskill at games like billiards, darts, or Fortnite.

The programming in this class is like running for fitness (doing the typing and thinking on your own), not about getting to a destination quickly (handing in a completed program). The answers to many programming problems are known, or close-to-known, and many tools exist that can generate part or all of them, and there are many people who can write them faster than you. We assign the work not because knowing a solution is particularly important, but because the act of creating the solution changes you.

So, you should not use AI to generate code or prose for work in this class.

That said, it’s relatively difficult for us to detect AI usage on take-home work. It’s also useful to know what AI and code generation can do. So feel free to experiment, and do not read this policy as prohibiting, or assigning formal consequences to LLM use. A good way to go about learning in this course is to do the work yourself first, then go back and see how the LLM would have done it. Then you may be able to notice things, like the LLM generating extra unnecessary code, or doing something in a more or less complex way than you did it, or maybe doing exactly what you did! The key thing is that you developed a sense of what a solution was supposed to look like, rather than trusting the version from the machine.

(Also, the exams require that you program on your own, without the aid of any AI assistants.)

Device Policy

To a large degree, you are responsible for managing your time, attention, and learning in lecture, and I hesitate to make policies that attempt to govern or restrict your choices with respect to note taking or device use. However, lecture is a communal space, and your actions can affect others’ learning. In particular, what you have on your screen may be unavoidably in the field of view of other students. Because of this, you are responsible for a fragment of the attention of everyone in a cone of space behind you. With this in mind, the policy for lecture is that if you use a device, you must have lecture-related content onscreen. There is even research that shows that the content of screens in the classroom, even quite far away, can have a detrimental effect on learning. If you cannot resist checking social media, playing a game, or doing other off-topic tasks during lecture, sit in the back 2 rows so that you are only having an effect on your own attention, or the attention of others with a similar mindset.

Assignments and Academic Integrity

You can use code that we provide or that your group develops in lab as part of your assignment. If you use code that you developed with other students (whether in lab or outside it), got from Piazza, or got from the internet, say which students you worked with and a sentence or two about what you did together in CREDITS.txt. All of the writing in assignments (e.g. in open-ended written questions) must be your own.

You can use an AI assistant like ChatGPT or Copilot to help you author assignments in this class. If you do, you are required to include in CREDITS.txt:

• The prompts you gave to the AI chat, or the context in which you used Copilot autocomplete
• What its output was and how you changed the output after it was produced (if at all)

This helps us all learn how these new, powerful, and little-understood tools work (and don’t).

If you don’t include a CREDITS.txt and it’s clear you included code from others or from an AI tool, you may lose credit or get a 0 on the assignment, and repeated or severe violations can be escalated to reports of academic integrity violations.

Exams and Academic Integrity

It is a violation of academic integrity to share details of your exam with others until after you receive your grade for it. Keep in mind that the exams are randomized to discourage casual cheating, so your exam may not be the same one that others see. It is a violation of academic integrity to communicate with anyone other than the official proctors during the exam, or to use devices other than the ones you are using to complete the exam.

Lab and Professionalism

Lab work will be highly collaborative, and designed to encourage communication between students. Some of the activities will have you talk to other students, or exchange code, ideas, or commands with other students, and write down what happened.

In all of this communication, remember to be polite, professional, and focus on the work. A huge part of the job of a working software professional or researcher is professional and clear communication.

Some tricks for this: avoid statements that reference the author of the code, frame negative feedback as possible improvements or ways your expectations were violated, and take responsibility for anything you don’t understand.

Examples:

• Don’t say “You made a mistake here: …” Instead say “On line I expect the condition to be true but I think it will be false because XYZ … we could demonstrate that by doing ABC.”
• Don’t say “It seems like you don’t know about…”, instead say “On line 10-12, these 3 lines could be shortened into one line using grep -r instead of find followed by grep: ….” And use some judgment: it’s likely that some of this advice is helpful and constructive, and some of it is just showing off.
• Don’t say “This code is (going to be) slow…” Instead wait until you can run it and try an example that demonstrates it “This code took 10 seconds to run for input XYZ and that seems like a lot. When we were writing … I think I noticed that we did X, if we did Y instead I think it will go faster
• Don’t say “That conditional is ugly:…” Instead say “I find it easier to read these conditions when they are written as …. because …” If you don’t have a good explanation to put after the “because”, how do you know it’s a good suggestion? Refer also to the advice about not showing off
• Don’t say “You wrote lines 20-24 very confusingly.” Instead say “I’m having trouble understanding lines 20-24. It would help me to work through an example of how that part is supposed to work”

FAQ/AFQ (Anticipated Frequent Questions)

Q: I am waitlisted for one of the sections at position N. What should I do?

Come to class and do all the work as usual (you will have Canvas access to get all the needed links) so you can be up to speed if you do get a spot. This is aligned with official department policy.

We can’t make accurate predictions about chances of getting into the course from a specific waitlist position, or control that process as instructors.

Can I attend a lab section other than the one I’m enrolled in?

No, please do not try to do this. The lab sections have limited seating and are full. We cannot accommodate switching.

How can I switch sections?

You have to drop and re-add (which may involve getting [back on] the waitlist). Sorry.

Can I leave lab early if I’m done or have a conflict?

The labs are designed to not be things you can “finish”. Labs have plenty of extension and exploration activities at the end for you to try out, discuss, and help one another with. Co-located time with other folks learning the same things is precious and what courses are for. Also, if you need an extrinsic motivation, you won’t get credit for participation if you don’t stay, and participate, the whole time. We can often accommodate one-off exceptions – if you have a particular day where you need to leave early, it’s a good idea to be extra-engaged in your participation so your lab leader can give you participation credit before you leave.

Do I have to come to lab?

Yes, see grading above.

I missed lab, what should I do?

The lab page will have instructions on how to submit the make-up, which can get you 1 (of 4 possible) points.

I missed my exam time, what should I do?

Stay tuned for announcements about scheduling make-ups in final exam week.

Where is the financial aid survey?

We do this for you; as long as you submit something in the first two weeks, we will mark you as commencing academic activity.

I have a conflict with the final exam time, what can I do?

The final exam week we will offer flexibly scheduled timeslots to retake the three PrarieLearn exams from the quarter.

Lab 1: Unix, SSH, and Vim

Welcome to the first CSE 29 lab!
Lab is the time and space to explore practical software tools aspect of CSE 29’s title. Tools will include Unix commands, Git, GDB, Valgrind, Makefiles, shell scripting, and more.
You are not expected to know what any of these topics are yet—this is just a preview of what’s to come. Over the next 10 weeks, the lab writeups found here will guide you as you build familiarity with these tools, which you’ll use throughout this course and in future endeavors.
I, the Lab, hope you enjoy the process and have some fun along the way!

• In each lab session, you will follow this guide to get firsthand experience with the tools and techniques we have introduced to you in lectures and discussions. This experience will be essential to your Project work. You earn credit for participation by being engaged with the content of this lab and interacting with the staff when asked.

These labs are a low-stakes environment to get proficient with programming and software tools with support from fellow classmates and course staff. Please ask for help from course staff if you are stuck on something—we are here for you!

Lab 1 Learning Objectives

• Connect to ieng6 using SSH (Secure SHell)
• Try out and understand some essential Unix/Linux commands
• Write a basic C program on ieng6 using Vim
• Compile and run the C program you wrote

Icebreaker

• Discuss the following with the people around you. Get to know your fellow group members!

• How you’d like people to refer to you (pronounce your name/nickname, pronouns like he/her/they, etc)

• Your major

• One of:

  • A UCSD student organization you’re a member of or interested in
  • Your favorite place you’ve found on campus so far
  • A useful campus shortcut or trick you know

• What is your favorite movie, or (if you prefer) the last movie you saw? What genre is it?

• Who is your favorite character and why?

• What is your favorite thing about the movie?

Throughout this lab, we strongly encourage you to help each other. The staff is always there to help, but do try working together and helping each other out first.

Github Setup

Make a Github account WITH YOUR UCSD EMAIL and fill out this form. https://forms.gle/pVQP1Xpc8akjqmTh9 If you already have a Github account, follow this link to add your UCSD email to your account. If you find yourself spending more than 5 minutes on this part, ask a staff member for help

Let’s connect to ieng6

First, open up a terminal window by following the instructions for your operating system.

• Windows: Do you have (Windows Subsystem for Linux) installed? (if you aren’t sure, assume you do not)
  • No WSL: Press the Windows button, type in “Terminal”, then select “Terminal” or “Command Prompt” (if “Terminal” doesn’t exist).
    • Once the window launches, type ssh and press Enter. If you see a red error message stating that ssh is not recognized, please follow the instructions here to enable SSH.
    • We do recommend installing wsl as it is a very useful tool! Let us know if you run into any issues on EdStem, in tutor hours, or in office hours.
  • Yes, WSL is installed: Press the Windows button, type in “wsl”, then select “WSL”
• MacOS: Click the Launchpad icon in the Dock, type in “Terminal”, then select the Terminal application.
• Linux: Press Ctrl+Alt+T to launch a terminal window.

As a student, you are assigned an account on the ieng6 server hosted by UCSD. These are similar to accounts you might get on other systems at other institutions (or a future job). We’ll see how to use your machine to connect to a remote computer over the Internet to do work there.

Your account name is the same account name as the one that’s used for your school Google account, i.e. it is the string that precedes “@ucsd.edu” in your school email address. In case you need to check the status of your student account, refer to the UCSD Student Account Lookup page.

Let’s use SSH (Secure SHell) to connect to ieng6 . Your command will look like this, but with the aname replaced by your account name. Don’t copy the $!

The $ symbol is the prompt. In the terminal, it represents that you can type commands after this symbol to execute them. It is conventional to include $ when giving examples of commands to make it clear that they are user-written commands, as opposed to output from a command.

Since this is likely the first time you’ve connected to this server, you will probably get a message like this:

$ ssh aname@ieng6.ucsd.edu
The authenticity of host 'ieng6.ucsd.edu (128.54.70.236)' can't be established.
ED25519 key fingerprint is SHA256:8vAtB6KpnYXm5dYczS0M9sotRVhvD55GYz8EjN1DYgs.
This host key is known by the following other names/addresses:
    C:\Users\etomson/.ssh/known_hosts:1: ieng6.ucsd.edu
Are you sure you want to continue connecting (yes/no/[fingerprint])? 

answer with: yes and it should say:

Warning: Permanently added 'ieng6.ucsd.edu' (ED25519) to the list of known hosts.

After this, you get a prompt to enter your password. This is the same password you use to log into your student account on other websites, like Canvas and Tritonlink. The terminal itself does not show what you type when you enter your password. This is conventionally done for your own security, so that others looking at your screen don’t see it. Just trust that it gets inputted when you type. Press Enter when you are done.

If the login process succeeds, you should see something like:

Last login: Tue Jan  7 10:00:00 2025 from 66.11.22.33
Hello aname, you are currently logged into ieng6-999.ucsd.edu

You are using 0% CPU on this system

To see all available software packages, type "prep -l" at the command prompt, or "prep -h" for more options.
[aname@ieng6-999]:~:45$

Now your terminal is connected to a computer that is physically somewhere else on campus, and any commands you run will run on that computer! We call your computer the client and the computer that is elsewhere the server based on how you are connected.

If, in this process, you run into errors and can’t figure out how to proceed, ask! Remember – it is rare for a tutorial to work perfectly. We often have to stop, think, guess, Google search, ask someone, etc. in order to get things to work the way the tutorial says.

To exit out of the ieng6 server and return to running commands on your local device, type exit as a command, or press Ctrl+D (which sends an EOF character). Please exit the ieng6 server now for the next section.

The Terminal and You

In your day-to-day life as a CSE 29 student (and as a software engineer), you’ll be making heavy use of the terminal. Best to get familiar with it early on.

A terminal is a text-based interface for a user to interact with the computer. There are various commands that a user can type into the terminal that perform different functions. Let’s take a look at some of them.

pwd - “Where am I?”

The location in the file system in which you are currently is called the “working directory”. You can use the pwd command to print the name of the working directory.

$ pwd
/home/linux/ieng6/oce/6k/aname

uname - “Who am I?”

Unix name will give you nformation about the unix or linux system you are currently on.

$ uname
Linux

This alone does not tell us much but there are several flags that are useful.

• -a:print all information, except omit -p and -i if unknown
• -s: print the kernel name (this is the same as default uname)
• -n: print the network node hostname i.e. the name of the computer.

systeminfo - Who am I on windows?

As uname stands for unix name, it does not tend to work on Windows machines. Thankfully, windows has provided it’s own command to print information about the system – systeminfo.

$ systeminfo

Host Name:                     ELENA-M15
OS Name:                       Microsoft Windows 11 Pro
OS Version:                    10.0.26200 N/A Build 26200
(...)

It gives far more information than you would need for this lab, but do note that it includes the name of the computer equivalent to uname -n.

ls - Looking around

You can’t do much without knowing what exists in the current working directory to interact with. You can use the ls command to list out the contents of the current working directory.

$ ls
folder hello.txt

Most commands will have multiple pre-defined options which allow you to modify the behavior of a command. Options are usually written as a dash (-) followed by a few letters. Some common options for the ls command include:

• -a: list all files, including hidden files
• -l: list in a long format, which shows additional information, such as permissions and time of creation
• -al: enables both the -a and -l options for the same command
• --color: colors the output which on ieng6 makes all your directories blue and executable files green

If you would like to always have the colored output, run the following command which will add the line “alias ls="ls –color" to the end of a file called .bash_profile. You do not need to fully understand this yet.
echo alias ls=\"ls --color\" >> ~/.bash_profile

cd - Going Places

You can change your working directory to a different directory using the cd command with the destination directory as an argument.

$ cd folder
$ pwd
/home/aname/folder

There are also built-in symbols which refer to locations in the filesystem that you can use as arguments to commands.

• / (slash) represents the root directory, which is the top-most directory in a file system. It has to start somewhere!
• ~ (tilde) represents the home directory, which is usually a specific directory assigned to each user on a system.
• . represents the current directory.
• .. represents the parent directory, i.e. the directory in which this directory is contained.

mv - Moving Things

You can move your files with mv.

We have a misspelt file in the wrong location.

$ ls -R
.:
cse29  hellowrold.c

./cse29:
$ mv hellowrold.c cse29/helloworld.c
$ ls -R
.:
cse29

./cse29:
helloworld.c

Moved the file hellowrold.c into the cse29 directory and fixed it’s name. You can rename files, change their location, or both at once as shown.

cp - Copying Things

You can copy files with cp.

$ ls
alloc_basic.c
$ cp alloc_basic.c mytest.c
$ ls
alloc_basic.c mytest.c

Works exactly the same as mv except doesn’t remove the original file.
Good for when you want to make a variation of a file or have a backup.

scp - Securely Copying Things

you can securely copy your files with scp. Assume I start on my machine which is windows – not ieng6

$ ls
fruits.txt
$ scp .\fruits.txt etomson@ieng6.ucsd.edu:~/
fruits.txt                                100%   31     0.0KB/s   00:00
PS C:\Users\etomson> ssh etomson@ieng6.ucsd.edu
$ ls
Downloads    Music      pokemon.sh    cse29fa24  
cse29su25    cse8a      ece148        MailArchive   
fruits.txt   cse29      cse29sp24     cse29wi26  
Documents   juotes.sh   quotes.sh

The file fruits.txt was copied into my home directory on ieng6.

A general format for copying to ieng6 is:

scp <file you wish to copy> <username>@ieng6.ucsd.edu:<path on ieng6 to put it>
username is the same as you used for ssh.

touch - Creating Things

The touch command is used to change the last modified date of a file (hence, touching the file). A neat bonus feature of touch is that it will create a file with the given name if the file doesn’t already exist.

$ touch random.txt
$ ls
random.txt

A quick side note - by default, the output of a command is printed out to the screen. But we can redirect the output into files using the > character. For example, $ pwd > random.txt takes the output from pwd and redirects it into a new file called random.txt (thus it does not print to the terminal).

cat - Looking at Things

You can use the cat command to display the contents of a file. This command is designed to be used to concatenate files, but it is also commonly used to print out things.

$ cat mylocation.txt
/home/aname/folder

mkdir - Creating Directories (Folders) to Hold Things

You can use the mkdir command to make a new directory with the given name as an argument.

$ mkdir nestedfolder
$ ls
nestedfolder

rm - Removing Things

When a file has outlived its usefulness, we may wish to remove them. This can be done with the rm command. For example:

$ ls
random.txt
$ rm random.txt
$ ls

Because the random.txt file got removed, our working directory is now empty, so ls doesn’t print anything.

man - Getting Help

Recall the command line options introduced for ls, -a and -l.

What if we wanted to learn more about what they do? What if we wanted to learn what other options ls has? How about the functionality and options of other commands? If only there were a manual for this information…

Luckily for us, there is. You can use the man command to look up the functionality of a command. For example:

$ man ls
LS(1)                                               User Commands                                               LS(1)
NAME
        ls - list directory contents

SYNOPSIS
        ls [OPTION]... [FILE]...

DESCRIPTION
        List  information  about the FILEs (the current directory by default).
        Sort entries alphabetically if none of
        -cftuvSUX nor --sort is specified
...
    -a, --all   do not ignore entries starting with .
...
    -l    use a long listing format
...

To navigate the manual page, you can use the up and down arrow keys. To exit the manual, press q.

Try looking up some of the commands we’ve learned about so far in the manual. Who knows? You might learn something new.

Who are you? – Whiteboard Activity

Using the commands above, fill out the following whiteboard with your group! Each group member should put their answer for each box.
A set of example answers have been given

Who are we anyways? – Whiteboard Activity

Now that you’ve established who you are using some commands you just learned, the course staff has come together to make an activity for you to explore more commands from above and learn something about them.

The Vim Text Editor

Back in my day, before we had IDEs, we had to write all our code in the terminal with Vim, and we liked it!

Up till now, you have most likely been programming in a graphical editor where you could click around with a mouse and highlight things by clicking and dragging.

But CSE 29 is cool. And using the mouse is decidedly uncool (in our view). So we are now going to learn a keyboard-based editor. Because you will spend the entire quarter inside the terminal (and you will love it), knowing how to use a text-based editor like what we are about to introduce is incredibly crucial.

After all, all the awesome hackers in movies are always typing, have you seen a single movie hacker clicking around with a mouse? Blurgh.

Our terminal-based editor is called vim. It’s an incredibly powerful editor once you learn how to use it properly. However, the learning curve is very steep, which is why the more you practice in these earlier weeks, the better. In this lab, you will use vim to write a small C program while learning a few essential vim features along the way.

Vim is highly configurable—using its own scripting language (VimScript), we can customize its behavior in a wide variety of ways. We can even install a Vim package manager and add plugins that make it feel like VSCode! For now, let’s start with some sensible defaults, like 4 spaces for indentation, syntax highlighting enabled, and automatic “smart” indentation. If you haven’t configured Vim on ieng6 before, run the following command to download and install our configuration file:

$ curl https://cse29.site/week1/assets/vimrc.txt >> ~/.vimrc

Now, we are ready to begin. Inside the lab1 directory you created in the previous section, run the following command to edit a new file named contains.c:

$ vim contains.c

The Insert mode: “Just type”

When you enter vim, you start in the Normal mode. Press i to enter Insert mode, where anything you type gets inserted into the file. You should see -- INSERT -- show up at the bottom left (the status bar).

In this mode, you can:

• Use your arrow keys to move your cursor around the file
• Press Backspace/delete to delete the character at the cursor, much like conventional text editors
• Press Ctrl+Shift+V (Windows and Linux) or Command+V (macOS) to paste text from your operating system clipboard
• Press Esc to exit Insert mode and return to Normal mode

While we’re in Insert mode, let’s write a small C program that demonstrates a linear search algorithm. Complete the following skeleton in vim:

#include <stdio.h>

int contains(int item, int arr[], int size) {
   // Write your solution here!
   // Return 1 if "item" exists in "arr" (which has length "size"), otherwise 0
}

int main() {
   int arr[] = {2, 9, 2, 0, 2, 5};

   // Call "contains" with an item of your choice, "arr", and the length of "arr".
   // Replace "0" in the following line with your function call
   printf("Result: %d\n", 0);
   return 0;
}

The Normal mode

Press Esc to exit Insert mode. The -- INSERT -- indicator at the bottom left should disappear. You are now in Normal mode, where you can:

• Press h, j, k, and l to move your cursor inside the text editor

      ^
      k     Hint: The h key is at the left and moves left.
  < h   l >       The l key is at the right and moves right.
      j           The j key looks like a down arrow.
      v
  

  You can still use your arrow keys instead if you’d like! Psssst, no shame in doing so—professor Soosairaj does this, too!

• Press : to enter Command mode

• Press i or a to enter Insert mode

  • Try out both to figure out the difference!

• Copy/paste: press y twice to “yank” (copy) the current line into vim’s internal clipboard. Press p to paste it at the current cursor position.

• Delete: press d twice to delete the current line and put it into vim’s internal clipboard. Press p to paste the deleted line at the current cursor position.

The Command mode

When you enter Command mode by pressing : in Normal mode, your cursor moves to the bottom line of the terminal, where you can type out commands. For now, we will only use two command shorthands: w for writing your changes (like pressing Save in a graphical text editor), and q for quitting vim. You can type :w to save your changes to storage, :q to quit (add ! afterward to force quit without saving unsaved changes), or wq to save and quit. So, when you are done editing in vim, you would type :wq from Normal mode. Pretty convenient, right?

By the way, if you ever change your mind and want to abandon your command, press Esc in Command mode to return to Normal mode.

A quick side note - avoid running two instances of Vim on the same file at the same time as this can lead to swap file conflicts. You should not close your terminal window to exit Vim as this will leave the swapfile there.

Compiling and running your program

Now we want to be able to run our program. First we will compile it using gcc, and then we will run our executable file.

Compiling

GCC, our C compiler of choice, takes .c files and compiles them into our executable. for now we will only have 1 .c file and we will give it as our first argument to gcc, giving us:

$ gcc contains.c (Don’t run this yet!)

However, this would create an executable named a.out and we would like our file to be named contains. (Yes, executable files don’t have an extension in Unix/Linux.) We can use the -o flag to do this. -o takes the next argument and renames the output file to be that name:

$ gcc contains.c -o contains (Don’t run this yet!)

We would also like to see any warnings that the compiler catches even if it doesn’t prevent it from compiling as an error. We will use the -Wall flag, which stands for Warn all. (Run this!)

$ gcc contains.c -o contains -Wall

If you don’t see any output from this command, then it has succeeded. To run our program, since it is named “contains”, we shall type:

$ ./contains

You should see your linear search implementation in action.

Congratulations! In this lab, you have created, compiled, and executed a C program. If your program has not run, please ask a staff member near you for help.

PA1 - UTF-8: Due Monday 10/12

Representing text is straightforward using ASCII: one byte per character fits well within char[] and it represents most English text. However, there are many more than 256 characters in the text we use, from non-Latin alphabets (Cyrillic, Arabic, and Chinese character sets, etc.) to emojis and other symbols like €, to accented characters like é and ü.

The UTF-8 encoding is the default encoding of text in the majority of software today. If you’ve opened a web page, read a text message, or sent an email in the past 15 years that had any special characters, the text was probably UTF-8 encoded.

Not all software handles UTF-8 correctly! For example, Joe got a marketing email recently with a header “Take your notes further with Connect​” We’re guessing that was supposed to be an ellipsis (…), UTF-8 encoded as the three bytes 0x11100010 0x10000000 0x10100110, and likely the software used to author the email mishandled the encoding and treated it as three extended ASCII characters.

This can cause serious problems for real people. For example, people with accented letters in their names can run into issues with sign-in forms (check out @yournameisinvalid for some examples). People with names best written in an alphabet other than Latin can have their names mangled in official documents, and need to have a “Latinized” version of their name for business in the US. Joe had trouble writing lecture notes because LaTeX does not support UTF-8 by default.

UTF-8 bugs can and do cause security vulnerabities in products we use every day. A simple search for UTF-8 in the CVE database of security vulnerabilities turns up hundreds of results.

It’s useful to get some experience with UTF-8 so you understand how it’s supposed to work and can recognize when it doesn’t. To that end, you’ll write several functions that work with UTF-8 encoded text, and use them to analyze some example texts.

Getting Started

Step 1: Do the Prairielearn Problem Set #1

Before you start coding or doing the project, you need to do the Prairielearn: Problem Set 1. You will incrementally build your full UTF-8 analyzer by doing this problem set. Then you will put everything together you built in the Problem Set into one complete program that will analyze UTF-8 strings.

Step 2: Make your Git repository and begin coding

Visit this link to create your project Git repository: Classroom50

Note: Git is a command line tool used for managing source code that we will teach you to use in lab 2. You should commit and push all your code and changes to this repository.

Milestones, Working Process, and Definitions

The functions described below are organized into milestones; you should definitely finish the functions in a milestone set before moving onto the next.

In general, you should work one function at a time, and earlier functions may be useful in implementing later functions.

A good first task is to implement only is_ascii and the corresponding part of main needed to read input and print the result for is_ascii, and make sure you can test that. Then move onto capitalize_ascii, and so on.

You can and should save your work by using git commits (if you’re comfortable with that), or even just saving copies of your .c file when you hit important milestones. We may ask to see your work from an earlier milestone if you ask us for help on a function from a later one.

Some reminders and information about the function signatures:

• Your functions must have exactly the names and signatures shown below; we will test each of them individually. Incorrect function headers will lead to failed tests.
• int8_t and int32_t are 8-bit (1-byte) and 32-bit (4-byte) integers. You can think of int32_t like int in Java, we just want to be explicit about sizes of things when we program in C, and int can mean different things on different systems. These types are defined in stdint.h, so #include <stdint.h> at the top of a program will make them usable.
• Some functions take a code point index (which character, counting from 0) and some take a byte index (which byte in the char[], counting from 0). For ASCII text these are the same, but for other text they are not! Pay attention to which one each function takes.

Functions - Milestone 1

int8_t is_ascii(char string[])

Takes a UTF-8 encoded string and returns if it is valid ASCII (e.g. all bytes are 127 or less). The empty string is valid ASCII.

Example Usage:

printf("Is 🔥 ASCII? %d\n", is_ascii("🔥"));

=== Output ===
Is 🔥 ASCII? 0

printf("Is abcd ASCII? %d\n", is_ascii("abcd"));

=== Output ===
Is abcd ASCII? 1

int32_t capitalize_ascii(char str[])

Takes a UTF-8 encoded string and changes it in-place so that any ASCII lowercase characters a-z are changed to their uppercase versions. Leaves all other characters unchanged. It returns the number of characters updated from lowercase to uppercase.

Example Usage:

int32_t ret = 0;
char str[] = "abcd";
ret = capitalize_ascii(str);
printf("Capitalized String: %s\nCharacters updated: %d\n", str, ret);

=== Output ===
Capitalized String: ABCD
Characters updated: 4

Functions - Milestone 2

int8_t codepoint_size(char string[])

Takes a UTF-8 encoded string and returns how many bytes the first code point in it takes (start byte + continuation bytes): 1, 2, 3, or 4.

Returns 0 if the string is empty, and -1 if the first byte is not a valid start byte.

Example Usage:

printf("Size: %d bytes\n", codepoint_size("éclair")); // é is start byte 0xC3 + 1 cont. byte

=== Output ===
Size: 2 bytes

char s[] = "Héy"; // same as { 'H', 0xC3, 0xA9, 'y', 0 }
printf("Size: %d\n", codepoint_size(&s[2])); // the string starting at byte 2 starts with 0xA9, a continuation byte, not a start byte

=== Output ===
Size: -1

int32_t utf8_strlen(char str[])

Takes a UTF-8 encoded string and returns the number of UTF-8 codepoints it represents.

Returns -1 if there are any errors encountered in processing the UTF-8 string.

Example Usage:

char str[] = "Joséph";
printf("Length of string %s is %d\n", str, utf8_strlen(str));  // 6 codepoints, (even though 7 bytes)

=== Output ===
Length of string Joséph is 6

void utf8_substring(const char str[], int start, int end, char result[])

Takes a UTF-8 encoded string and start (inclusive) and end (exclusive) code point indices, and writes the substring between those indices to result, with a null terminator. Assumes that result has sufficient bytes of space available. (Hint: result will be created beforehand with a given size and passed as input here. Can any of the above functions be used to determine what the size of result should be?)

If the end index is larger than the utf8_strlen of the string, it should act as if the end index was exactly utf8_strlen of the string.

If start is negative, or start is greater than or equal to end, result should be the empty string.

Example Usage:

char str[] = "🦀🦮🦮🦀🦀🦮🦮"; // these emoji are 4 bytes long
char result[17];
utf8_substring(str, 3, 7, result);
printf("String: %s\nSubstring: %s\n", str, result);

=== Output ===
String: 🦀🦮🦮🦀🦀🦮🦮
Substring: 🦀🦀🦮🦮

Functions - Milestone 3

int32_t codepoint_at(char str[], int32_t byte_index)

Takes a UTF-8 encoded string and a byte index, and returns a decimal representing the codepoint of the character that starts at that byte.

Returns -1 if the byte at that index is not a valid start byte (for example, if it is a continuation byte) or is past the end of the string.

Example Usage:

char str[] = "Joséph"; // J o s é é p h
                       // 0 1 2 3 4 5 6  <- byte indices; é takes bytes 3 and 4
printf("Codepoint at byte 5 in %s is %d\n", str, codepoint_at(str, 5)); // 'p' starts at byte 5
printf("Codepoint at byte 3 in %s is %d\n", str, codepoint_at(str, 3)); // 'é' starts at byte 3
printf("Codepoint at byte 4 in %s is %d\n", str, codepoint_at(str, 4)); // byte 4 is the middle of 'é'

=== Output ===
Codepoint at byte 5 in Joséph is 112
Codepoint at byte 3 in Joséph is 233
Codepoint at byte 4 in Joséph is -1

int is_animal_emoji_at(const char str[], int index)

Takes a UTF-8 encoded string and a code point index, and returns 1 if the code point at that index is an animal emoji, and 0 otherwise (including if the index is out of range).

For simplicity for this question, we will define that that the “animal emojii” are in two ranges: from 🐀 to 🐿️ and from 🦀 to 🦮. (Yes, this technically includes things like 🐽 which are only related to or part of an animal, and excludes a few things like 🙊, 😸, which are animal faces.). You may find the wikipedia page on Unicode emoji helpful here.

Example Usage:

char str[] = "I 🐶 you";
printf("%d %d\n", is_animal_emoji_at(str, 2), is_animal_emoji_at(str, 0)); // 🐶 is code point 2

=== Output ===
1 0

UTF-8 Analyzer

You’ll also write a program that reads UTF-8 input and prints out some information about it.

Here’s what the output of a sample run of your program should look like:

$ ./utf8analyzer
Enter a UTF-8 encoded string: My 🐩’s name is Erdős.
Valid ASCII: false
Uppercased ASCII: "MY 🐩’S NAME IS ERDőS."
Length in bytes: 27
Number of code points: 21
Bytes per code point: 1 1 1 4 3 1 1 1 1 1 1 1 1 1 1 1 1 1 2 1 1
Substring of the first 6 code points: "My 🐩’s"
Code points as decimal numbers: 77 121 32 128041 8217 115 32 110 97 109 101 32 105 115 32 69 114 100 337 115 46
Animal emojis: 🐩

You can also test the contents of files by using the < operator:

$ cat utf8test.txt
My 🐩’s name is Erdős.
$ ./utf8analyzer < utf8test.txt
Enter a UTF-8 encoded string: 
Valid ASCII: false
Uppercased ASCII: "MY 🐩’S NAME IS ERDőS."
Length in bytes: 27
Number of code points: 21
Bytes per code point: 1 1 1 4 3 1 1 1 1 1 1 1 1 1 1 1 1 1 2 1 1
Substring of the first 6 code points: "My 🐩’s"
Code points as decimal numbers: 77 121 32 128041 8217 115 32 110 97 109 101 32 105 115 32 69 114 100 337 115 46
Animal emojis: 🐩

Testing

We provide 3 basic tests in the tests folder of your Classroom50 repository. These contain simple tests for identifying valid ASCII and converting ASCII lowercase characters to uppercase.

You can see the result for a single test by using:

./utf8analyzer < tests/utf8test.txt

Here are some other ideas for tests you should write. They aren’t necessarily comprehensive (you should design your own!) but they should get you started. For each of these kinds of strings, you should check how UTF-8 analyzer handles them:

• Strings with a single UTF-8 character that is 1, 2, 3, 4 bytes
• Strings with two UTF-8 characters in all combinations of 1/2/3/4 bytes. (e.g. "aa", "aá", "áa", "áá", and so on)
• Strings with and without animal emojii, including at the beginning, middle, and end of the string, and at the beginning, middle, and end of the range
• Strings of exactly 5 characters

We recommend saving your input in files in the tests folder and using redirection (<) to test, so you don’t have to figure out how to type the same UTF-8 characters over and over. Commit and push these test files to your repository along with your code.

Design Questions

The design questions are submitted separately from your code.

Answer each of these with a few sentences or paragraphs; don’t write a whole essay, but use good writing practice to communicate the essence of the idea. A good response doesn’t need to be long, but it needs to have attention to detail and be clear. Examples help!

Question 1

Consider these two bytes: 11000001 10000001

Based on the definition of UTF-8 we used in PA1, what code point does it encode? What are 1-byte, 3-byte, and 4-byte encodings of the same code point? Which of these are valid UTF-8 encodings of this code point? Why are they valid or not valid? (This requires some outside research – “valid” is a technical term here)

Describe how you would write a function that detects if a UTF-8 string has any invalid code points like these.

Question 2

Consider a comparison of UTF-8 with the alternate encoding UTF-32.

For a string s that is n+1 bytes long (n bytes of data with a 1-byte null terminator), strlen(s) must be equal to n.

• Is this property true for UTF-8? Explain why or give a counterexample.
• Is this property true for UTF-32? Explain why or give a counterexample.

For a string s that is n+1 bytes long (n bytes of data with a 1-byte null terminator) with the n bytes encoding 2c code points (that is, it is even length in terms of unicode characters), there is a valid code point starting at byte s[n / 2].

• Is this property true for UTF-8? Explain why or give a counterexample.
• Is this property true for UTF-32? Explain why or give a counterexample.

HINT: Write out the UTF-8 and UTF-32 encoding of a few short strings, including characters in the ASCII range and outside it.

Resources and Policy

Refer to the policies on assignments for working with others or appropriate use of tools like ChatGPT or Github Copilot.

You can use any code from class, lab, or discussion in your work.

What to Hand In

PA1 has two separate Gradescope submissions. You must complete both.

These have yet to be set up! Hang tight if you complete the assignment before they are set up

1. Code: the Project 1 - Code assignment on Gradescope

Your submission should contain:

• Any .c files you wrote (can be one file or many; it’s totally reasonable to only have one). We will run gcc *.c -o utf8analyzer to compile your code, so you should make sure it works when we do that.
• Your tests in files tests/*.txt

To submit:

1. Make sure all of your work is committed and pushed to your Classroom50 repository (git status should show nothing left to commit, and your latest changes should be visible on GitHub).
2. Open the Project 1 - Code assignment on Gradescope and choose GitHub as the submission method. (The first time, you will need to connect your GitHub account to Gradescope.)
3. Select your repository, ucsd-cse29-fall2026/cse29-fa26-pa1-<your GitHub username>, and the main branch, then upload.

If your repository doesn’t appear in the list on Gradescope, choose Upload instead and upload your .c files and your tests folder.

Pushing to your repository does not submit your assignment, even if Classroom50 shows the assignment as Submitted. Only what you submit on Gradescope before the deadline will be graded, so if you push more changes, submit again on Gradescope.

The submission system will show you the output of compiling and running your program on the provided tests to make sure the baseline format of your submission works. You will not get feedback about your overall grade before the deadline.

2. Design Questions: the Project 1 - Design Questions assignment on Gradescope

Type your answers to the design questions directly into the Project 1 - Design Questions assignment on Gradescope. Do not put them in your repository or your code submission; answers submitted there will not be graded.