Project 1

goto:
	Actually used a lot in the kernel
	Example:  How often?
	Considered harmful
		- Which is harmful

Bitwise arithmatic refresher:
	and and or are the most common
	logical vs. bitwise operators
	Turning a single bit on or off
	Use hex for constants, to keep your head screwed on straight

Macros:
	#define, for simple stuff like constants
	#defines that look like functions (but aren't functions)
		When to use this feature?
	The project 1 function definition macro

Now project 1 should (hopefully) make sense!
	One thing people ask about:  The array of functions
		Generated using a macro
		Let's go over it, and the rest of the project too
	The last problem is the easiest

Pointers:
	Pointers are 64-bit unsigned integers
	Pointers can point to any type, since it's just a number
	Use size_t for data structure sizes
	ssize_t for signed size_t (why is this ok?)
	sizeof returns the size of variables
	Pointer arithmatic example:  Iteration
		- Example:  Sum of an array
		- Example:  Encrypt a string with shift of 13 (if time permits)
		- Example:  Square each number in an array
		- Incrementation amount determined by type
		- Either direction is possible
	void* can point to anything!
	Programs can write to anywhere they're allowed to write to
		- Example:  Change a different variable
	Passing pointers to functions:  Sort of a manual pass-by-reference

Allocating Memory:
	malloc and free
	calloc
	Don't forget to deallocate!
	Arrays vs. Python lists, and realloc
		- Userspace:  C++ vector
		- Kernel:  Kernel linked lists

Notes about linking:
	We'll build, but not link, a file with a C function
	Then later, write a program that uses it
	Does it work if we build with clang on one file, and gcc on another?
	If we compile the library on FreeBSD?
	If we engineer a name conflict?
	Inefficiency of static linking
		Multifunction machines to save space
	Dynamic linking instead with .so files
		kernel will use .ko