Index: doc/theses/aaron_moss_PhD/phd/generic-types.tex
===================================================================
--- doc/theses/aaron_moss_PhD/phd/generic-types.tex	(revision ab3a69c8c78c624b6860ec934d440a484a75f17d)
+++ doc/theses/aaron_moss_PhD/phd/generic-types.tex	(revision 5a80144407d100629a9ee2fe20572861109d286f)
@@ -350,5 +350,5 @@
 Similarly, the layout function can only safely be called from a context where the generic type definition is visible, because otherwise the caller does not know how large to allocate the array of member offsets. 
 
-The C standard does not specify a memory layout for structs, but the POSIX ABI for x86 \cite{POSIX08} does; this memory layout is common for C implementations, but is a platform-specific issue for porting \CFA{}. 
+The C standard does not specify a memory layout for structs, but the System V ABI \cite{SysVABI} does; this memory layout is common for C implementations, but is a platform-specific issue for porting \CFA{}. 
 This algorithm, sketched below in pseudo-\CFA{}, is a straightforward mapping of consecutive fields into the first properly-aligned offset in the !struct! layout; layout functions for !union! types omit the offset array and simply calculate the maximum size and alignment over all union variants. 
 Since \CFACC{} generates a distinct layout function for each type, constant-folding and loop unrolling are applied.