CSE 333 Homework 0

Part A – Fetch the Code

Assignments will be distributed and collected using your CSE 333 Gitlab repository. Starter code will be added to your repository by the course staff and you will tag your repository when you are done with an assignment to indicate which revision should be evaluated and graded by the course staff. More information about git and Gitlab is given below and in other writeups on the course web site.

Clone your Gitlab repository

You can use the CSE Gitlab web interface to browse your files and find out information about your repository, but you must clone a copy to a Linux machine to do your work. If you have not done so already, change to a directory where you want to store the local repository for your CSE 333 projects, then follow the instructions on the Gitlab Setup page to clone your CSE 333 repository. There is also additional information further down that page on Developing with Git Workflow.

You might have additional personal projects and repositories in Gitlab for your own work, but be sure to use the repository provided by us for your CSE 333 course projects.

Once you have cloned the repository, change into that directory (it will be named something like cse333-23au-xyzzy, where xyzzy is your userid) then enter a ls command. You should see something like this:

$ git clone git@gitlab.cs.washington.edu:cse333-23au-students/cse333-23au-xyzzy.git
-- git output appears here
$ cd cse333-23au-xyzzy
$ ls -a
.gitignore cpplint.py exercises hw0

• The .gitignore file lists file types that should not normally be saved in the repository. These are typically things like editor backup files (names ending in ~) and object files (ending in .o). They are files that are generated and used locally while you are working but are recreated as needed from files that are in the repository rather than archived permanently.
• The exercises directory is mostly empty, but you can store your exercise code here. It is especially useful for collaborating with a partner and enabling course staff to access your code remotely (e.g., during virtual OH or when responding to your Ed post). It these cases, it would be best to push your current code to this folder for your partner or a staff member to view.

Part B – Edit, Compile, and Run hello_world

In the hw0 directory, run make. This command will use the instructions in file Makefile to compile the hello_world executable using the gcc compiler. Run the executable by entering the command ./hello_world. You should see one line of output that looks like:

$ ./hello_world
The magic code is: <xxxxx>
$ 

for some <xxxxx>. Now, edit hello_world.c in the CSE Linux environment using your favorite editor, and change the printf so that it instead says:

$ ./hello_world
The magic word is: <xxxxx>
$ 

Execute make to rebuild, and then re-run ./hello_world to make sure that it does what you expect.

Part C – Try GDB

You're unlikely to have any runtime errors, but let's use the debugger so that you know what it can do. Here is a session that:

1. Launches the debugger,
2. Sets a breakpoint on source line 19 of hello_world.c,
3. Prints the values of a couple of variables and an expression,
4. Prints a "backtrace" of the stack (showing the sequence of procedure calls that led to executing line 19 of hello_world.c), and then
5. Continues execution.

You should type the lines shown in bold. You may see some differences in version numbers or exact addresses, but the data values should be basically the same.

• For GDB to be useful, you must use the -g option for gcc when compiling. The Makefile we distributed does that.
• If you have already modified your file for Part B, you will see the new output word instead of "code" below.

$ gdb ./hello_world
GNU gdb (GDB) Red Hat Enterprise Linux 10.2-10.el9
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
...
Reading symbols from ./hello_world...
(gdb) break 19
Breakpoint 1 at 0x401143: file hello_world.c, line 19.
(gdb) run
Starting program: /homes/iws/<netid>/cse333-23au-<netid>/hw0/hello_world
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".

Breakpoint 1, main (argc=1, argv=0x7fffffffe1c8) at hello_world.c:19
19        printf("The magic word is: %X\n", a + b);
(gdb) print argv[0]
$1 = 0x7fffffffe477 "/homes/iws/<netid>/cse333-23au-<netid>/hw0/hello_world"
(gdb) print a
$2 = -889262067
(gdb) print /x a
$3 = 0xcafef00d
(gdb) print a+b
$4 = -559038737
(gdb) backtrace
#0  main (argc=1, argv=0x7fffffffe1c8) at hello_world.c:19
(gdb) continue
Continuing.
The magic word is: <xxxxxxxx>
[Inferior 1 (process 396554) exited normally]
(gdb) quit
$ 

Part D – Verify No Memory Issues

Throughout the quarter, we'll also be testing whether your code has any memory leaks or other memory errors (e.g., using uninitialized memory). We'll be using Valgrind to do this. Try out Valgrind for yourself so you know how to run it:

$ valgrind --leak-check=full ./hello_world

Note that Valgrind will print out that no memory issues were found. Specifically, look for a line that looks like:

==399152== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

Part E – Check for Style Issues

Another requirement during the quarter is that your code must follow the provided style guidelines. Although there are many opinions about what constitutes "good style," in this course, we will generally follow the Google C++ Style Guide for both C and C++ code. The repository files for this assignment included a Python script cpplint.py to check C source files for style issues. Try it yourself so you know how to run it:

$ ../cpplint.py --clint hello_world.c

No style-checking tool is perfect, but you should try to clean up any problems that cpplint detects unless it flags something that is definitely not a problem in this particular context (but be sure you have very good reasons to ignore any warnings).

Part F – Add a README.md File

Create a README.md file in directory hw0 that contains:

• Your name
• Your UW or CSE email address
• A sentence that reveals the magic word you learned from Part B. Be sure that you actually say the magic word as it was output from the executable; do not just hint at the word or its meaning.

We are not picky about the format of this file as long as it has all this information.