Changeset ed79428 for doc

Timestamp:

Dec 12, 2023, 11:29:06 AM (6 months ago)

Author:

Peter A. Buhr <pabuhr@…>

Branches:

master

Children:

7972603

Parents:

cd79053

Message:

comment out missing lstinputlisting files, fix missing @'s for lstinline code

File:

• doc/theses/mike_brooks_MMath/background.tex (modified) (10 diffs)

doc/theses/mike_brooks_MMath/background.tex

@@ -40 +40 @@
 
 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 +48 @@
 
 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 +176 @@
 
 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 +229 @@
 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 +240 @@
 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 +259 @@
 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 +414 @@
 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 +426 @@
     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 +436 @@
 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 +453 @@
 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)@