Out: Wednesday, June 22, 2022
Due: Monday, June 27, 2022 by 11:59 pm.
The goal of Homework 0 is to make sure that all of the course infrastructure is working for you:
maketo compile it, and run it to learn the magic code.
gcc -vfrom the terminal and check that the output displays a version string indicating you are using gcc9. If it displays something else, refer to the instructions in Exercise 1 here.
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.
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 Git Setup page to clone your CSE 333 repository. There is also additional information further down that page on Developing with Git.
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
xyzzy is your userid) then enter a
ls command. You should see something like this:
bash$ git clone email@example.com:cse333-22su-students/cse333-22su-xyzzy.git -- git output appears here bash$ cd cse333-22su-xyzzy bash$ ls -a .gitignore clint.py exercises hw0
.gitignorefile 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.
exercisesdirectory 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.
hw0directory to it, enter a
git pullcommand to bring your local copy up to date. Once you see the
cd hw0to change into that directory to work on the assignment.
hw0 directory, run
This command will use the instructions in file
to compile the
hello_world executable using the
Run the executable by entering the command
You should see one line of output that looks like:
bash$ ./hello_world The magic code is: <xxxxx> bash$
for some <xxxxx>.
hello_world.c in the CSE Linux environment
using your favorite editor,
and change the
printf so that it instead says:
bash$ ./hello_world The magic word is: <xxxxx> bash$
make to rebuild, and then re-run
./hello_world to make sure that it does what you expect.
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:
hello_world.c), and then
You should type the lines shown in italics. You may see some differences in version numbers or exact addresses, but the data values should be basically the same.
gccwhen compiling. The
Makefilewe distributed does that.
bash$ gdb ./hello_world GNU gdb (GDB) Red Hat Enterprise Linux 8.3-1.el8 Copyright (C) 2019 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 $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: <xxxxxxxx> [Inferior 1 (process 6760) exited normally] (gdb) quit bash$
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:
bash$ valgrind --leak-check=full ./hello_world
Note that Valgrind will print out that no memory issues were found.
clint.py to check C source files for style issues.
Try it yourself so you know how to run it:
bash$ ../clint.py hello_world.c
No style-checking tool is perfect, but you should try to clean up any problems that clint detects unless clint flags something that is definitely not a problem in this particular context (but be sure you have very good reasons to ignore any warnings).
README.md file in directory hw0 that
We are not picky about the format of this file as long as it has all this information.
Once you're done, "turning in" the assignment is done by creating 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 should carefully follow the following steps in this order. The basic idea is:
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
Then in the
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
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.
Tag your repository and push the tag information to GitLab to indicate that the current commit is the version that you are submitting for grading:
bash$ git tag hw0-final bash$ git push --tags
Do not do this until after you have pushed all parts of your homework solution to GitLab.
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.
bash$ cd <somewhere-completely-different> bash$ git clone firstname.lastname@example.org:cse333-22su-students/cse333-22su-xyzzy.git bash$ cd cse333-22su-xyzzy bash$ git checkout hw0-final bash$ ls clint.py exercises hw0
Use your own userid instead of
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
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-22su-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 the following (this
should not normally be necessary):
bash$ git tag -d hw0-final bash$ git push origin :refs/tags/hw0-final
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.
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.
For hw0, we'll give you full credit if you learn the magic code and correctly submit your work.