Index: doc/theses/mike_brooks_MMath/background.tex
===================================================================
--- doc/theses/mike_brooks_MMath/background.tex	(revision b8cb388b580011a7a3f6688e6395b22a3d7cb0ad)
+++ doc/theses/mike_brooks_MMath/background.tex	(revision b5bfb16ea228f5a456e0a4c2f07fb56ac6186cae)
@@ -6,36 +6,48 @@
 \section{Array}
 
-When a programmer works with an array, C semantics provide access to a type that is different in every way from ``pointer to its first element.''
-Its qualities become apparent by inspecting the declaration
+At the start, the C programming language made a significant design mistake.
+\begin{quote}
+In C, there is a strong relationship between pointers and arrays, strong enough that pointers and arrays really should be treated simultaneously.
+Any operation which can be achieved by array subscripting can also be done with pointers.~\cite[p.~93]{C:old}
+\end{quote}
+Accessing any storage requires pointer arithmetic, even if it is just base-displacement addressing in an instruction.
+The conjoining of pointers and arrays could also be applied to structures, where a pointer references a structure field like an array element.
+Finally, while subscripting involves pointer arithmetic (as does field references @x.y.z@), it is very complex for multi-dimensional arrays and requires array descriptors to know stride lengths along dimensions.
+Many C errors result from performing pointer arithmetic instead of using subscripting.
+Some C textbooks erroneously teach pointer arithmetic suggesting it is faster than subscripting.
+
+C semantics want a programmer to \emph{believe} an array variable is a ``pointer to its first element.''
+This desire becomes apparent by a detailed inspection of an array declaration.
 \lstinput{34-34}{bkgd-carray-arrty.c}
 The inspection begins by using @sizeof@ to provide definite program semantics for the intuition of an expression's type.
-Assuming a target platform keeps things concrete:
 \lstinput{35-36}{bkgd-carray-arrty.c}
-Consider the sizes of expressions derived from @a@, modified by adding ``pointer to'' and ``first element'' (and including unnecessary parentheses to avoid confusion about precedence).
+Now consider the sizes of expressions derived from @ar@, modified by adding ``pointer to'' and ``first element'' (and including unnecessary parentheses to avoid confusion about precedence).
 \lstinput{37-40}{bkgd-carray-arrty.c}
-That @a@ takes up 40 bytes is common reasoning for C programmers.
-Set aside for a moment the claim that this first assertion is giving information about a type.
-For now, note that an array and a pointer to its first element are, sometimes, different things.
-
-The idea that there is such a thing as a pointer to an array may be surprising.
-It is not the same thing as a pointer to the first element:
+Given the size of @float@ is 4, the size of @ar@ with 10 floats being 40 bytes is common reasoning for C programmers.
+Equally, C programmers know the size of a \emph{pointer} to the first array element is 8 (or 4 depending on the addressing architecture).
+% Now, set aside for a moment the claim that this first assertion is giving information about a type.
+Clearly, an array and a pointer to its first element are different things.
+
+In fact, the idea that there is such a thing as a pointer to an array may be surprising and it is not the same thing as a pointer to the first element.
 \lstinput{42-45}{bkgd-carray-arrty.c}
-The first gets
+The first assignment gets
 \begin{cfa}
 warning: assignment to `float (*)[10]' from incompatible pointer type `float *'
 \end{cfa}
-and the second gets the opposite.
-
-We now refute a concern that @sizeof(a)@ is reporting on special knowledge from @a@ being an local variable,
-say that it is informing about an allocation, rather than simply a type.
-
-First, recognizing that @sizeof@ has two forms, one operating on an expression, the other on a type, we observe that the original answers are unaffected by using the type-parameterized form:
-\lstinput{46-50}{bkgd-carray-arrty.c}
-Finally, the same sizing is reported when there is no allocation at all, and we launch the analysis instead from the pointer-to-array type.
+and the second assignment gets the opposite.
+
+The inspection now refutes any suggestion that @sizeof@ is informing about allocation rather than type information.
+Note, @sizeof@ has two forms, one operating on an expression and the other on a type.
+Using the type form yields the same results as the prior expression form.
+\lstinput{46-49}{bkgd-carray-arrty.c}
+The results are also the same when there is \emph{no allocation} using a pointer-to-array type.
 \lstinput{51-57}{bkgd-carray-arrty.c}
-So, in spite of considerable programmer success enabled by an understanding that an array just a pointer to its first element (revisited TODO pointer decay), this understanding is simplistic.
-
-A shortened form for declaring local variables exists, provided that length information is given in the initializer:
-\lstinput{59-63}{bkgd-carray-arrty.c}
+Hence, in all cases, @sizeof@ is informing about type information.
+
+So, thinking of an array as a pointer to its first element is too simplistic an analogue and it is not backed up the type system.
+This misguided analogue can be forced onto single-dimension arrays but there is no advantage other than possibly teaching beginning programmers about basic runtime array-access.
+
+Continuing, a shortened form for declaring local variables exists, provided that length information is given in the initializer:
+\lstinput{59-62}{bkgd-carray-arrty.c}
 In these declarations, the resulting types are both arrays, but their lengths are inferred.
 
