If you've forgotten how to modify your shell startup files
(e.g., so that your PATH environment variable includes a specific
directory automatically when you log in, or how to add a command
alias), please refresh your memory.
If you don't know how to use grep, it is probably wise
to look into that.
For example, if given a large source tree, know how to use grep
to find all mentions of a function. There are other ways to do this!
Some people might prefer cscope, in which case
it's ok to know how to use both of them.
As another example: list name of all the files in a source tree
that contain the string "increment", the string "decrement", or both,
without regard to capitalization of those strings.
What short command could one type to determine which C source
file in the current directory contains the most (or least) lines?
There are multiple ways to do this.
If you don't know how to use find, it is probably wise
to look into that.
For example, list assembly-language files in a source
tree whose file name contains the string "tree".
It is probably useful to install an X server on your personal
machine. To make sure you have it working, SSH into LINUX.ANDREW
and run xrefresh
, xeyes
,
and/or xclock
.
The textbook information includes some optional additional
readings.
If you are proficient at banging out code that runs ok but gets
complaints from project partners,
it would probably be productive to read
The Practice of Programming,
at least the first few chapters.
Again, this is optional!
But some students do start the semester writing code exhibiting
features which are not best practices in any programming language.
This is a good semester to write good code,
and there are books that discuss how to do that.
Speaking of textbooks, if your relationship with 15-213/513
didn't involve a lot of textbook time,
please be aware that we expect you to be able to apply
a 213-level understanding of relevant 213 topics,
including files and directories, file I/O, signals,
and virtual memory,
in addition to the absolutely core machine-model material
on instructions, registers, and caches.
If you are fuzzy on any of this,
the 213 textbook contains excellent refresher material!
Speaking of 213, it is probably a good idea for you to
re-read most of the code you submitted.
Probably the Malloc lab and the Shell lab are the most
directly applicable.
If there is anything in the code you submitted that you no longer
understand, please remedy that!
It is a good idea to be familiar with C conventions.
For example, it is generally not the case that a void *
is a pointer.
If seeing a
void *
parameter,
or a void **
parameter,
in a function prototype would be confusing,
this would be a good area to look into.
You should know what sizeof()
is for,
and be prepared to use it.
If you like to watch videos, this one might be interesting:
SREcon14 - Keys to SRE, Ben Treynor,
Jun 26, 2014.
And if you like to read papers, this might be eye-opening:
A Few Billion Lines of Code Later: using static analysis to find bugs in the real world.
If you are interested in writing small amounts of dangerous
code, these may be of interest:
From Debugging to Integrity in Coding (Dan O'Dowd, Fall 2017);
Software That Never Fails and Can't Be Hacked (Dan O'Dowd, June 11, 2021).