Out: Wednesday, April 2, 2025
Due: Monday, April 7, 2024 by 11:59 pm.
| Summary. |
For homework #0, you will fetch a source distribution that we have prepared. Next, you will trivially modify a simple hello world C application, use "make" to compile it, and run it to learn the magic code. You will also run a tool that checks your code for memory leaks and another that checks for potential style problems. Finally, you will package up and submit your code.
As you can probably tell, the real goal of this homework is to make sure that all of the course infrastructure is working for you.
| Part A -- Fetch the code |
Overview
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. We will demonstrate and discuss the process in sections during the first week of class.
Clone your GitLab repository
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 in the CSE 333 GitLab Guide to clone your CSE 333 repository. The Gitlab Guide is also linked to the CSE 333 resources web page, and there are additional links there to the CSE GitLab site and other git resources.
Before cloning the repo, be sure you have run the
git config ... commands described in the CSE 333 Gitlab Guide.
That will set options that will allow you to create and change files
in your GitLab repo without receiving various alarming-looking messages each time.
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.
(Hint: In the Gitlab web interface for your repository there is a little
"clone" button in the top right corner. Click on it and find the string
labeled "ssl". Make a copy of the long git@gitlab...
string and use that in the git clone command below to save
some typing.)
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-25sp-xyzzy,
where xyzzy is your userid) then enter a
ls command. You should see something like this:
bash% git clone git@gitlab.cs.washington.edu:cse333-25sp-students/cse333-25sp-xyzzy.git -- git output appears here bash% cd cse333-25sp-xyzzy bash% 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 binary object code 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.
You should not change this file. Well-intended changes have been known in the past
to cause trouble when new starter files are added to your repo or when trying to push
necessary files to GitLab.
See below for more about cpplint.py.
The exercises directory is mostly empty. It is a place where you can
store your code for cse333 exercise problems. It is especially useful if you want
to discuss an exercise with a TA during online office hours. It will save time if you
push your code in its current state to this folder before you connect with the TA online.
That way you and the TA
can browse your code easily while the two of you are discussing it.
However, this is not the place where you submit your finished exercises
for feedback and grading. You must use gradescope for that.
If you originally cloned your repository before the staff added the
hw0 directory to it, enter a git pull command
to bring your local copy up to date. Once you see the hw0
directory, enter cd hw0 to change into that directory to
work on the assignment.
| Part B -- edit, compile, and run hello_world |
In the hw0 directory, type make. This command will use the instructions in
file Makefile to
compile the hello_world application using the gcc compiler. Run
hello_world by typing the command ./hello_world. You should see
one line of output that looks like:
bash% ./hello_world The magic code is: <xxxxx> bash%
for some <xxxxx>. Now, edit hello_world.c using your
favorite Unix-based editor, and change the
printf so that it instead says:
bash% ./hello_world The magic word is: <xxxxx> bash%
(Notice the one-word change in the message - that's the change you need to make.)
Execute make to rebuild, and then re-run hello_world to make sure
it does what you expect.
Part C -- experience the gdb debugger
|
You're unlikely to have any runtime bugs in this homework, but let's
use the debugger
so that you know what it can do. Here is a session that
launches the debugger, sets a breakpoint on source line 19 of hello_world.c
(the printf function call),
prints the values of a couple of variables and an expression,
prints a "backtrace" of the stack (showing the sequence of procedure calls that led to
executing line 19 of hello_world.c), and then continues execution.
You should first make the changes to the hw0 starter code described above to change
the hello_world output message. You should also make any other changes
needed to the source file, possibly adding your name to the code, and so forth.
Once you've done that and used make to compile the code, we want to run
the program using gdb. Normally we would do that with the gdb command shown
in the transcript below: gdb ./hello_world.
But for this part of hw0, we want to run gdb and capture all of the input
and output to a text file that can be added to our repo. So instead of typing the simple
gdb command we would normally use, you should type the following command
to start gdb and arrange to capture all of the input and
output produced in a new text file
named gdb-demo.txt:
script -c 'gdb ./hello_world' gdb-demo.txt
Once you've started gdb this way,
type the italicized lines in the following transcript starting with the
break 19 command to run your
hello_world program under gdb and try out various gdb commands.
(You may see some differences in gdb or Linux version numbers, or exact addresses
of variables and code, but the data values should be basically the same. If you have
added or deleted lines of code in the program, the printf command may
be at a different line number than line 19; if so, use the correct number
in the break command.)
bash$ 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. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-redhat-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: ... Reading symbols ./hello_world... (gdb) break 19 Breakpoint 1 at 0x401143: file hello_world.c, line 19. (gdb) run Starting program: /home/auser/cse333/hw0/hello_world Breakpoint 1, main (argc=1, argv=0x7fffffffd668) at hello_world.c:19 19 printf("The magic code is: %X\n", a + b); (gdb) print argv[0] $1 = 0x7fffffffe394 "/home/auser/cse333/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=0x7fffffffd668) at hello_world.c:19 (gdb) continue Continuing. The magic code is: <xxxxx> [Inferior 1 (process 6760) exited normally] (gdb) quit bash$
After you type the quit command to exit gdb
you should see a new
gdb-demo.txt file in your hw0 directory
containing a transcript of your gdb session.
You should add this file and push it to your gitlab repository.
Notes: For gdb to be useful, you must use the -g option
for gcc when compiling. The makefile we distributed does that.
Assuming you have already modified your file for part B, as you should, you will see the new output
message after "Continuing."
Most gdb commands can be abbreviated, for instance using p instead of print
or bt instead of backtrace.
The full versions of commands are used in the example above for clarity, but you will quickly want
to learn the abbreviations to speed up your use of gdb.
The script command used to create the gdb-demo.txt file captures
everything that happens on the terminal, including any backspace or delete characters you
might have used to correct input lines. That's expected and you should just leave those
characters in the file - no need to clean them up unless there is so much of this that the file
is badly garbled and hard to read. In that case, please just do this part of the assignment over
again to get a relatively clean version of the transcript file.
| Part D -- verify you have no leaks |
Throughout the quarter, we'll also be testing whether your code has any memory leaks or other memory errors like reading values of uninitialize variables. We'll be using Valgrind to do this. Try out Valgrind for yourself, to be sure you know how run it:
bash% valgrind --leak-check=full ./hello_world
Note that Valgrind prints out that no memory leaks were found in the starter code.
| Part E -- check for style issues |
Another requirement during the quarter is that your code must
be written legibly and follow widely understood good (and safe) coding practices.
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 and C++ source files for style issues. Try it yourself to be sure
you can run it:
bash% ../cpplint.py --clint hello_world.c
(The --clint option tells cpplint that the source file
contains C code. If this option is omitted, cpplint assumes the
source code in the file is C++.)
No style-checking tool is perfect, but you should 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, such as explicit
instructions from the course staff).
Because of historical reasons,
there are occasional problems in the starter code we distribute,
and you are not responsible for
fixing those.
But the code you create should have no reported cpplint.py bugs.
| Part F -- add a README.md file |
Create a README.md file in directory
hw0 that contains:
gcc -v command,
which starts with "gcc version 11...." on the CSE lab machines.
You should be able to copy and
paste this from a terminal window to save typing.
If you see an older version number you should be sure that you are using
the current CSE lab machines, attu servers, or the home virtual machine.We are not picky about the format of this file as long as it has all this information. Be sure to add this file and push it to your GitLab repository.
| Homework Submission |
Once you're done, "turning in" the assignment is logically simple -- create an appropriate tag in your git repository to designate the revision (commit) that the course staff should examine for grading. But there are multiple ways to get this wrong, so you must carefully follow the following steps in this order. The idea is:
1. Tidy up and be sure everything in your hw0 directory is properly committed,
including the updated hello_world.c and the new gdb-demo.txt
and README.md files.
Commit all
of your changes to your repository (see the beginning of the
assignment or the main course web page for links to git
information if you need a refresher on how to do this). Then in the
hw0 directory:
If you see any messages about uncommitted changes or any other indications that the latest version of your code has not been pushed to the GitLab repository, fix those problems and push any unsaved changes before going on. Then repeat the above steps to verify that all is well.bash% git pull bash% make clean bash$ git status On branch master Your branch is up-to-date with 'origin/master'. nothing to commit, working directory clean
2. Tag your repository and push the tag information to GitLab to indicate that the current commit is the version of hw0 that you are submitting for grading:
Do not do this until after you have pushed all parts of yourbash% git tag hw0-final bash% git push --tags
hw0 solution to GitLab in the previous step.
The tag name must be exactly hw0-final.
If it is not, then you have not properly indicated that you have finished this
assignment and you might not receive any credit for it.
3. Check that everything is properly stored and tagged in your repository. To be sure that you really have updated everything properly, create a brand new, empty directory that is nowhere near your regular working directory, clone the repository into the new location, and verify that everything works as expected. It is really, really, REALLY important that this not be nested anywhere inside your regular, working repository directory. Do this:
Use your own userid instead ofbash% cd <somewhere-completely-different> bash% git clone git@gitlab.cs.washington.edu:cse333-25sp-students/cse333-25sp-xyzzy.git bash% cd cse333-25sp-xyzzy bash% git checkout hw0-final bash% ls cpplint.py exercises hw0
xyzzy, of course. The
commands after git clone change to the newly cloned
directory, then cause git to switch to the tagged commit you created
in step 2, above. We will do the same when we examine your files for
grading.
At this point you should see your hw0 directory.
cd into it, run make, run any tests you wish
(something that will be crucial on future assignments). If there are
any problems, immediately erase this newly cloned copy of your
repository (rm -rf cse333-25sp-xyzzy) go back to
your regular working repository, and fix whatever is wrong. It may be
as simple as running a missed git push --tags command if
the tag was not found in the repository. If it requires more
substantive changes, you may need to do a little voodoo to get rid of
the original hw0-final tag from your repository and
re-tag after making your repairs,
To eliminate the hw0-final tag,
do this (this should not normally be necessary):
Then make and commit and push your repairs, and only after all the changes are pushed, repeat the tag and tag push commands from step 2. And then repeat this verification step to be sure that the updated version is actually correct.bash% git tag -d hw0-final bash% git push origin :refs/tags/hw0-final
Note: if you discover that repairs are needed when you check your work, it is crucial that you delete the newly cloned copy and make the repairs back your regular working repository. If you modify files in the cloned copy you may wind up pushing changes to GitLab that will leave your repository in a strange state, and files may appear to mysteriously vanish. Please follow the instructions precisely.
| Grading |
For hw0, we'll give you full credit if you learn the magic code and correctly submit your work with all the requested changes and information.