@@ -102,5 +114,5 @@
 It shows how to spell the types under discussion,
 along with interactions with orthogonal (but easily confused) language features.
-Alterrnate spellings are listed withing a row.
+Alternate spellings are listed within a row.
 The simplest occurrences of types distinguished in the preceding discussion are marked with $\triangleright$.
 The Type column gives the spelling used in a cast or error message (though note Section TODO points out that some types cannot be casted to).
@@ -227,5 +239,5 @@
 \lstinput{9-9}{bkgd-carray-decay.c}
 The validity of this initialization is unsettling, in the context of the facts established in the last section.
-Notably, it initializes name @pa0x@ from expression @a@, when they are not of the same type:
+Notably, it initializes name @pa0x@ from expression @ar@, when they are not of the same type:
 \lstinput{10-10}{bkgd-carray-decay.c}
 
@@ -241,12 +253,12 @@
 This phenomenon is the famous ``pointer decay,'' which is a decay of an array-typed expression into a pointer-typed one.
 
-It is worthy to note that the list of exception cases does not feature the occurrence of @a@ in @a[i]@.
+It is worthy to note that the list of exception cases does not feature the occurrence of @ar@ in @ar[i]@.
 Thus, subscripting happens on pointers, not arrays.
 
-Subscripting proceeds first with pointer decay, if needed.  Next, ARM-6.5.2.1.2 explains that @a[i]@ is treated as if it were @(*((a)+(i)))@.
-ARM-6.5.6.8 explains that the addition, of a pointer with an integer type,  is defined only when the pointer refers to an element that is in an array, with a meaning of ``@i@ elements away from,'' which is valid if @a@ is big enough and @i@ is small enough.
+Subscripting proceeds first with pointer decay, if needed.  Next, ARM-6.5.2.1.2 explains that @ar[i]@ is treated as if it were @(*((a)+(i)))@.
+ARM-6.5.6.8 explains that the addition, of a pointer with an integer type,  is defined only when the pointer refers to an element that is in an array, with a meaning of ``@i@ elements away from,'' which is valid if @ar@ is big enough and @i@ is small enough.
 Finally, ARM-6.5.3.2.4 explains that the @*@ operator's result is the referenced element.
 
-Taken together, these rules also happen to illustrate that @a[i]@ and @i[a]@ mean the same thing.
+Taken together, these rules also happen to illustrate that @ar[i]@ and @i[a]@ mean the same thing.
 
 Subscripting a pointer when the target is standard-inappropriate is still practically well-defined.
@@ -255,5 +267,5 @@
 the fact that C is famously both generally high-performance, and specifically not bound-checked,
 leads to an expectation that the runtime handling is uniform across legal and illegal accesses.
-Moreover, consider the common pattern of subscripting on a malloc result:
+Moreover, consider the common pattern of subscripting on a @malloc@ result:
 \begin{cfa}
 float * fs = malloc( 10 * sizeof(float) );
@@ -280,5 +292,5 @@
 The respective handlings of the following two parameter spellings shows that the array-spelled one is really, like the other, a pointer.
 \lstinput{12-16}{bkgd-carray-decay.c}
-As the @sizeof(x)@ meaning changed, compared with when run on a similarly-spelled local variariable declaration,
+As the @sizeof(x)@ meaning changed, compared with when run on a similarly-spelled local variable declaration,
 GCC also gives this code the warning: ```sizeof' on array function parameter `x' will return size of `float *'.''
 
@@ -295,13 +307,13 @@
 whose subsequent @edit@ calls behave differently.
 The syntax-caused confusion is in the comparison of the first and last lines,
-both of which use a literal to initialze an object decalared with spelling @T x[]@.
+both of which use a literal to initialize an object declared with spelling @T x[]@.
 But these initialized declarations get opposite meanings,
 depending on whether the object is a local variable or a parameter.
 
 
-In sumary, when a funciton is written with an array-typed parameter,
+In summary, when a function is written with an array-typed parameter,
 \begin{itemize}
 	\item an appearance of passing an array by value is always an incorrect understanding
-	\item a dimension value, if any is present, is ignorred
+	\item a dimension value, if any is present, is ignored
 	\item pointer decay is forced at the call site and the callee sees the parameter having the decayed type
 \end{itemize}
@@ -366,5 +378,5 @@
 	assert( 0 < n && n < 1000 );
 
-	float a[n];
+	float ar[n];
 	float b[10];
 
@@ -372,6 +384,6 @@
 }
 \end{cfa}
-This arrangement allocates @n@ elements on the @main@ stack frame for @a@, just as it puts 10 elements on the @main@ stack frame for @b@.
-The variable-sized allocation of @a@ is provided by @alloca@.
+This arrangement allocates @n@ elements on the @main@ stack frame for @ar@, just as it puts 10 elements on the @main@ stack frame for @b@.
+The variable-sized allocation of @ar@ is provided by @alloca@.
 
 In a situation where the array sizes are not known to be small enough for stack allocation to be sensible, corresponding heap allocations are achievable as:
