source: doc/theses/mike_brooks_MMath/intro.tex@ 7d415b4

\chapter{Introduction}

All modern programming languages provide three high-level containers (collections): array, linked-list, and string.
Often array is part of the programming language, while linked-list is built from (recursive) pointer types, and string from a combination of array and linked-list.
For all three types, languages supply varying degrees of high-level mechanism for manipulating these objects at the bulk level and at the component level, such as array copy, slicing and iterating using subscripting.

This work looks at extending these three foundational container types in the programming language \CFA, which is a new dialect of the C programming language.
A primary goal of \CFA~\cite{Cforall} is 99\% backward compatibility with C, while maintaining a look and feel that matches with C programmer experience and intuition.
This goal requires ``thinking inside the box'' to engineer new features that ``work and play'' with C and its massive legacy code-base.
An equally important goal is balancing good performance with safety.


\section{Array}

An array provides a homogeneous container with $O(1)$ access to elements using subscripting.
Higher-level operations like array slicing (single or multidimensional) may have significantly higher cost, but provides a better programmer experience.
The array size can be static, dynamic but fixed after creation, or dynamic and variable after creation.
For static and dynamic-fixed, an array can be stack allocated, while dynamic-variable requires the heap.
Because array layout has contiguous components, subscripting is a computation (some form of pointer arithmetic).


\section{Linked list}

A linked-list provides a homogeneous container often with $O(log N)$/$O(N)$ access to elements using successor and predecessor operations that normally involve pointer chasing.
Subscripting by value is sometimes available, \eg hash table.
Linked types are normally dynamically sized by adding/removing nodes using link fields internal or external to the elements (nodes).
If a programming language allows pointer to stack storage, linked-list types can be allocated on the stack;
otherwise, elements are heap allocated with explicitly/implicitly managed.


\section{String}

A string provides a dynamic array of homogeneous elements, where the elements are (often) some form of human-readable characters.
What differentiates a string from other types in that many of its operations work on groups of elements for scanning and changing, \eg @index@ and @substr@;
subscripting individual elements is usually available, too.
Therefore, the cost of a string operation is usually less important than the power of the operation to accomplish complex text manipulation, \eg search, analysing, composing, and decomposing.
The dynamic nature of a string means storage is normally heap allocated but often implicitly managed, even in unmanaged languages.
In some cases, string management is separate from heap management, \ie strings roll their own heap.


\section{Iterator}

As a side issue to working with complex structured types is iterating through them.
Some thought has been given to \emph{general} versus specific iteration capabilities as part of of this work, but the general iteration work is only a sketch for others as future work.
Nevertheless, sufficed work was done to write out the ideas that developed and how they should apply in the main context of this work. 


\section{Motivation}

The primary motivation for this work is two fold:
\begin{enumerate}[leftmargin=*]
\item
These three aspects of C are difficult to understand, teach, and get right because they are correspondingly low level.
Providing higher-level, feature-rich versions of these containers in \CFA is a major component of the primary goal.
\item
These three aspects of C cause the greatest safety issues because there are few or no safe guards when a programmer misunderstands or misuses these features~\cite{Elliott18, Blache19, Ruef19, Oorschot23}.
Estimates suggest 50\%~\cite{Mendio24} of total reported open-source vulnerabilities occur in C resulting from errors using these facilities (memory errors), providing the major hacker attack-vectors.
\end{enumerate}
Both White House~\cite{WhiteHouse24} and DARPA~\cite{DARPA24} recently released a recommendation to move away from C and \CC, because of cybersecurity threats exploiting vulnerabilities in these older languages.
Hardening these three types goes a long way to make the majority of C programs safer.


While multiple new languages purport to be systems languages replacing C, the reality is that rewriting massive C code-bases is impractical and a non-starter if the new runtime uses garage collection.
Furthermore, these languages must still interact with the underlying C operating system through fragile, type-unsafe, interlanguage-communication.
Switching to \CC is equally impractical as its complex and interdependent type-system (\eg objects, inheritance, templates) means idiomatic \CC code is difficult to use from C, and C programmers must expend significant effort learning \CC.
Hence, rewriting and retraining costs for these languages can be prohibitive for companies with a large C software-base (Google, Apple, Microsoft, Amazon, AMD, Nvidia).


\subsection{C?}

Like many established programming languages, C has a standards committee and multiple ANSI/\-ISO language manuals~\cite{C99,C11,C18,C23}.
However, most programming languages are only partially explained by their standard's manual(s).
When it comes to explaining how C works, the definitive source is the @gcc@ compiler, which is mimicked by other C compilers, such as Clang~\cite{clang}.
Often other C compilers must mimic @gcc@ because a large part of the C library (runtime) system (@glibc@ on Linux) contains @gcc@ features.
While some key aspects of C need to be explained and understood by quoting from the language reference manual, to illustrate actual program semantics, this thesis uses constructs a program whose behaviour exercises a particular point and then confirms the behaviour by running the program.
These example programs show
\begin{itemize}[leftmargin=*]
        \item if the compiler accepts or rejects certain syntax,
        \item prints output to buttress a behavioural claim,
        \item or executes without triggering any embedded assertions testing pre/post-assertions or invariants.
\end{itemize}
This work has been tested across @gcc@ versions 8--14 and clang versions 10--14 running on ARM, AMD, and Intel architectures.
Any discovered anomalies among compilers or versions is discussed.
In all case, it is never clear whether the \emph{truth} lies in the compiler(s) or the C standard.


\section{Contributions}

This work has produced significant syntactic and semantic improvements to C's arrays, linked-lists and string types.
As well, a strong plan for general iteration has been sketched out.

\subsection{Linked list}

\subsection{Array}

\subsection{String}

\subsection{Iterator}