Index: doc/theses/mike_brooks_MMath/background.tex
===================================================================
--- doc/theses/mike_brooks_MMath/background.tex	(revision cd79053e2f038780f8cd5d6679e3cfd90494a658)
+++ doc/theses/mike_brooks_MMath/background.tex	(revision ed79428117309565d8dae6ac6df962d528bae256)
@@ -40,5 +40,5 @@
 
 TODO: typeset
-\lstinputlisting[language=C, firstline=13, lastline=56]{bkgd-c-tyerr.c}
+%\lstinputlisting[language=C, firstline=13, lastline=56]{bkgd-c-tyerr.c}
 
 
@@ -48,5 +48,5 @@
 
 TODO: typeset
-\lstinputlisting[language=C, firstline=35, lastline=116]{bkgd-carray-arrty.c}
+%\lstinputlisting[language=C, firstline=35, lastline=116]{bkgd-carray-arrty.c}
 
 My contribution is enabled by recognizing
@@ -176,5 +176,5 @@
 
 TODO: typeset
-\lstinputlisting[language=C, firstline=4, lastline=26]{bkgd-carray-decay.c}
+%\lstinputlisting[language=C, firstline=4, lastline=26]{bkgd-carray-decay.c}
 
 
@@ -229,10 +229,10 @@
 the parameter's type becomes a type that I summarize as being the array-decayed type.
 The respective handlings of the following two parameter spellings shows that the array-spelled one is really, like the other, a pointer.
-\lstinputlisting[language=C, firstline=40, lastline=44]{bkgd-carray-decay.c}
+%\lstinputlisting[language=C, firstline=40, lastline=44]{bkgd-carray-decay.c}
 As the @sizeof(x)@ meaning changed, compared with when run on a similarly-spelled local variariable declaration,
 GCC also gives this code the warning: ```sizeof' on array function parameter `x' will return size of `float *'.''
 
 The caller of such a function is left with the reality that a pointer parameter is a pointer, no matter how it's spelled:
-\lstinputlisting[language=C, firstline=60, lastline=63]{bkgd-carray-decay.c}
+%\lstinputlisting[language=C, firstline=60, lastline=63]{bkgd-carray-decay.c}
 This fragment gives no warnings.
 
@@ -240,5 +240,5 @@
 Note the opposite meaning of this spelling now, compared with its use in local variable declarations.
 This point of confusion is illustrated in:
-\lstinputlisting[language=C, firstline=80, lastline=87]{bkgd-carray-decay.c}
+%\lstinputlisting[language=C, firstline=80, lastline=87]{bkgd-carray-decay.c}
 The basic two meanings, with a syntactic difference helping to distinguish,
 are illustrated in the declarations of @ca@ vs.\ @cp@,
@@ -259,5 +259,5 @@
 Pointer decay does not affect pointer-to-array types, because these are already pointers, not arrays.
 As a result, a function with a pointer-to-array parameter sees the parameter exactly as the caller does:
-\lstinputlisting[language=C, firstline=100, lastline=110]{bkgd-carray-decay.c}
+%\lstinputlisting[language=C, firstline=100, lastline=110]{bkgd-carray-decay.c}
 
 
@@ -414,5 +414,5 @@
 which type information associated with a polymorphic return type
 replaces @malloc@'s use of programmer-supplied size information.
-\begin{lstinline}
+\begin{lstlisting}
     // C, library
     void * malloc( size_t );
@@ -426,5 +426,5 @@
     tm * el2 = alloc();
     tm (*ar2)[10] = alloc();
-\end{lstinline}
+\end{lstlisting}
 The alloc polymorphic return compiles into a hidden parameter, which receives a compiler-generated argument.
 This compiler's argument generation uses type information from the left-hand side of the initialization to obtain the intended type.
@@ -436,16 +436,16 @@
 In the last example, the choice of ``pointer to array'' @ar2@ breaks a parallel with @ar1@.
 They are not subscripted in the same way.
-\begin{lstinline}
+\begin{lstlisting}
     ar1[5];
     (*ar2)[5];
-\end{lstinline}
+\end{lstlisting}
 Using ``reference to array'' works at resolving this issue.  TODO: discuss connection with Doug-Lea \CC proposal.
-\begin{lstinline}
+\begin{lstlisting}
     tm (&ar3)[10] = *alloc();
     ar3[5];
-\end{lstinline}
+\end{lstlisting}
 The implicit size communication to @alloc@ still works in the same ways as for @ar2@.
 
-Using proper array types (@ar2@ and @ar3@) addresses a concern about using raw element pointers (@ar1), albeit a theoretical one.
+Using proper array types (@ar2@ and @ar3@) addresses a concern about using raw element pointers (@ar1@), albeit a theoretical one.
 TODO xref C standard does not claim that @ar1@ may be subscripted,
 because no stage of interpreting the construction of @ar1@ has it be that ``there is an \emph{array object} here.''
@@ -453,5 +453,5 @@
 where the type requested is an array, making the result, much more obviously, an array object.
 
-The ``reference to array'' type has its sore spots too.  TODO see also dimexpr-match-c/REFPARAM_CALL (under TRY_BUG_1)
+The ``reference to array'' type has its sore spots too.  TODO see also @dimexpr-match-c/REFPARAM_CALL (under TRY_BUG_1)@