@@ -440,5 +452,5 @@
 As in the last section, we inspect the declaration ...
 \lstinput{16-18}{bkgd-carray-mdim.c}
-The significant axis of deriving expressions from @a@ is now ``itself,'' ``first element'' or ``first grand-element (meaning, first element of first element).''
+The significant axis of deriving expressions from @ar@ is now ``itself,'' ``first element'' or ``first grand-element (meaning, first element of first element).''
 \lstinput{20-44}{bkgd-carray-mdim.c}
 
Index: doc/theses/mike_brooks_MMath/programs/bkgd-carray-arrty.c
===================================================================
--- doc/theses/mike_brooks_MMath/programs/bkgd-carray-arrty.c	(revision b8cb388b580011a7a3f6688e6395b22a3d7cb0ad)
+++ doc/theses/mike_brooks_MMath/programs/bkgd-carray-arrty.c	(revision b5bfb16ea228f5a456e0a4c2f07fb56ac6186cae)
@@ -32,34 +32,34 @@
 
 int main() {
-	float a[10];
-	static_assert(sizeof(float) == 4);		$\C{// floats (array elements) are 4 bytes}$
-	static_assert(sizeof(void*) == 8);		$\C{// pointers are 8 bytes}$
-	static_assert(sizeof(a) == 40);			$\C{// array}$
-	static_assert(sizeof(&a) == 8 );		$\C{// pointer to array}$
-	static_assert(sizeof(a[0]) == 4 );		$\C{// first element}$
-	static_assert(sizeof(&(a[0])) == 8 );	$\C{// pointer to first element}$
+	float ar[10];
+	static_assert( sizeof(float) == 4 );	$\C{// floats (array elements) are 4 bytes}$
+	static_assert( sizeof(void*) == 8 );	$\C{// pointers are 8 bytes}$
+	static_assert( sizeof(ar) == 40 );		$\C{// array}$
+	static_assert( sizeof(&ar) == 8 );		$\C{// pointer to array}$
+	static_assert( sizeof(ar[0]) == 4 );	$\C{// first element}$
+	static_assert( sizeof(&(ar[0])) == 8 );	$\C{// pointer to first element}$
 
-	typeof(&a) x;							$\C{// x is pointer to array}$
-	typeof(&(a[0])) y;						$\C{// y is pointer to first element}$
+	typeof(&ar) x = &ar;					$\C{// x is pointer to array}$
+	typeof(&(ar[0])) y = &ar[0];			$\C{// y is pointer to first element}$
 	@x = y;@								$\C{// ill-typed}$
 	@y = x;@								$\C{// ill-typed}$
-	static_assert(sizeof(typeof(a)) == 40);
-	static_assert(sizeof(typeof(&a)) == 8 );
-	static_assert(sizeof(typeof(a[0])) == 4 );
-	static_assert(sizeof(typeof(&(a[0]))) == 8 );
+	static_assert( sizeof(typeof(ar)) == 40 ); $\C{// array}$
+	static_assert( sizeof(typeof(&ar)) == 8 );	$\C{// pointer to array}$
+	static_assert( sizeof(typeof(ar[0])) == 4 ); $\C{// first element}$
+	static_assert( sizeof(typeof(&(ar[0]))) == 8 ); $\C{// pointer to first element}$
 
 	void f( float (*pa)[10] ) {
-	    static_assert(sizeof(   *pa     ) == 40); $\C{// array}$
-	    static_assert(sizeof(    pa     ) == 8 ); $\C{// pointer to array}$
-	    static_assert(sizeof(  (*pa)[0] ) == 4 ); $\C{// first element}$
-	    static_assert(sizeof(&((*pa)[0])) == 8 ); $\C{// pointer to first element}$
+		static_assert( sizeof( *pa ) == 40 ); $\C{// array}$
+		static_assert( sizeof( pa ) == 8 );	$\C{// pointer to array}$
+		static_assert( sizeof( (*pa)[0] ) == 4 ); $\C{// first element}$
+		static_assert( sizeof(&((*pa)[0])) == 8 ); $\C{// pointer to first element}$
 	}
-	f( & a );
+	f( &ar );
 
 	float fs[] = {3.14, 1.707};
 	char cs[] = "hello";
-
 	static_assert( sizeof(fs) == 2 * sizeof(float) );
 	static_assert( sizeof(cs) == 6 * sizeof(char) );  $\C{// 5 letters + 1 null terminator}$
+
 }
 
@@ -144,8 +144,8 @@
 void stx2() { const T x[10];
 //            x[5] = 3.14; // bad
-	        }
+			}
 void stx3() { T const x[10];
 //            x[5] = 3.14; // bad
-	        }
+			}
 
 // Local Variables: //