Index: doc/theses/mike_brooks_MMath/background.tex
===================================================================
--- doc/theses/mike_brooks_MMath/background.tex	(revision 703885e1b67c8bd1f6f9853eeb243e626a6c1023)
+++ doc/theses/mike_brooks_MMath/background.tex	(revision 4fc7388ea88eb10cdb80bc09e77bf2758b6beb01)
@@ -714,7 +714,7 @@
 \begin{c++}
 uSequence<NodeDL> sequence;
-sequence.add_front( node.nodeseq );		$\C{// link fields in embedded type}$
-NodeDL nodedl = sequence.remove( node.nodeseq );
-int i = nodedl.get().i;					$\C{// indirection to node}$
+sequence.add_front( @node.nodeseq@ );	$\C{// link fields in embedded type}$
+NodeDL nodedl = sequence.remove( @node.nodeseq@ );
+int i = nodedl.@get()@.i;				$\C{// indirection to node}$
 \end{c++}
 Hence, the \uCpp approach optimizes one set of intrusive links through the \CC inheritance mechanism, and falls back onto the LQ approach of explicit declarations for additional intrusive links.
@@ -803,15 +803,15 @@
 Technically, a string is an array whose elements are single characters.
 The compiler automatically places the null character @\0@ at the end of each such string, so programs can conveniently find the end.
-This representation means that there is no real limit to how long a string can be, but programs have to scan one completely to determine its length.
+This representation means that there is no real limit to how long a string can be, but programs have to scan one completely to determine its length.~\cite[p.~36]{C:old}
 \end{quote}
 Unfortunately, this design decision is both unsafe and inefficient.
-It is common error in C to forget the space in a character array for the terminator or overwrite the terminator, resulting in array overruns in string operations.
+It is common error in C to forget the storage in a character array for the terminator or overwrite the terminator, resulting in array overruns in string operations.
 The need to repeatedly scan an entire string to determine its length can result in significant cost, as it is impossible to cache the length in many cases.
 
 C strings are fixed size because arrays are used for the implementation.
-However, string manipulation commonly results in dynamically-sized temporary and final string values.
+However, string manipulation commonly results in dynamically-sized temporary and final string values, \eg @strcpy@, @strcat@, @strcmp@, @strlen@, @strstr@, \etc.
 As a result, storage management for C strings is a nightmare, quickly resulting in array overruns and incorrect results.
 
 Collectively, these design decisions make working with strings in C, awkward, time consuming, and unsafe.
-While there are companion string routines that take the maximum lengths of strings to prevent array overruns, that means the semantics of the operation can fail because strings are truncated.
-Suffice it to say, C is not a go-to language for string applications, which is why \CC introduced the @string@ type.
+While there are companion string routines that take the maximum lengths of strings to prevent array overruns, \eg @strncpy@, @strncat@, @strncpy@, that means the semantics of the operation can fail because strings are truncated.
+Suffice it to say, C is not a go-to language for string applications, which is why \CC introduced the dynamically-sized @string@ type.