Changeset 90152a4 for doc/user/user.tex


Ignore:
Timestamp:
Aug 27, 2018, 4:40:34 PM (8 years ago)
Author:
Rob Schluntz <rschlunt@…>
Branches:
ADT, arm-eh, ast-experimental, cleanup-dtors, enum, forall-pointer-decay, jacob/cs343-translation, jenkins-sandbox, master, new-ast, new-ast-unique-expr, pthread-emulation, qualifiedEnum, stuck-waitfor-destruct
Children:
b7c89aa
Parents:
f9feab8 (diff), 305581d (diff)
Note: this is a merge changeset, the changes displayed below correspond to the merge itself.
Use the (diff) links above to see all the changes relative to each parent.
Message:

Merge branch 'master' into cleanup-dtors

File:
1 edited

Legend:

Unmodified
Added
Removed

  • doc/user/user.tex

    rf9feab8 r90152a4  
    11%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -*- Mode: Latex -*- %%%%%%%%%%%%%%%%%%%%%%%%%%%%
    2 %% 
     2%%
    33%% Cforall Version 1.0.0 Copyright (C) 2016 University of Waterloo
    44%%
    55%% The contents of this file are covered under the licence agreement in the
    66%% file "LICENCE" distributed with Cforall.
    7 %% 
    8 %% user.tex -- 
    9 %% 
     7%%
     8%% user.tex --
     9%%
    1010%% Author           : Peter A. Buhr
    1111%% Created On       : Wed Apr  6 14:53:29 2016
    1212%% Last Modified By : Peter A. Buhr
    13 %% Last Modified On : Mon Nov 27 18:09:59 2017
    14 %% Update Count     : 3143
     13%% Last Modified On : Thu Jul 26 17:29:05 2018
     14%% Update Count     : 3366
    1515%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
    1616
    … …  
    4040\usepackage[dvips,plainpages=false,pdfpagelabels,pdfpagemode=UseNone,colorlinks=true,pagebackref=true,linkcolor=blue,citecolor=blue,urlcolor=blue,pagebackref=true,breaklinks=true]{hyperref}
    4141\usepackage{breakurl}
    42 \renewcommand{\UrlFont}{\small\sf}
    4342
    4443\usepackage[pagewise]{lineno}
    … …  
    7372
    7473% Names used in the document.
    75 \newcommand{\Version}{\input{../../version}}
     74\newcommand{\Version}{\input{build/version}}
    7675\newcommand{\Textbf}[2][red]{{\color{#1}{\textbf{#2}}}}
    7776\newcommand{\Emph}[2][red]{{\color{#1}\textbf{\emph{#2}}}}
    … …  
    147146\CFA adds many modern programming-language features that directly lead to increased \emph{\Index{safety}} and \emph{\Index{productivity}}, while maintaining interoperability with existing C programs and achieving similar performance.
    148147Like C, \CFA is a statically typed, procedural (non-\Index{object-oriented}) language with a low-overhead runtime, meaning there is no global \Index{garbage-collection}, but \Index{regional garbage-collection}\index{garbage-collection!regional} is possible.
    149 The primary new features include parametric-polymorphic routines and types, exceptions, concurrency, and modules.
     148The primary new features include polymorphic routines and types, exceptions, concurrency, and modules.
    150149
    151150One of the main design philosophies of \CFA is to ``\Index{describe not prescribe}'', which means \CFA tries to provide a pathway from low-level C programming to high-level \CFA programming, but it does not force programmers to ``do the right thing''.
    … …  
    156155As well, new programs can be written in \CFA using a combination of C and \CFA features.
    157156
    158 \Index*[C++]{\CC{}} had a similar goal 30 years ago, allowing object-oriented programming to be incrementally added to C.
    159 However, \CC currently has the disadvantages of a strong object-oriented bias, multiple legacy design-choices that cannot be updated, and active divergence of the language model from C, all of which requires significant effort and training to incrementally add \CC to a C-based project.
     157\Index*[C++]{\CC{}}~\cite{c++:v1} had a similar goal 30 years ago, allowing object-oriented programming to be incrementally added to C.
     158However, \CC currently has the disadvantages of a strong object-oriented bias, multiple legacy design-choices that cannot be updated, and active divergence of the language model from C, requiring significant effort and training to incrementally add \CC to a C-based project.
    160159In contrast, \CFA has 30 years of hindsight and a clean starting point.
    161160
    162161Like \Index*[C++]{\CC{}}, there may be both an old and new ways to achieve the same effect.
    163 For example, the following programs compare the \CFA, C, and \CC I/O mechanisms, where the programs output the same result.
    164 \begin{quote2}
     162For example, the following programs compare the C, \CFA, and \CC I/O mechanisms, where the programs output the same result.
     163\begin{center}
    165164\begin{tabular}{@{}l@{\hspace{1.5em}}l@{\hspace{1.5em}}l@{}}
    166165\multicolumn{1}{c@{\hspace{1.5em}}}{\textbf{C}} & \multicolumn{1}{c}{\textbf{\CFA}}     & \multicolumn{1}{c}{\textbf{\CC}}      \\
    … …  
    192191\end{cfa}
    193192\end{tabular}
    194 \end{quote2}
     193\end{center}
    195194While the \CFA I/O looks similar to the \Index*[C++]{\CC{}} output style, there are important differences, such as automatic spacing between variables as in \Index*{Python} (see~\VRef{s:IOLibrary}).
    196195
    … …  
    198197
    199198This document is a programmer reference-manual for the \CFA programming language.
    200 The manual covers the core features of the language and runtime-system, with simple examples illustrating syntax and semantics of each feature.
     199The manual covers the core features of the language and runtime-system, with simple examples illustrating syntax and semantics of features.
    201200The manual does not teach programming, \ie how to combine the new constructs to build complex programs.
    202 A reader should already have an intermediate knowledge of control flow, data structures, and concurrency issues to understand the ideas presented, as well as some experience programming in C/\CC.
     201The reader must have an intermediate knowledge of control flow, data structures, and concurrency issues to understand the ideas presented, as well as some experience programming in C/\CC.
    203202Implementers should refer to the \CFA Programming Language Specification for details about the language syntax and semantics.
    204203Changes to the syntax and additional features are expected to be included in later revisions.
    … …  
    207206\section{Why fix C?}
    208207
    209 The C programming language is a foundational technology for modern computing with millions of lines of code implementing everything from commercial operating-systems (especially UNIX systems) to hobby projects.
     208The C programming language is a foundational technology for modern computing with millions of lines of code implementing everything from hobby projects to commercial operating-systems.
    210209This installation base and the programmers producing it represent a massive software-engineering investment spanning decades and likely to continue for decades more.
    211210Even with all its problems, C continues to be popular because it allows writing software at virtually any level in a computer system without restriction.
    212211For system programming, where direct access to hardware, storage management, and real-time issues are a requirement, C is usually the only language of choice.
    213 The TIOBE index~\cite{TIOBE} for March 2016 showed the following programming-language popularity: \Index*{Java} 20.5\%, C 14.5\%, \Index*[C++]{\CC{}} 6.7\%, \Csharp 4.3\%, \Index*{Python} 4.3\%, where the next 50 languages are less than 3\% each with a long tail.
    214 As well, for 30 years, C has been the number 1 and 2 most popular programming language:
     212The TIOBE index~\cite{TIOBE} for July 2018 ranks the top 5 most \emph{popular} programming languages as: \Index*{Java} 16\%, C 14\%, \Index*[C++]{\CC{}} 7.5\%, Python 6\%, Visual Basic 4\% = 47.5\%, where the next 50 languages are less than 4\% each, with a long tail.
     213The top 3 rankings over the past 30 years are:
    215214\begin{center}
    216 \setlength{\tabcolsep}{1.5ex}
    217 \begin{tabular}{@{}r|c|c|c|c|c|c|c@{}}
    218 Ranking & 2016  & 2011  & 2006  & 2001  & 1996  & 1991  & 1986          \\
    219 \hline
    220 Java    & 1             & 1             & 1             & 3             & 29    & -             & -                     \\
    221 \hline
    222 \R{C}   & \R{2} & \R{2} & \R{2} & \R{1} & \R{1} & \R{1} & \R{1}         \\
    223 \hline
    224 \CC             & 3             & 3             & 3             & 2             & 2             & 2             & 7                     \\
     215\setlength{\tabcolsep}{10pt}
     216\begin{tabular}{@{}rccccccc@{}}
     217                & 2018  & 2013  & 2008  & 2003  & 1998  & 1993  & 1988  \\ \hline
     218Java    & 1             & 2             & 1             & 1             & 16    & -             & -             \\
     219\R{C}   & \R{2} & \R{1} & \R{2} & \R{2} & \R{1} & \R{1} & \R{1} \\
     220\CC             & 3             & 4             & 3             & 3             & 2             & 2             & 5             \\
    225221\end{tabular}
    226222\end{center}
    227223Hence, C is still an extremely important programming language, with double the usage of \Index*[C++]{\CC{}}; in many cases, \CC is often used solely as a better C.
    228224Love it or hate it, C has been an important and influential part of computer science for 40 years and its appeal is not diminishing.
    229 Unfortunately, C has many problems and omissions that make it an unacceptable programming language for modern needs.
     225Nevertheless, C has many problems and omissions that make it an unacceptable programming language for modern needs.
    230226
    231227As stated, the goal of the \CFA project is to engineer modern language-features into C in an evolutionary rather than revolutionary way.
    … …  
    237233These languages have different syntax and semantics from C, do not interoperate directly with C, and are not systems languages because of restrictive memory-management or garbage collection.
    238234As a result, there is a significant learning curve to move to these languages, and C legacy-code must be rewritten.
    239 These costs can be prohibitive for many companies with a large software-base in C/\CC, and a significant number of programmers require retraining to the new programming language.
    240 
    241 The result of this project is a language that is largely backwards compatible with \Index*[C11]{\Celeven{}}~\cite{C11}, but fixes many of the well known C problems while containing modern language-features.
    242 Without significant extension to the C programming language, it is becoming unable to cope with the needs of modern programming problems and programmers;
     235These costs can be prohibitive for many companies with a large software-base in C/\CC, and a significant number of programmers require retraining in the new programming language.
     236
     237The result of this project is a language that is largely backwards compatible with \Index*[C11]{\Celeven{}}~\cite{C11}, but fixes many of the well known C problems while adding modern language-features.
     238To achieve these goals required a significant engineering exercise, where we had to ``think inside the existing C box''.
     239Without these significant extension to C, it is unable to cope with the needs of modern programming problems and programmers;
    243240as a result, it will fade into disuse.
    244241Considering the large body of existing C code and programmers, there is significant impetus to ensure C is transformed into a modern programming language.
    … …  
    256253\begin{lstlisting}
    257254®forall( otype T )® T identity( T val ) { return val; }
    258 int forty_two = identity( 42 );                 §\C{// T is bound to int, forty\_two == 42}§
     255int forty_two = identity( 42 );                         §\C{// T is bound to int, forty\_two == 42}§
    259256\end{lstlisting}
    260257% extending the C type system with parametric polymorphism and overloading, as opposed to the \Index*[C++]{\CC{}} approach of object-oriented extensions.
    … …  
    275272
    276273\begin{comment}
    277 A simple example is leveraging the existing type-unsafe (©void *©) C ©bsearch© to binary search a sorted floating-point array:
     274A simple example is leveraging the existing type-unsafe (©void *©) C ©bsearch© to binary search a sorted floating array:
    278275\begin{lstlisting}
    279276void * bsearch( const void * key, const void * base, size_t dim, size_t size,
    … …  
    283280                                *(double *)t2 < *(double *)t1 ? 1 : 0; }
    284281
    285 double key = 5.0, vals[10] = { /* 10 sorted floating-point values */ };
    286 double * val = (double *)bsearch( &key, vals, 10, sizeof(vals[0]), comp );      $\C{// search sorted array}$
     282double key = 5.0, vals[10] = { /* 10 sorted floating values */ };
     283double * val = (double *)bsearch( &key, vals, 10, sizeof(vals[0]), comp );      §\C{// search sorted array}§
    287284\end{lstlisting}
    288285which can be augmented simply with a polymorphic, type-safe, \CFA-overloaded wrappers:
    … …  
    293290
    294291forall( otype T | { int ?<?( T, T ); } ) unsigned int bsearch( T key, const T * arr, size_t size ) {
    295         T * result = bsearch( key, arr, size ); $\C{// call first version}$
    296         return result ? result - arr : size; }  $\C{// pointer subtraction includes sizeof(T)}$
    297 
    298 double * val = bsearch( 5.0, vals, 10 );        $\C{// selection based on return type}$
     292        T * result = bsearch( key, arr, size ); §\C{// call first version}§
     293        return result ? result - arr : size; }  §\C{// pointer subtraction includes sizeof(T)}§
     294
     295double * val = bsearch( 5.0, vals, 10 );        §\C{// selection based on return type}§
    299296int posn = bsearch( 5.0, vals, 10 );
    300297\end{lstlisting}
    … …  
    308305\begin{lstlisting}
    309306forall( dtype T | sized(T) ) T * malloc( void ) { return (T *)malloc( sizeof(T) ); }
    310 int * ip = malloc();                                    §\C{// select type and size from left-hand side}§
     307int * ip = malloc();                                            §\C{// select type and size from left-hand side}§
    311308double * dp = malloc();
    312309struct S {...} * sp = malloc();
    … …  
    319316Whereas, \CFA wraps each of these routines into ones with the overloaded name ©abs©:
    320317\begin{cfa}
    321 char abs( char );
    322 ®extern "C" {® int abs( int ); ®}®              §\C{// use default C routine for int}§
    323 long int abs( long int );
    324 long long int abs( long long int );
    325 float abs( float );
    326 double abs( double );
    327 long double abs( long double );
    328 float _Complex abs( float _Complex );
    329 double _Complex abs( double _Complex );
    330 long double _Complex abs( long double _Complex );
     318char ®abs®( char );
     319extern "C" { int ®abs®( int ); }                        §\C{// use default C routine for int}§
     320long int ®abs®( long int );
     321long long int ®abs®( long long int );
     322float ®abs®( float );
     323double ®abs®( double );
     324long double ®abs®( long double );
     325float _Complex ®abs®( float _Complex );
     326double _Complex ®abs®( double _Complex );
     327long double _Complex ®abs®( long double _Complex );
    331328\end{cfa}
    332329The problem is the name clash between the library routine ©abs© and the \CFA names ©abs©.
    333330Hence, names appearing in an ©extern "C"© block have \newterm*{C linkage}.
    334331Then overloading polymorphism uses a mechanism called \newterm{name mangling}\index{mangling!name} to create unique names that are different from C names, which are not mangled.
    335 Hence, there is the same need as in \CC, to know if a name is a C or \CFA name, so it can be correctly formed.
    336 There is no way around this problem, other than C's approach of creating unique names for each pairing of operation and type.
     332Hence, there is the same need, as in \CC, to know if a name is a C or \CFA name, so it can be correctly formed.
     333There is no way around this problem, other than C's approach of creating unique names for each pairing of operation and types.
    337334
    338335This example strongly illustrates a core idea in \CFA: \emph{the \Index{power of a name}}.
    … …  
    351348\begin{description}
    352349\item
    353 \Indexc{-std=gnu99}\index{compilation option!-std=gnu99@{©-std=gnu99©}}
    354 The 1999 C standard plus GNU extensions.
    355 \item
    356 \Indexc[deletekeywords=inline]{-fgnu89-inline}\index{compilation option!-fgnu89-inline@{\lstinline[deletekeywords=inline]$-fgnu89-inline$}}
    357 Use the traditional GNU semantics for inline routines in C99 mode, which allows inline routines in header files.
     350\Indexc{-std=gnu11}\index{compilation option!-std=gnu11@{©-std=gnu11©}}
     351The 2011 C standard plus GNU extensions.
     352\item
     353\Indexc[deletekeywords=inline]{-fgnu89-inline}\index{compilation option!-fgnu89-inline@{\lstinline[deletekeywords=inline]@-fgnu89-inline@}}
     354Use the traditional GNU semantics for inline routines in C11 mode, which allows inline routines in header files.
    358355\end{description}
    359356The following new \CFA options are available:
    … …  
    428425\begin{cfa}
    429426#ifndef __CFORALL__
    430 #include <stdio.h>§\indexc{stdio.h}§    §\C{// C header file}§
     427#include <stdio.h>§\indexc{stdio.h}§            §\C{// C header file}§
    431428#else
    432 #include <fstream>§\indexc{fstream}§    §\C{// \CFA header file}§
     429#include <fstream>§\indexc{fstream}§            §\C{// \CFA header file}§
    433430#endif
    434431\end{cfa}
    435 which conditionally includes the correct header file, if the program is compiled using \Indexc{gcc} or \Indexc{cfa}.
     432which conditionally includes the correct header file, if the program is compiled using \Indexc{gcc} or \Indexc{cfa}.
     433
     434
     435\section{Backquote Identifiers}
     436\label{s:BackquoteIdentifiers}
     437
     438\CFA introduces several new keywords (see \VRef{s:CFAKeywords}) that can clash with existing C variable-names in legacy code.
     439Keyword clashes are accommodated by syntactic transformations using the \CFA backquote escape-mechanism:
     440\begin{cfa}
     441int ®`®otype®`® = 3;                                            §\C{// make keyword an identifier}§
     442double ®`®forall®`® = 3.5;
     443\end{cfa}
     444
     445Existing C programs with keyword clashes can be converted by enclosing keyword identifiers in backquotes, and eventually the identifier name can be changed to a non-keyword name.
     446\VRef[Figure]{f:HeaderFileInterposition} shows how clashes in existing C header-files (see~\VRef{s:StandardHeaders}) can be handled using preprocessor \newterm{interposition}: ©#include_next© and ©-I filename©.
     447Several common C header-files with keyword clashes are fixed in the standard \CFA header-library, so there is a seamless programming-experience.
     448
     449\begin{figure}
     450\begin{cfa}
     451// include file uses the CFA keyword "with".
     452#if ! defined( with )                                           §\C{// nesting ?}§
     453#define with ®`®with®`®                                         §\C{// make keyword an identifier}§
     454#define __CFA_BFD_H__
     455#endif
     456
     457®#include_next <bfdlink.h>                                      §\C{// must have internal check for multiple expansion}§
     458®
     459#if defined( with ) && defined( __CFA_BFD_H__ ) §\C{// reset only if set}§
     460#undef with
     461#undef __CFA_BFD_H__
     462#endif
     463\end{cfa}
     464\caption{Header-File Interposition}
     465\label{f:HeaderFileInterposition}
     466\end{figure}
    436467
    437468
    … …  
    440471Numeric constants are extended to allow \Index{underscore}s\index{constant!underscore}, \eg:
    441472\begin{cfa}
    442 2®_®147®_®483®_®648;                                    §\C{// decimal constant}§
    443 56®_®ul;                                                                §\C{// decimal unsigned long constant}§
    444 0®_®377;                                                                §\C{// octal constant}§
    445 0x®_®ff®_®ff;                                                   §\C{// hexadecimal constant}§
    446 0x®_®ef3d®_®aa5c;                                               §\C{// hexadecimal constant}§
    447 3.141®_®592®_®654;                                              §\C{// floating point constant}§
    448 10®_®e®_®+1®_®00;                                               §\C{// floating point constant}§
    449 0x®_®ff®_®ff®_®p®_®3;                                   §\C{// hexadecimal floating point}§
    450 0x®_®1.ffff®_®ffff®_®p®_®128®_®l;               §\C{// hexadecimal floating point long constant}§
     4732®_®147®_®483®_®648;                                            §\C{// decimal constant}§
     47456®_®ul;                                                                        §\C{// decimal unsigned long constant}§
     4750®_®377;                                                                        §\C{// octal constant}§
     4760x®_®ff®_®ff;                                                           §\C{// hexadecimal constant}§
     4770x®_®ef3d®_®aa5c;                                                       §\C{// hexadecimal constant}§
     4783.141®_®592®_®654;                                                      §\C{// floating constant}§
     47910®_®e®_®+1®_®00;                                                       §\C{// floating constant}§
     4800x®_®ff®_®ff®_®p®_®3;                                           §\C{// hexadecimal floating}§
     4810x®_®1.ffff®_®ffff®_®p®_®128®_®l;                       §\C{// hexadecimal floating long constant}§
    451482L®_®§"\texttt{\textbackslash{x}}§®_®§\texttt{ff}§®_®§\texttt{ee}"§;     §\C{// wide character constant}§
    452483\end{cfa}
    … …  
    470501
    471502
    472 \section{Backquote Identifiers}
    473 \label{s:BackquoteIdentifiers}
    474 
    475 \CFA introduces several new keywords (see \VRef{s:CFAKeywords}) that can clash with existing C variable-names in legacy code.
    476 Keyword clashes are accommodated by syntactic transformations using the \CFA backquote escape-mechanism:
    477 \begin{cfa}
    478 int ®`®otype®`® = 3;                    §\C{// make keyword an identifier}§
    479 double ®`®forall®`® = 3.5;
    480 \end{cfa}
    481 
    482 Existing C programs with keyword clashes can be converted by enclosing keyword identifiers in backquotes, and eventually the identifier name can be changed to a non-keyword name.
    483 \VRef[Figure]{f:HeaderFileInterposition} shows how clashes in existing C header-files (see~\VRef{s:StandardHeaders}) can be handled using preprocessor \newterm{interposition}: ©#include_next© and ©-I filename©.
    484 Several common C header-files with keyword clashes are fixed in the standard \CFA header-library, so there is a seamless programming-experience.
    485 
    486 \begin{figure}
    487 \begin{cfa}
    488 // include file uses the CFA keyword "with".
    489 #if ! defined( with )                   §\C{// nesting ?}§
    490 #define with ®`®with®`®                 §\C{// make keyword an identifier}§
    491 #define __CFA_BFD_H__
    492 #endif
    493 
    494 ®#include_next <bfdlink.h>              §\C{// must have internal check for multiple expansion}§
    495 ®
    496 #if defined( with ) && defined( __CFA_BFD_H__ ) §\C{// reset only if set}§
    497 #undef with
    498 #undef __CFA_BFD_H__
    499 #endif
    500 \end{cfa}
    501 \caption{Header-File Interposition}
    502 \label{f:HeaderFileInterposition}
    503 \end{figure}
    504 
    505 
    506 \section{\texorpdfstring{Labelled \LstKeywordStyle{continue} / \LstKeywordStyle{break}}{Labelled continue / break}}
     503\section{Exponentiation Operator}
     504
     505C, \CC, and Java (and many other programming languages) have no exponentiation operator\index{exponentiation!operator}\index{operator!exponentiation}, \ie $x^y$, and instead use a routine, like \Indexc{pow}, to perform the exponentiation operation.
     506\CFA extends the basic operators with the exponentiation operator ©?\?©\index{?\\?@\lstinline@?\?@} and ©?\=?©\index{?\\=?@\lstinline@?\=?@}, as in, ©x \ y© and ©x \= y©, which means $x^y$ and $x \leftarrow x^y$.
     507The priority of the exponentiation operator is between the cast and multiplicative operators, so that ©w * (int)x \ (int)y * z© is parenthesized as ©((w * (((int)x) \ ((int)y))) * z)©.
     508
     509As for \Index{division}, there are exponentiation operators for integral and floating types, including the builtin \Index{complex} types.
     510Unsigned integral exponentiation\index{exponentiation!unsigned integral} is performed with repeated multiplication\footnote{The multiplication computation is $O(\log y)$.} (or shifting if the base is 2).
     511Signed integral exponentiation\index{exponentiation!signed integral} is performed with repeated multiplication (or shifting if the base is 2), but yields a floating result because $x^{-y}=1/x^y$.
     512Hence, it is important to designate exponent integral-constants as unsigned or signed: ©3 \ 3u© return an integral result, while ©3 \ 3© returns a floating result.
     513Floating exponentiation\index{exponentiation!floating} is performed using \Index{logarithm}s\index{exponentiation!logarithm}, so the base cannot be negative.
     514\begin{cfa}
     515sout | 2 ®\® 8u | 4 ®\® 3u | -4 ®\® 3u | 4 ®\® -3 | -4 ®\® -3 | 4.0 ®\® 2.1 | (1.0f+2.0fi) ®\® (3.0f+2.0fi) | endl;
     516256 64 -64 0.015625 -0.015625 18.3791736799526 0.264715-1.1922i
     517\end{cfa}
     518Parenthesis are necessary for the complex constants or the expression is parsed as ©1.0f+(2.0fi \ 3.0f)+2.0fi©.
     519The exponentiation operator is available for all the basic types, but for user-defined types, only the integral-computation versions are available.
     520For returning an integral value, the user type ©T© must define multiplication, ©*©, and one, ©1©;
     521for returning a floating value, an additional divide of type ©T© into a ©double© returning a ©double© (©double ?/?( double, T )©) is necessary for negative exponents.
     522
     523
     524\section{Control Structures}
     525
     526\CFA identifies inconsistent, problematic, and missing control structures in C, and extends, modifies, and adds control structures to increase functionality and safety.
     527
     528
     529%\subsection{\texorpdfstring{\protect\lstinline@if@ Statement}{if Statement}}
     530\subsection{\texorpdfstring{\LstKeywordStyle{if} Statement}{if Statement}}
     531
     532The ©if© expression allows declarations, similar to ©for© declaration expression:
     533\begin{cfa}
     534if ( int x = f() ) ...                                          §\C{// x != 0}§
     535if ( int x = f(), y = g() ) ...                         §\C{// x != 0 \&\& y != 0}§
     536if ( int x = f(), y = g(); ®x < y® ) ...        §\C{// relational expression}§
     537\end{cfa}
     538Unless a relational expression is specified, each variable is compared not equal to 0, which is the standard semantics for the ©if© expression, and the results are combined using the logical ©&&© operator.\footnote{\CC only provides a single declaration always compared not equal to 0.}
     539The scope of the declaration(s) is local to the @if@ statement but exist within both the ``then'' and ``else'' clauses.
     540
     541
     542%\section{\texorpdfstring{\protect\lstinline@switch@ Statement}{switch Statement}}
     543\subsection{\texorpdfstring{\LstKeywordStyle{switch} Statement}{switch Statement}}
     544
     545C allows a number of questionable forms for the ©switch© statement:
     546\begin{enumerate}
     547\item
     548By default, the end of a ©case© clause\footnote{
     549In this section, the term \emph{case clause} refers to either a ©case© or ©default© clause.}
     550\emph{falls through} to the next ©case© clause in the ©switch© statement;
     551to exit a ©switch© statement from a ©case© clause requires explicitly terminating the clause with a transfer statement, most commonly ©break©:
     552\begin{cfa}
     553switch ( i ) {
     554  case 1:
     555        ...
     556        // fall-through
     557  case 2:
     558        ...
     559        break;  // exit switch statement
     560}
     561\end{cfa}
     562The ability to fall-through to the next clause \emph{is} a useful form of control flow, specifically when a sequence of case actions compound:
     563\begin{cquote}
     564\begin{tabular}{@{}l@{\hspace{3em}}l@{}}
     565\begin{cfa}
     566switch ( argc ) {
     567  case 3:
     568        // open output file
     569        // fall-through
     570  case 2:
     571        // open input file
     572        break;  // exit switch statement
     573  default:
     574        // usage message
     575}
     576\end{cfa}
     577&
     578\begin{cfa}
     579
     580if ( argc == 3 ) {
     581        // open output file
     582        ®// open input file
     583®} else if ( argc == 2 ) {
     584        ®// open input file (duplicate)
     585
     586®} else {
     587        // usage message
     588}
     589\end{cfa}
     590\end{tabular}
     591\end{cquote}
     592In this example, case 2 is always done if case 3 is done.
     593This control flow is difficult to simulate with if statements or a ©switch© statement without fall-through as code must be duplicated or placed in a separate routine.
     594C also uses fall-through to handle multiple case-values resulting in the same action:
     595\begin{cfa}
     596switch ( i ) {
     597  ®case 1: case 3: case 5:®     // odd values
     598        // odd action
     599        break;
     600  ®case 2: case 4: case 6:®     // even values
     601        // even action
     602        break;
     603}
     604\end{cfa}
     605However, this situation is handled in other languages without fall-through by allowing a list of case values.
     606While fall-through itself is not a problem, the problem occurs when fall-through is the default, as this semantics is unintuitive to many programmers and is different from virtually all other programming languages with a ©switch© statement.
     607Hence, default fall-through semantics results in a large number of programming errors as programmers often \emph{forget} the ©break© statement at the end of a ©case© clause, resulting in inadvertent fall-through.
     608
     609\item
     610It is possible to place ©case© clauses on statements nested \emph{within} the body of the ©switch© statement:
     611\begin{cfa}
     612switch ( i ) {
     613  case 0:
     614        if ( j < k ) {
     615                ...
     616          ®case 1:®             // transfer into "if" statement
     617                ...
     618        } // if
     619  case 2:
     620        while ( j < 5 ) {
     621                ...
     622          ®case 3:®             // transfer into "while" statement
     623                ...
     624        } // while
     625} // switch
     626\end{cfa}
     627The problem with this usage is branching into control structures, which is known to cause both comprehension and technical difficulties.
     628The comprehension problem occurs from the inability to determine how control reaches a particular point due to the number of branches leading to it.
     629The technical problem results from the inability to ensure declaration and initialization of variables when blocks are not entered at the beginning.
     630There are no positive arguments for this kind of control flow, and therefore, there is a strong impetus to eliminate it.
     631Nevertheless, C does have an idiom where this capability is used, known as ``\Index*{Duff's device}''~\cite{Duff83}:
     632\begin{cfa}
     633register int n = (count + 7) / 8;
     634switch ( count % 8 ) {
     635case 0: do{ *to = *from++;
     636case 7:         *to = *from++;
     637case 6:         *to = *from++;
     638case 5:         *to = *from++;
     639case 4:         *to = *from++;
     640case 3:         *to = *from++;
     641case 2:         *to = *from++;
     642case 1:         *to = *from++;
     643                } while ( --n > 0 );
     644}
     645\end{cfa}
     646which unrolls a loop N times (N = 8 above) and uses the ©switch© statement to deal with any iterations not a multiple of N.
     647While efficient, this sort of special purpose usage is questionable:
     648\begin{quote}
     649Disgusting, no? But it compiles and runs just fine. I feel a combination of pride and revulsion at this
     650discovery.~\cite{Duff83}
     651\end{quote}
     652\item
     653It is possible to place the ©default© clause anywhere in the list of labelled clauses for a ©switch© statement, rather than only at the end.
     654Virtually all programming languages with a ©switch© statement require the ©default© clause to appear last in the case-clause list.
     655The logic for this semantics is that after checking all the ©case© clauses without success, the ©default© clause is selected;
     656hence, physically placing the ©default© clause at the end of the ©case© clause list matches with this semantics.
     657This physical placement can be compared to the physical placement of an ©else© clause at the end of a series of connected ©if©/©else© statements.
     658
     659\item
     660It is possible to place unreachable code at the start of a ©switch© statement, as in:
     661\begin{cfa}
     662switch ( x ) {
     663        ®int y = 1;®                                                    §\C{// unreachable initialization}§
     664        ®x = 7;®                                                                §\C{// unreachable code without label/branch}§
     665  case 0: ...
     666        ...
     667        ®int z = 0;®                                                    §\C{// unreachable initialization, cannot appear after case}§
     668        z = 2;
     669  case 1:
     670        ®x = z;®                                                                §\C{// without fall through, z is uninitialized}§
     671}
     672\end{cfa}
     673While the declaration of the local variable ©y© is useful with a scope across all ©case© clauses, the initialization for such a variable is defined to never be executed because control always transfers over it.
     674Furthermore, any statements before the first ©case© clause can only be executed if labelled and transferred to using a ©goto©, either from outside or inside of the ©switch©, both of which are problematic.
     675As well, the declaration of ©z© cannot occur after the ©case© because a label can only be attached to a statement, and without a fall through to case 3, ©z© is uninitialized.
     676The key observation is that the ©switch© statement branches into control structure, \ie there are multiple entry points into its statement body.
     677\end{enumerate}
     678
     679Before discussing potential language changes to deal with these problems, it is worth observing that in a typical C program:
     680\begin{itemize}
     681\item
     682the number of ©switch© statements is small,
     683\item
     684most ©switch© statements are well formed (\ie no \Index*{Duff's device}),
     685\item
     686the ©default© clause is usually written as the last case-clause,
     687\item
     688and there is only a medium amount of fall-through from one ©case© clause to the next, and most of these result from a list of case values executing common code, rather than a sequence of case actions that compound.
     689\end{itemize}
     690These observations put into perspective the \CFA changes to the ©switch©.
     691\begin{enumerate}
     692\item
     693Eliminating default fall-through has the greatest potential for affecting existing code.
     694However, even if fall-through is removed, most ©switch© statements would continue to work because of the explicit transfers already present at the end of each ©case© clause, the common placement of the ©default© clause at the end of the case list, and the most common use of fall-through, \ie a list of ©case© clauses executing common code, \eg:
     695\begin{cfa}
     696case 1:  case 2:  case 3: ...
     697\end{cfa}
     698still works.
     699Nevertheless, reversing the default action would have a non-trivial effect on case actions that compound, such as the above example of processing shell arguments.
     700Therefore, to preserve backwards compatibility, it is necessary to introduce a new kind of ©switch© statement, called ©choose©, with no implicit fall-through semantics and an explicit fall-through if the last statement of a case-clause ends with the new keyword ©fallthrough©/©fallthru©, \eg:
     701\begin{cfa}
     702®choose® ( i ) {
     703  case 1:  case 2:  case 3:
     704        ...
     705        ®// implicit end of switch (break)
     706  ®case 5:
     707        ...
     708        ®fallthru®;                                                             §\C{// explicit fall through}§
     709  case 7:
     710        ...
     711        ®break®                                                                 §\C{// explicit end of switch (redundant)}§
     712  default:
     713        j = 3;
     714}
     715\end{cfa}
     716Like the ©switch© statement, the ©choose© statement retains the fall-through semantics for a list of ©case© clauses;
     717An implicit ©break© is applied only at the end of the \emph{statements} following a ©case© clause.
     718An explicit ©fallthru© is retained because it is a C-idiom most C programmers expect, and its absence might discourage programmers from using the ©choose© statement.
     719As well, allowing an explicit ©break© from the ©choose© is a carry over from the ©switch© statement, and expected by C programmers.
     720\item
     721\Index*{Duff's device} is eliminated from both ©switch© and ©choose© statements, and only invalidates a small amount of very questionable code.
     722Hence, the ©case© clause must appear at the same nesting level as the ©switch©/©choose© body, as is done in most other programming languages with ©switch© statements.
     723\item
     724The issue of ©default© at locations other than at the end of the cause clause can be solved by using good programming style, and there are a few reasonable situations involving fall-through where the ©default© clause needs to appear is locations other than at the end.
     725Therefore, no change is made for this issue.
     726\item
     727Dealing with unreachable code in a ©switch©/©choose© body is solved by restricting declarations and associated initialization to the start of statement body, which is executed \emph{before} the transfer to the appropriate ©case© clause\footnote{
     728Essentially, these declarations are hoisted before the ©switch©/©choose© statement and both declarations and statement are surrounded by a compound statement.} and precluding statements before the first ©case© clause.
     729Further declarations at the same nesting level as the statement body are disallowed to ensure every transfer into the body is sound.
     730\begin{cfa}
     731switch ( x ) {
     732        ®int i = 0;®                                                    §\C{// allowed only at start}§
     733  case 0:
     734        ...
     735        ®int j = 0;®                                                    §\C{// disallowed}§
     736  case 1:
     737        {
     738                ®int k = 0;®                                            §\C{// allowed at different nesting levels}§
     739                ...
     740          ®case 2:®                                                             §\C{// disallow case in nested statements}§
     741        }
     742  ...
     743}
     744\end{cfa}
     745\end{enumerate}
     746
     747
     748%\section{\texorpdfstring{\protect\lstinline@case@ Clause}{case Clause}}
     749\subsection{\texorpdfstring{\LstKeywordStyle{case} Statement}{case Statement}}
     750
     751C restricts the ©case© clause of a ©switch© statement to a single value.
     752For multiple ©case© clauses associated with the same statement, it is necessary to have multiple ©case© clauses rather than multiple values.
     753Requiring a ©case© clause for each value does not seem to be in the spirit of brevity normally associated with C.
     754Therefore, the ©case© clause is extended with a list of values, as in:
     755\begin{cquote}
     756\begin{tabular}{@{}l@{\hspace{3em}}l@{\hspace{2em}}l@{}}
     757\multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}}        & \multicolumn{1}{c@{\hspace{2em}}}{\textbf{C}} \\
     758\begin{cfa}
     759switch ( i ) {
     760  case ®1, 3, 5®:
     761        ...
     762  case ®2, 4, 6®:
     763        ...
     764}
     765\end{cfa}
     766&
     767\begin{cfa}
     768switch ( i ) {
     769  case 1: case 3 : case 5:
     770        ...
     771  case 2: case 4 : case 6:
     772        ...
     773}
     774\end{cfa}
     775&
     776\begin{cfa}
     777
     778// odd values
     779
     780// even values
     781
     782
     783\end{cfa}
     784\end{tabular}
     785\end{cquote}
     786In addition, subranges are allowed to specify case values.\footnote{
     787gcc has the same mechanism but awkward syntax, \lstinline@2 ...42@, because a space is required after a number, otherwise the period is a decimal point.}
     788\begin{cfa}
     789switch ( i ) {
     790  case ®1~5:®                                   §\C{// 1, 2, 3, 4, 5}§
     791        ...
     792  case ®10~15:®                                 §\C{// 10, 11, 12, 13, 14, 15}§
     793        ...
     794}
     795\end{cfa}
     796Lists of subranges are also allowed.
     797\begin{cfa}
     798case ®1~5, 12~21, 35~42®:
     799\end{cfa}
     800
     801
     802%\subsection{\texorpdfstring{Labelled \protect\lstinline@continue@ / \protect\lstinline@break@}{Labelled continue / break}}
     803\subsection{\texorpdfstring{Labelled \LstKeywordStyle{continue} / \LstKeywordStyle{break} Statement}{Labelled continue / break Statement}}
    507804
    508805While C provides ©continue© and ©break© statements for altering control flow, both are restricted to one level of nesting for a particular control structure.
    509806Unfortunately, this restriction forces programmers to use \Indexc{goto} to achieve the equivalent control-flow for more than one level of nesting.
    510 To prevent having to switch to the ©goto©, \CFA extends the \Indexc{continue}\index{continue@\lstinline $continue$!labelled}\index{labelled!continue@©continue©} and \Indexc{break}\index{break@\lstinline $break$!labelled}\index{labelled!break@©break©} with a target label to support static multi-level exit\index{multi-level exit}\index{static multi-level exit}~\cite{Buhr85}, as in Java.
     807To prevent having to switch to the ©goto©, \CFA extends the \Indexc{continue}\index{continue@\lstinline@continue@!labelled}\index{labelled!continue@©continue©} and \Indexc{break}\index{break@\lstinline@break@!labelled}\index{labelled!break@©break©} with a target label to support static multi-level exit\index{multi-level exit}\index{static multi-level exit}~\cite{Buhr85}, as in Java.
    511808For both ©continue© and ©break©, the target label must be directly associated with a ©for©, ©while© or ©do© statement;
    512809for ©break©, the target label can also be associated with a ©switch©, ©if© or compound (©{}©) statement.
    … …  
    593890\end{figure}
    594891
    595 Both labelled ©continue© and ©break© are a ©goto©\index{goto@\lstinline $goto$!restricted} restricted in the following ways:
     892Both labelled ©continue© and ©break© are a ©goto©\index{goto@\lstinline@goto@!restricted} restricted in the following ways:
    596893\begin{itemize}
    597894\item
    … …  
    606903With ©goto©, the label is at the end of the control structure, which fails to convey this important clue early enough to the reader.
    607904Finally, using an explicit target for the transfer instead of an implicit target allows new constructs to be added or removed without affecting existing constructs.
    608 The implicit targets of the current ©continue© and ©break©, \ie the closest enclosing loop or ©switch©, change as certain constructs are added or removed.
    609 
    610 
    611 \section{\texorpdfstring{\LstKeywordStyle{switch} Statement}{switch Statement}}
    612 
    613 C allows a number of questionable forms for the ©switch© statement:
    614 \begin{enumerate}
    615 \item
    616 By default, the end of a ©case© clause\footnote{
    617 In this section, the term \emph{case clause} refers to either a ©case© or ©default© clause.}
    618 \emph{falls through} to the next ©case© clause in the ©switch© statement;
    619 to exit a ©switch© statement from a ©case© clause requires explicitly terminating the clause with a transfer statement, most commonly ©break©:
    620 \begin{cfa}
    621 switch ( i ) {
    622   case 1:
    623         ...
    624         // fall-through
    625   case 2:
    626         ...
    627         break;  // exit switch statement
    628 }
    629 \end{cfa}
    630 The ability to fall-through to the next clause \emph{is} a useful form of control flow, specifically when a sequence of case actions compound:
    631 \begin{quote2}
    632 \begin{tabular}{@{}l@{\hspace{3em}}l@{}}
    633 \begin{cfa}
    634 switch ( argc ) {
    635   case 3:
    636         // open output file
    637         // fall-through
    638   case 2:
    639         // open input file
    640         break;  // exit switch statement
    641   default:
    642         // usage message
    643 }
    644 \end{cfa}
    645 &
    646 \begin{cfa}
    647 
    648 if ( argc == 3 ) {
    649         // open output file
    650         ®// open input file
    651 ®} else if ( argc == 2 ) {
    652         ®// open input file (duplicate)
    653 
    654 ®} else {
    655         // usage message
    656 }
    657 \end{cfa}
    658 \end{tabular}
    659 \end{quote2}
    660 In this example, case 2 is always done if case 3 is done.
    661 This control flow is difficult to simulate with if statements or a ©switch© statement without fall-through as code must be duplicated or placed in a separate routine.
    662 C also uses fall-through to handle multiple case-values resulting in the same action:
    663 \begin{cfa}
    664 switch ( i ) {
    665   ®case 1: case 3: case 5:®     // odd values
    666         // odd action
    667         break;
    668   ®case 2: case 4: case 6:®     // even values
    669         // even action
    670         break;
    671 }
    672 \end{cfa}
    673 However, this situation is handled in other languages without fall-through by allowing a list of case values.
    674 While fall-through itself is not a problem, the problem occurs when fall-through is the default, as this semantics is unintuitive to many programmers and is different from virtually all other programming languages with a ©switch© statement.
    675 Hence, default fall-through semantics results in a large number of programming errors as programmers often \emph{forget} the ©break© statement at the end of a ©case© clause, resulting in inadvertent fall-through.
    676 
    677 \item
    678 It is possible to place ©case© clauses on statements nested \emph{within} the body of the ©switch© statement:
    679 \begin{cfa}
    680 switch ( i ) {
    681   case 0:
    682         if ( j < k ) {
    683                 ...
    684           ®case 1:®             // transfer into "if" statement
    685                 ...
    686         } // if
    687   case 2:
    688         while ( j < 5 ) {
    689                 ...
    690           ®case 3:®             // transfer into "while" statement
    691                 ...
    692         } // while
    693 } // switch
    694 \end{cfa}
    695 The problem with this usage is branching into control structures, which is known to cause both comprehension and technical difficulties.
    696 The comprehension problem occurs from the inability to determine how control reaches a particular point due to the number of branches leading to it.
    697 The technical problem results from the inability to ensure declaration and initialization of variables when blocks are not entered at the beginning.
    698 There are no positive arguments for this kind of control flow, and therefore, there is a strong impetus to eliminate it.
    699 Nevertheless, C does have an idiom where this capability is used, known as ``\Index*{Duff's device}''~\cite{Duff83}:
    700 \begin{cfa}
    701 register int n = (count + 7) / 8;
    702 switch ( count % 8 ) {
    703 case 0: do{ *to = *from++;
    704 case 7:         *to = *from++;
    705 case 6:         *to = *from++;
    706 case 5:         *to = *from++;
    707 case 4:         *to = *from++;
    708 case 3:         *to = *from++;
    709 case 2:         *to = *from++;
    710 case 1:         *to = *from++;
    711                 } while ( --n > 0 );
    712 }
    713 \end{cfa}
    714 which unrolls a loop N times (N = 8 above) and uses the ©switch© statement to deal with any iterations not a multiple of N.
    715 While efficient, this sort of special purpose usage is questionable:
    716 \begin{quote}
    717 Disgusting, no? But it compiles and runs just fine. I feel a combination of pride and revulsion at this
    718 discovery.~\cite{Duff83}
    719 \end{quote}
    720 \item
    721 It is possible to place the ©default© clause anywhere in the list of labelled clauses for a ©switch© statement, rather than only at the end.
    722 Virtually all programming languages with a ©switch© statement require the ©default© clause to appear last in the case-clause list.
    723 The logic for this semantics is that after checking all the ©case© clauses without success, the ©default© clause is selected;
    724 hence, physically placing the ©default© clause at the end of the ©case© clause list matches with this semantics.
    725 This physical placement can be compared to the physical placement of an ©else© clause at the end of a series of connected ©if©/©else© statements.
    726 
    727 \item
    728 It is possible to place unreachable code at the start of a ©switch© statement, as in:
    729 \begin{cfa}
    730 switch ( x ) {
    731         ®int y = 1;®                            §\C{// unreachable initialization}§
    732         ®x = 7;®                                        §\C{// unreachable code without label/branch}§
    733   case 3: ...
    734         ...
    735         ®int z = 0;®                            §\C{// unreachable initialization, cannot appear after case}§
    736         z = 2;
    737   case 3:
    738         ®x = z;®                                        §\C{// without fall through, z is uninitialized}§
    739 }
    740 \end{cfa}
    741 While the declaration of the local variable ©y© is useful with a scope across all ©case© clauses, the initialization for such a variable is defined to never be executed because control always transfers over it.
    742 Furthermore, any statements before the first ©case© clause can only be executed if labelled and transferred to using a ©goto©, either from outside or inside of the ©switch©, both of which are problematic.
    743 As well, the declaration of ©z© cannot occur after the ©case© because a label can only be attached to a statement, and without a fall through to case 3, ©z© is uninitialized.
    744 The key observation is that the ©switch© statement branches into control structure, \ie there are multiple entry points into its statement body.
    745 \end{enumerate}
    746 
    747 Before discussing potential language changes to deal with these problems, it is worth observing that in a typical C program:
    748 \begin{itemize}
    749 \item
    750 the number of ©switch© statements is small,
    751 \item
    752 most ©switch© statements are well formed (\ie no \Index*{Duff's device}),
    753 \item
    754 the ©default© clause is usually written as the last case-clause,
    755 \item
    756 and there is only a medium amount of fall-through from one ©case© clause to the next, and most of these result from a list of case values executing common code, rather than a sequence of case actions that compound.
    757 \end{itemize}
    758 These observations put into perspective the \CFA changes to the ©switch©.
    759 \begin{enumerate}
    760 \item
    761 Eliminating default fall-through has the greatest potential for affecting existing code.
    762 However, even if fall-through is removed, most ©switch© statements would continue to work because of the explicit transfers already present at the end of each ©case© clause, the common placement of the ©default© clause at the end of the case list, and the most common use of fall-through, \ie a list of ©case© clauses executing common code, \eg:
    763 \begin{cfa}
    764 case 1:  case 2:  case 3: ...
    765 \end{cfa}
    766 still works.
    767 Nevertheless, reversing the default action would have a non-trivial effect on case actions that compound, such as the above example of processing shell arguments.
    768 Therefore, to preserve backwards compatibility, it is necessary to introduce a new kind of ©switch© statement, called ©choose©, with no implicit fall-through semantics and an explicit fall-through if the last statement of a case-clause ends with the new keyword ©fallthrough©/©fallthru©, \eg:
    769 \begin{cfa}
    770 ®choose® ( i ) {
    771   case 1:  case 2:  case 3:
    772         ...
    773         ®// implicit end of switch (break)
    774   ®case 5:
    775         ...
    776         ®fallthru®;                                     §\C{// explicit fall through}§
    777   case 7:
    778         ...
    779         ®break®                                         §\C{// explicit end of switch (redundant)}§
    780   default:
    781         j = 3;
    782 }
    783 \end{cfa}
    784 Like the ©switch© statement, the ©choose© statement retains the fall-through semantics for a list of ©case© clauses;
    785 An implicit ©break© is applied only at the end of the \emph{statements} following a ©case© clause.
    786 An explicit ©fallthru© is retained because it is a C-idiom most C programmers expect, and its absence might discourage programmers from using the ©choose© statement.
    787 As well, allowing an explicit ©break© from the ©choose© is a carry over from the ©switch© statement, and expected by C programmers.
    788 \item
    789 \Index*{Duff's device} is eliminated from both ©switch© and ©choose© statements, and only invalidates a small amount of very questionable code.
    790 Hence, the ©case© clause must appear at the same nesting level as the ©switch©/©choose© body, as is done in most other programming languages with ©switch© statements.
    791 \item
    792 The issue of ©default© at locations other than at the end of the cause clause can be solved by using good programming style, and there are a few reasonable situations involving fall-through where the ©default© clause needs to appear is locations other than at the end.
    793 Therefore, no change is made for this issue.
    794 \item
    795 Dealing with unreachable code in a ©switch©/©choose© body is solved by restricting declarations and associated initialization to the start of statement body, which is executed \emph{before} the transfer to the appropriate ©case© clause\footnote{
    796 Essentially, these declarations are hoisted before the ©switch©/©choose© statement and both declarations and statement are surrounded by a compound statement.} and precluding statements before the first ©case© clause.
    797 Further declarations at the same nesting level as the statement body are disallowed to ensure every transfer into the body is sound.
    798 \begin{cfa}
    799 switch ( x ) {
    800         ®int i = 0;®                            §\C{// allowed only at start}§
    801   case 0:
    802         ...
    803         ®int j = 0;®                            §\C{// disallowed}§
    804   case 1:
    805         {
    806                 ®int k = 0;®                    §\C{// allowed at different nesting levels}§
    807                 ...
    808           ®case 2:®                                     §\C{// disallow case in nested statements}§
     905Otherwise, the implicit targets of the current ©continue© and ©break©, \ie the closest enclosing loop or ©switch©, change as certain constructs are added or removed.
     906
     907
     908%\section{\texorpdfstring{\protect\lstinline@with@ Statement}{with Statement}}
     909\section{\texorpdfstring{\LstKeywordStyle{with} Statement}{with Statement}}
     910\label{s:WithStatement}
     911
     912Grouping heterogeneous data into \newterm{aggregate}s (structure/union) is a common programming practice, and an aggregate can be further organized into more complex structures, such as arrays and containers:
     913\begin{cfa}
     914struct S {                                                                      §\C{// aggregate}§
     915        char c;                                                                 §\C{// fields}§
     916        int i;
     917        double d;
     918};
     919S s, as[10];
     920\end{cfa}
     921However, functions manipulating aggregates must repeat the aggregate name to access its containing fields:
     922\begin{cfa}
     923void f( S s ) {
     924        ®s.®c; ®s.®i; ®s.®d;                                    §\C{// access containing fields}§
     925}
     926\end{cfa}
     927which extends to multiple levels of qualification for nested aggregates.
     928A similar situation occurs in object-oriented programming, \eg \CC:
     929\begin{C++}
     930struct S {
     931        char c;                                                                 §\C{// fields}§
     932        int i;
     933        double d;
     934        void f() {                                                              §\C{// implicit ``this'' aggregate}§
     935                ®this->®c; ®this->®i; ®this->®d;        §\C{// access containing fields}§
    809936        }
    810   ...
    811 }
    812 \end{cfa}
    813 \end{enumerate}
    814 
    815 
    816 \section{\texorpdfstring{\LstKeywordStyle{case} Clause}{case Clause}}
    817 
    818 C restricts the ©case© clause of a ©switch© statement to a single value.
    819 For multiple ©case© clauses associated with the same statement, it is necessary to have multiple ©case© clauses rather than multiple values.
    820 Requiring a ©case© clause for each value does not seem to be in the spirit of brevity normally associated with C.
    821 Therefore, the ©case© clause is extended with a list of values, as in:
    822 \begin{quote2}
    823 \begin{tabular}{@{}l@{\hspace{3em}}l@{\hspace{2em}}l@{}}
    824 \multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}}        & \multicolumn{1}{c@{\hspace{2em}}}{\textbf{C}} \\
    825 \begin{cfa}
    826 switch ( i ) {
    827   case ®1, 3, 5®:
    828         ...
    829   case ®2, 4, 6®:
    830         ...
    831 }
    832 \end{cfa}
    833 &
    834 \begin{cfa}
    835 switch ( i ) {
    836   case 1: case 3 : case 5:
    837         ...
    838   case 2: case 4 : case 6:
    839         ...
    840 }
    841 \end{cfa}
    842 &
    843 \begin{cfa}
    844 
    845 // odd values
    846 
    847 // even values
    848 
    849 
    850 \end{cfa}
    851 \end{tabular}
    852 \end{quote2}
    853 In addition, two forms of subranges are allowed to specify case values: a new \CFA form and an existing GNU C form.\footnote{
    854 The GNU C form \emph{requires} spaces around the ellipse.}
    855 \begin{quote2}
    856 \begin{tabular}{@{}l@{\hspace{3em}}l@{\hspace{2em}}l@{}}
    857 \multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}}        & \multicolumn{1}{c@{\hspace{2em}}}{\textbf{GNU C}}     \\
    858 \begin{cfa}
    859 switch ( i ) {
    860   case ®1~5:®
    861         ...
    862   case ®10~15:®
    863         ...
    864 }
    865 \end{cfa}
    866 &
    867 \begin{cfa}
    868 switch ( i )
    869   case ®1 ... 5®:
    870         ...
    871   case ®10 ... 15®:
    872         ...
    873 }
    874 \end{cfa}
    875 &
    876 \begin{cfa}
    877 
    878 // 1, 2, 3, 4, 5
    879 
    880 // 10, 11, 12, 13, 14, 15
    881 
    882 
    883 \end{cfa}
    884 \end{tabular}
    885 \end{quote2}
    886 Lists of subranges are also allowed.
    887 \begin{cfa}
    888 case ®1~5, 12~21, 35~42®:
    889 \end{cfa}
    890 
    891 
    892 \section{\texorpdfstring{\LstKeywordStyle{with} Clause / Statement}{with Clause / Statement}}
    893 \label{s:WithClauseStatement}
     937}
     938\end{C++}
     939Object-oriented nesting of member functions in a \lstinline[language=C++]@class/struct@ allows eliding \lstinline[language=C++]@this->@ because of lexical scoping.
     940However, for other aggregate parameters, qualification is necessary:
     941\begin{cfa}
     942struct T { double m, n; };
     943int S::f( T & t ) {                                                     §\C{// multiple aggregate parameters}§
     944        c; i; d;                                                                §\C{\color{red}// this--{\textgreater}.c, this--{\textgreater}.i, this--{\textgreater}.d}§
     945        ®t.®m; ®t.®n;                                                   §\C{// must qualify}§
     946}
     947\end{cfa}
     948
     949To simplify the programmer experience, \CFA provides a ©with© statement (see Pascal~\cite[\S~4.F]{Pascal}) to elide aggregate qualification to fields by opening a scope containing the field identifiers.
     950Hence, the qualified fields become variables with the side-effect that it is easier to optimizing field references in a block.
     951\begin{cfa}
     952void f( S & this ) ®with ( this )® {            §\C{// with statement}§
     953        c; i; d;                                                                §\C{\color{red}// this.c, this.i, this.d}§
     954}
     955\end{cfa}
     956with the generality of opening multiple aggregate-parameters:
     957\begin{cfa}
     958void f( S & s, T & t ) ®with ( s, t )® {        §\C{// multiple aggregate parameters}§
     959        c; i; d;                                                                §\C{\color{red}// s.c, s.i, s.d}§
     960        m; n;                                                                   §\C{\color{red}// t.m, t.n}§
     961}
     962\end{cfa}
     963
     964In detail, the ©with© statement has the form:
     965\begin{cfa}
     966§\emph{with-statement}§:
     967        'with' '(' §\emph{expression-list}§ ')' §\emph{compound-statement}§
     968\end{cfa}
     969and may appear as the body of a function or nested within a function body.
     970Each expression in the expression-list provides a type and object.
     971The type must be an aggregate type.
     972(Enumerations are already opened.)
     973The object is the implicit qualifier for the open structure-fields.
     974
     975All expressions in the expression list are open in parallel within the compound statement.
     976This semantic is different from Pascal, which nests the openings from left to right.
     977The difference between parallel and nesting occurs for fields with the same name and type:
     978\begin{cfa}
     979struct S { int ®i®; int j; double m; } s, w;
     980struct T { int ®i®; int k; int m; } t, w;
     981with ( s, t ) {
     982        j + k;                                                                  §\C{// unambiguous, s.j + t.k}§
     983        m = 5.0;                                                                §\C{// unambiguous, t.m = 5.0}§
     984        m = 1;                                                                  §\C{// unambiguous, s.m = 1}§
     985        int a = m;                                                              §\C{// unambiguous, a = s.i }§
     986        double b = m;                                                   §\C{// unambiguous, b = t.m}§
     987        int c = s.i + t.i;                                              §\C{// unambiguous, qualification}§
     988        (double)m;                                                              §\C{// unambiguous, cast}§
     989}
     990\end{cfa}
     991For parallel semantics, both ©s.i© and ©t.i© are visible, so ©i© is ambiguous without qualification;
     992for nested semantics, ©t.i© hides ©s.i©, so ©i© implies ©t.i©.
     993\CFA's ability to overload variables means fields with the same name but different types are automatically disambiguated, eliminating most qualification when opening multiple aggregates.
     994Qualification or a cast is used to disambiguate.
     995
     996There is an interesting problem between parameters and the function-body ©with©, \eg:
     997\begin{cfa}
     998void ?{}( S & s, int i ) with ( s ) {           §\C{// constructor}§
     999        ®s.i = i;®  j = 3;  m = 5.5;                    §\C{// initialize fields}§
     1000}
     1001\end{cfa}
     1002Here, the assignment ©s.i = i© means ©s.i = s.i©, which is meaningless, and there is no mechanism to qualify the parameter ©i©, making the assignment impossible using the function-body ©with©.
     1003To solve this problem, parameters are treated like an initialized aggregate:
     1004\begin{cfa}
     1005struct Params {
     1006        S & s;
     1007        int i;
     1008} params;
     1009\end{cfa}
     1010and implicitly opened \emph{after} a function-body open, to give them higher priority:
     1011\begin{cfa}
     1012void ?{}( S & s, int ®i® ) with ( s ) ®with( §\emph{\color{red}params}§ )® {
     1013        s.i = ®i®; j = 3; m = 5.5;
     1014}
     1015\end{cfa}
     1016Finally, a cast may be used to disambiguate among overload variables in a ©with© expression:
     1017\begin{cfa}
     1018with ( w ) { ... }                                                      §\C{// ambiguous, same name and no context}§
     1019with ( (S)w ) { ... }                                           §\C{// unambiguous, cast}§
     1020\end{cfa}
     1021and ©with© expressions may be complex expressions with type reference (see Section~\ref{s:References}) to aggregate:
     1022% \begin{cfa}
     1023% struct S { int i, j; } sv;
     1024% with ( sv ) {                                                         §\C{// implicit reference}§
     1025%       S & sr = sv;
     1026%       with ( sr ) {                                                   §\C{// explicit reference}§
     1027%               S * sp = &sv;
     1028%               with ( *sp ) {                                          §\C{// computed reference}§
     1029%                       i = 3; j = 4;                                   §\C{\color{red}// sp--{\textgreater}i, sp--{\textgreater}j}§
     1030%               }
     1031%               i = 2; j = 3;                                           §\C{\color{red}// sr.i, sr.j}§
     1032%       }
     1033%       i = 1; j = 2;                                                   §\C{\color{red}// sv.i, sv.j}§
     1034% }
     1035% \end{cfa}
    8941036
    8951037In \Index{object-oriented} programming, there is an implicit first parameter, often names \textbf{©self©} or \textbf{©this©}, which is elided.
    … …  
    8971039class C {
    8981040        int i, j;
    899         int mem() {                                     §\C{\color{red}// implicit "this" parameter}§
    900                 i = 1;                                  §\C{\color{red}// this->i}§
    901                 j = 2;                                  §\C{\color{red}// this->j}§
     1041        int mem() {                                                             §\C{\color{red}// implicit "this" parameter}§
     1042                i = 1;                                                          §\C{\color{red}// this->i}§
     1043                j = 2;                                                          §\C{\color{red}// this->j}§
    9021044        }
    9031045}
    9041046\end{C++}
    905 Since CFA is non-object-oriented, the equivalent object-oriented program looks like:
     1047Since \CFA is non-object-oriented, the equivalent object-oriented program looks like:
    9061048\begin{cfa}
    9071049struct S { int i, j; };
    908 int mem( S &®this® ) {                  §\C{// explicit "this" parameter}§
    909         ®this.®i = 1;                           §\C{// "this" is not elided}§
     1050int mem( S & ®this® ) {                                         §\C{// explicit "this" parameter}§
     1051        ®this.®i = 1;                                                   §\C{// "this" is not elided}§
    9101052        ®this.®j = 2;
    9111053}
    9121054\end{cfa}
    913 but it is cumbersome having to write "©this.©" many times in a member.
     1055but it is cumbersome having to write ``©this.©'' many times in a member.
    9141056
    9151057\CFA provides a ©with© clause/statement (see Pascal~\cite[\S~4.F]{Pascal}) to elided the "©this.©" by opening a scope containing field identifiers, changing the qualified fields into variables and giving an opportunity for optimizing qualified references.
    9161058\begin{cfa}
    917 int mem( S &this ) ®with this® { §\C{// with clause}§
    918         i = 1;                                          §\C{\color{red}// this->i}§
    919         j = 2;                                          §\C{\color{red}// this->j}§
     1059int mem( S & this ) ®with( this )® {            §\C{// with clause}§
     1060        i = 1;                                                                  §\C{\color{red}// this.i}§
     1061        j = 2;                                                                  §\C{\color{red}// this.j}§
    9201062}
    9211063\end{cfa}
    … …  
    9231065\begin{cfa}
    9241066struct T { double m, n; };
    925 int mem2( S &this1, T &this2 ) ®with this1, this2® {
     1067int mem2( S & this1, T & this2 ) ®with( this1, this2 )® {
    9261068        i = 1; j = 2;
    9271069        m = 1.0; n = 2.0;
    … …  
    9341076        struct S1 { ... } s1;
    9351077        struct S2 { ... } s2;
    936         ®with s1® {                     // with statement
     1078        ®with( s1 )® {                                                  §\C{// with statement}§
    9371079                // access fields of s1 without qualification
    938                 ®with s2® {  // nesting
     1080                ®with s2® {                                                     §\C{// nesting}§
    9391081                        // access fields of s1 and s2 without qualification
    9401082                }
    … …  
    9511093struct S { int i; int j; double m; } a, c;
    9521094struct T { int i; int k; int m } b, c;
    953 ®with a, b® {
    954         j + k;                                          §\C{// unambiguous, unique names define unique types}§
    955         i;                                                      §\C{// ambiguous, same name and type}§
    956         a.i + b.i;                                      §\C{// unambiguous, qualification defines unique names}§
    957         m;                                                      §\C{// ambiguous, same name and no context to define unique type}§
    958         m = 5.0;                                        §\C{// unambiguous, same name and context defines unique type}§
    959         m = 1;                                          §\C{// unambiguous, same name and context defines unique type}§
    960 }
    961 ®with c® { ... }                                §\C{// ambiguous, same name and no context}§
    962 ®with (S)c® { ... }                             §\C{// unambiguous, same name and cast defines unique type}§
    963 \end{cfa}
    964 
     1095with( a, b )
     1096{
     1097}
     1098\end{cfa}
     1099
     1100\begin{comment}
    9651101The components in the "with" clause
    9661102
    … …  
    9871123the "with" to be implemented because I hate having to type all those object
    9881124names for fields. It's a great way to drive people away from the language.
     1125\end{comment}
    9891126
    9901127
    … …  
    9961133Non-local transfer can cause stack unwinding, \ie non-local routine termination, depending on the kind of raise.
    9971134\begin{cfa}
    998 exception_t E {};                               §\C{// exception type}§
     1135exception_t E {};                                                       §\C{// exception type}§
    9991136void f(...) {
    1000         ... throw E{}; ...                      §\C{// termination}§
    1001         ... throwResume E{}; ...        §\C{// resumption}§
     1137        ... throw E{}; ...                                              §\C{// termination}§
     1138        ... throwResume E{}; ...                                §\C{// resumption}§
    10021139}
    10031140try {
    10041141        f(...);
    1005 } catch( E e ; §boolean-predicate§ ) {                  §\C[8cm]{// termination handler}§
     1142} catch( E e ; §boolean-predicate§ ) {          §\C[8cm]{// termination handler}§
    10061143        // recover and continue
    1007 } catchResume( E e ; §boolean-predicate§ ) {    §\C{// resumption handler}\CRT§
     1144} catchResume( E e ; §boolean-predicate§ ) { §\C{// resumption handler}\CRT§
    10081145        // repair and return
    10091146} finally {
    … …  
    10461183
    10471184
    1048 \section{Declarations}
    1049 \label{s:Declarations}
     1185\section{Alternative Declarations}
     1186\label{s:AlternativeDeclarations}
    10501187
    10511188C declaration syntax is notoriously confusing and error prone.
    10521189For example, many C programmers are confused by a declaration as simple as:
    1053 \begin{quote2}
     1190\begin{cquote}
    10541191\begin{tabular}{@{}ll@{}}
    10551192\begin{cfa}
    … …  
    10591196\raisebox{-0.75\totalheight}{\input{Cdecl}}
    10601197\end{tabular}
    1061 \end{quote2}
     1198\end{cquote}
    10621199Is this an array of 5 pointers to integers or a \Index{pointer} to an array of 5 integers?
    1063 The fact this declaration is unclear to many C programmers means there are \Index{productivity} and \Index{safety} issues even for basic programs.
     1200If there is any doubt, it implies \Index{productivity} and \Index{safety} issues even for basic programs.
    10641201Another example of confusion results from the fact that a routine name and its parameters are embedded within the return type, mimicking the way the return value is used at the routine's call site.
    10651202For example, a routine returning a \Index{pointer} to an array of integers is defined and used in the following way:
    10661203\begin{cfa}
    1067 int ®(*®f®())[®5®]® {...};                              §\C{definition}§
    1068  ... ®(*®f®())[®3®]® += 1;                              §\C{usage}§
     1204int ®(*®f®())[®5®]® {...};                              §\C{// definition}§
     1205 ... ®(*®f®())[®3®]® += 1;                              §\C{// usage}§
    10691206\end{cfa}
    10701207Essentially, the return type is wrapped around the routine name in successive layers (like an \Index{onion}).
    … …  
    10751212In the following example, \R{red} is the base type and \B{blue} is qualifiers.
    10761213The \CFA declarations move the qualifiers to the left of the base type, \ie move the blue to the left of the red, while the qualifiers have the same meaning but are ordered left to right to specify a variable's type.
    1077 \begin{quote2}
     1214\begin{cquote}
    10781215\begin{tabular}{@{}l@{\hspace{3em}}l@{}}
    10791216\multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}}        & \multicolumn{1}{c}{\textbf{C}}        \\
    … …  
    10901227\end{cfa}
    10911228\end{tabular}
    1092 \end{quote2}
     1229\end{cquote}
    10931230The only exception is \Index{bit field} specification, which always appear to the right of the base type.
    10941231% Specifically, the character ©*© is used to indicate a pointer, square brackets ©[©\,©]© are used to represent an array or function return value, and parentheses ©()© are used to indicate a routine parameter.
    10951232However, unlike C, \CFA type declaration tokens are distributed across all variables in the declaration list.
    10961233For instance, variables ©x© and ©y© of type \Index{pointer} to integer are defined in \CFA as follows:
    1097 \begin{quote2}
     1234\begin{cquote}
    10981235\begin{tabular}{@{}l@{\hspace{3em}}l@{}}
    10991236\multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}}        & \multicolumn{1}{c}{\textbf{C}}        \\
    … …  
    11061243\end{cfa}
    11071244\end{tabular}
    1108 \end{quote2}
     1245\end{cquote}
    11091246The downside of this semantics is the need to separate regular and \Index{pointer} declarations:
    1110 \begin{quote2}
     1247\begin{cquote}
    11111248\begin{tabular}{@{}l@{\hspace{3em}}l@{}}
    11121249\multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}}        & \multicolumn{1}{c}{\textbf{C}}        \\
    … …  
    11211258\end{cfa}
    11221259\end{tabular}
    1123 \end{quote2}
     1260\end{cquote}
    11241261which is \Index{prescribing} a safety benefit.
    11251262Other examples are:
    1126 \begin{quote2}
     1263\begin{cquote}
    11271264\begin{tabular}{@{}l@{\hspace{3em}}l@{\hspace{2em}}l@{}}
    11281265\multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}}        & \multicolumn{1}{c@{\hspace{2em}}}{\textbf{C}} \\
    … …  
    11601297\end{cfa}
    11611298\end{tabular}
    1162 \end{quote2}
     1299\end{cquote}
    11631300
    11641301All type qualifiers, \eg ©const©, ©volatile©, etc., are used in the normal way with the new declarations and also appear left to right, \eg:
    1165 \begin{quote2}
     1302\begin{cquote}
    11661303\begin{tabular}{@{}l@{\hspace{1em}}l@{\hspace{1em}}l@{}}
    11671304\multicolumn{1}{c@{\hspace{1em}}}{\textbf{\CFA}}        & \multicolumn{1}{c@{\hspace{1em}}}{\textbf{C}} \\
    … …  
    11811318\end{cfa}
    11821319\end{tabular}
    1183 \end{quote2}
     1320\end{cquote}
    11841321All declaration qualifiers, \eg ©extern©, ©static©, etc., are used in the normal way with the new declarations but can only appear at the start of a \CFA routine declaration,\footnote{\label{StorageClassSpecifier}
    11851322The placement of a storage-class specifier other than at the beginning of the declaration specifiers in a declaration is an obsolescent feature.~\cite[\S~6.11.5(1)]{C11}} \eg:
    1186 \begin{quote2}
     1323\begin{cquote}
    11871324\begin{tabular}{@{}l@{\hspace{3em}}l@{\hspace{2em}}l@{}}
    11881325\multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}}        & \multicolumn{1}{c@{\hspace{2em}}}{\textbf{C}} \\
    … …  
    12021339\end{cfa}
    12031340\end{tabular}
    1204 \end{quote2}
     1341\end{cquote}
    12051342
    12061343The new declaration syntax can be used in other contexts where types are required, \eg casts and the pseudo-routine ©sizeof©:
    1207 \begin{quote2}
     1344\begin{cquote}
    12081345\begin{tabular}{@{}l@{\hspace{3em}}l@{}}
    12091346\multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}}        & \multicolumn{1}{c}{\textbf{C}}        \\
    12101347\begin{cfa}
    1211 y = (®* int®)x;
    1212 i = sizeof(®[ 5 ] * int®);
     1348y = (* int)x;
     1349i = sizeof([ 5 ] * int);
    12131350\end{cfa}
    12141351&
    12151352\begin{cfa}
    1216 y = (®int *®)x;
    1217 i = sizeof(®int * [ 5 ]®);
     1353y = (int *)x;
     1354i = sizeof(int * [ 5 ]);
    12181355\end{cfa}
    12191356\end{tabular}
    1220 \end{quote2}
     1357\end{cquote}
    12211358
    12221359Finally, new \CFA declarations may appear together with C declarations in the same program block, but cannot be mixed within a specific declaration.
    12231360Therefore, a programmer has the option of either continuing to use traditional C declarations or take advantage of the new style.
    1224 Clearly, both styles need to be supported for some time due to existing C-style header-files, particularly for UNIX systems.
    1225 
    1226 
    1227 \section{Exponentiation Operator}
    1228 
    1229 C, \CC, and Java (and many other programming languages) have no exponentiation operator\index{exponentiation!operator}\index{operator!exponentiation}, \ie $x^y$, and instead use a routine, like \Indexc{pow}, to perform the exponentiation operation.
    1230 \CFA extends the basic operators with the exponentiation operator ©?\?©\index{?\\?@\lstinline$?\?$} and ©?\=?©\index{?\\=?@\lstinline$?\=?$}, as in, ©x \ y© and ©x \= y©, which means $x^y$ and $x \leftarrow x^y$.
    1231 The priority of the exponentiation operator is between the cast and multiplicative operators, so that ©w * (int)x \ (int)y * z© is parenthesized as ©((w * (((int)x) \ ((int)y))) * z)©.
    1232 
    1233 As for \Index{division}, there are exponentiation operators for integral and floating-point types, including the builtin \Index{complex} types.
    1234 Unsigned integral exponentiation\index{exponentiation!unsigned integral} is performed with repeated multiplication\footnote{The multiplication computation is optimized to $O(\log y)$.} (or shifting if the base is 2).
    1235 Signed integral exponentiation\index{exponentiation!signed integral} is performed with repeated multiplication (or shifting if the base is 2), but yields a floating-point result because $x^{-y}=1/x^y$.
    1236 Hence, it is important to designate exponent integral-constants as unsigned or signed: ©3 \ 3u© return an integral result, while ©3 \ 3© returns a floating-point result.
    1237 Floating-point exponentiation\index{exponentiation!floating point} is performed using \Index{logarithm}s\index{exponentiation!logarithm}, so the base cannot be negative.
    1238 \begin{cfa}
    1239 sout | 2 ®\® 8u | 4 ®\® 3u | -4 ®\® 3u | 4 ®\® -3 | -4 ®\® -3 | 4.0 ®\® 2.1 | (1.0f+2.0fi) ®\® (3.0f+2.0fi) | endl;
    1240 256 64 -64 0.015625 -0.015625 18.3791736799526 0.264715-1.1922i
    1241 \end{cfa}
    1242 Parenthesis are necessary for the complex constants or the expresion is parsed as ©1.0f+(2.0fi \ 3.0f)+2.0fi©.
    1243 The exponentiation operator is available for all the basic types, but for user-defined types, only the integral-computation versions are available.
    1244 For returning an integral value, the user type ©T© must define multiplication, ©*©, and one, ©1©;
    1245 for returning a floating-point value, an additional divide of type ©T© into a ©double© returning a ©double© (©double ?/?( double, T )©) is necessary for negative exponents.
     1361Clearly, both styles need to be supported for some time due to existing C-style header-files, particularly for UNIX-like systems.
    12461362
    12471363
    … …  
    12611377A program \newterm{object} is a region of data storage in the execution environment, the contents of which can represent values.
    12621378In most cases, objects are located in memory at an address, and the variable name for an object is an implicit address to the object generated by the compiler and automatically dereferenced, as in:
    1263 \begin{quote2}
     1379\begin{cquote}
    12641380\begin{tabular}{@{}ll@{\hspace{2em}}l@{}}
    12651381\begin{cfa}
    … …  
    12791395\end{cfa}
    12801396\end{tabular}
    1281 \end{quote2}
     1397\end{cquote}
    12821398where the right example is how the compiler logically interprets the variables in the left example.
    12831399Since a variable name only points to one address during its lifetime, it is an \Index{immutable} \Index{pointer};
    … …  
    12851401In general, variable addresses are stored in instructions instead of loaded from memory, and hence may not occupy storage.
    12861402These approaches are contrasted in the following:
    1287 \begin{quote2}
     1403\begin{cquote}
    12881404\begin{tabular}{@{}l|l@{}}
    12891405\multicolumn{1}{c|}{explicit variable address} & \multicolumn{1}{c}{implicit variable address} \\
    … …  
    13031419\end{cfa}
    13041420\end{tabular}
    1305 \end{quote2}
     1421\end{cquote}
    13061422Finally, the immutable nature of a variable's address and the fact that there is no storage for the variable pointer means pointer assignment\index{pointer!assignment}\index{assignment!pointer} is impossible.
    13071423Therefore, the expression ©x = y© has only one meaning, ©*x = *y©, \ie manipulate values, which is why explicitly writing the dereferences is unnecessary even though it occurs implicitly as part of \Index{instruction decoding}.
    … …  
    13101426(Similarly, an integer variable can contain multiple integer literals during its lifetime versus an integer constant representing a single literal during its lifetime, and like a variable name, may not occupy storage if the literal is embedded directly into instructions.)
    13111427Hence, a pointer occupies memory to store its current address, and the pointer's value is loaded by dereferencing, \eg:
    1312 \begin{quote2}
     1428\begin{cquote}
    13131429\begin{tabular}{@{}l@{\hspace{2em}}l@{}}
    13141430\begin{cfa}
    … …  
    13221438\raisebox{-0.5\totalheight}{\input{pointer2.pstex_t}}
    13231439\end{tabular}
    1324 \end{quote2}
     1440\end{cquote}
    13251441
    13261442Notice, an address has a \Index{duality}\index{address!duality}: a location in memory or the value at that location.
    … …  
    13311447\end{cfa}
    13321448Algol68 infers the following dereferencing ©*p2 = *p1 + x©, because adding the arbitrary integer value in ©x© to the address of ©p1© and storing the resulting address into ©p2© is an unlikely operation.
    1333 Unfortunately, automatic dereferencing does not work in all cases, and so some mechanism is necessary to fix incorrect choices. 
     1449Unfortunately, automatic dereferencing does not work in all cases, and so some mechanism is necessary to fix incorrect choices.
    13341450
    13351451Rather than inferring dereference, most programming languages pick one implicit dereferencing semantics, and the programmer explicitly indicates the other to resolve address-duality.
    … …  
    14271543The position of the ©const© qualifier \emph{after} the pointer/reference qualifier causes confuse for C programmers.
    14281544The ©const© qualifier cannot be moved before the pointer/reference qualifier for C style-declarations;
    1429 \CFA-style declarations (see \VRef{s:Declarations}) attempt to address this issue:
    1430 \begin{quote2}
     1545\CFA-style declarations (see \VRef{s:AlternativeDeclarations}) attempt to address this issue:
     1546\begin{cquote}
    14311547\begin{tabular}{@{}l@{\hspace{3em}}l@{}}
    14321548\multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}}        & \multicolumn{1}{c}{\textbf{C}}        \\
    … …  
    14411557\end{cfa}
    14421558\end{tabular}
    1443 \end{quote2}
     1559\end{cquote}
    14441560where the \CFA declaration is read left-to-right.
    14451561
    … …  
    15191635\begin{cfa}
    15201636void f( int i );
    1521 void (*fp)( int );                                      §\C{// routine pointer}§
     1637void (* fp)( int );                                     §\C{// routine pointer}§
    15221638fp = f;                                                         §\C{// reference initialization}§
    15231639fp = &f;                                                        §\C{// pointer initialization}§
    … …  
    15461662\begin{itemize}
    15471663\item
    1548 if ©R© is an \Index{rvalue} of type ©T &$_1$...&$_r$© where $r \ge 1$ references (©&© symbols) than ©&R© has type ©T ®*®&$_{\color{red}2}$...&$_{\color{red}r}$©, \ie ©T© pointer with $r-1$ references (©&© symbols).
    1549 
    1550 \item
    1551 if ©L© is an \Index{lvalue} of type ©T &$_1$...&$_l$© where $l \ge 0$ references (©&© symbols) then ©&L© has type ©T ®*®&$_{\color{red}1}$...&$_{\color{red}l}$©, \ie ©T© pointer with $l$ references (©&© symbols).
     1664if ©R© is an \Index{rvalue} of type ©T &©$_1\cdots$ ©&©$_r$, where $r \ge 1$ references (©&© symbols), than ©&R© has type ©T ®*®&©$_{\color{red}2}\cdots$ ©&©$_{\color{red}r}$, \ie ©T© pointer with $r-1$ references (©&© symbols).
     1665
     1666\item
     1667if ©L© is an \Index{lvalue} of type ©T &©$_1\cdots$ ©&©$_l$, where $l \ge 0$ references (©&© symbols), than ©&L© has type ©T ®*®&©$_{\color{red}1}\cdots$ ©&©$_{\color{red}l}$, \ie ©T© pointer with $l$ references (©&© symbols).
    15521668\end{itemize}
    15531669The following example shows the first rule applied to different \Index{rvalue} contexts:
    … …  
    15961712
    15971713\item
    1598 lvalue to reference conversion: \lstinline[deletekeywords=lvalue]$lvalue-type cv1 T$ converts to ©cv2 T &©, which allows implicitly converting variables to references.
     1714lvalue to reference conversion: \lstinline[deletekeywords=lvalue]@lvalue-type cv1 T@ converts to ©cv2 T &©, which allows implicitly converting variables to references.
    15991715\begin{cfa}
    16001716int x, &r = ®x®, f( int & p ); // lvalue variable (int) convert to reference (int &)
    … …  
    18982014\end{cfa}
    18992015This syntax allows a prototype declaration to be created by cutting and pasting source text from the routine definition header (or vice versa).
    1900 Like C, it is possible to declare multiple routine-prototypes in a single declaration, where the return type is distributed across \emph{all} routine names in the declaration list (see~\VRef{s:Declarations}), \eg:
     2016Like C, it is possible to declare multiple routine-prototypes in a single declaration, where the return type is distributed across \emph{all} routine names in the declaration list (see~\VRef{s:AlternativeDeclarations}), \eg:
    19012017\begin{cfa}
    19022018C :             const double bar1(), bar2( int ), bar3( double );
    … …  
    20732189Default arguments and overloading (see Section 24) are complementary.
    20742190While in theory default arguments can be simulated with overloading, as in:
    2075 \begin{quote2}
     2191\begin{cquote}
    20762192\begin{tabular}{@{}l@{\hspace{3em}}l@{}}
    20772193\multicolumn{1}{c@{\hspace{3em}}}{\textbf{default arguments}}   & \multicolumn{1}{c}{\textbf{overloading}}      \\
    … …  
    20882204\end{cfa}
    20892205\end{tabular}
    2090 \end{quote2}
     2206\end{cquote}
    20912207the number of required overloaded routines is linear in the number of default values, which is unacceptable growth.
    20922208In general, overloading should only be used over default arguments if the body of the routine is significantly different.
    … …  
    21662282        struct T t;
    21672283} s;
    2168        
     2284
    21692285
    21702286
    … …  
    22252341The following program in undefined in \CFA (and Indexc{gcc})
    22262342\begin{cfa}
    2227 [* [int]( int )] foo() {                §\C{// int (*foo())( int )}§
     2343[* [int]( int )] foo() {                §\C{// int (* foo())( int )}§
    22282344        int ®i® = 7;
    22292345        int bar( int p ) {
    … …  
    22342350}
    22352351int main() {
    2236         * [int]( int ) fp = foo();      §\C{// int (*fp)( int )}§
     2352        * [int]( int ) fp = foo();      §\C{// int (* fp)( int )}§
    22372353        sout | fp( 3 ) | endl;
    22382354}
    22392355\end{cfa}
    2240 because 
     2356because
    22412357
    22422358Currently, there are no \Index{lambda} expressions, \ie unnamed routines because routine names are very important to properly select the correct routine.
    … …  
    22732389In the latter approach, additional return values are passed as pointer parameters.
    22742390A pointer parameter is assigned inside the routine to emulate a return.
    2275 For example, consider C's \Indexc{modf} function, which returns the integral and fractional part of a floating-point value.
     2391For example, consider C's \Indexc{modf} function, which returns the integral and fractional part of a floating value.
    22762392\begin{cfa}
    22772393double modf( double x, double * i );            §\C{// from include math.h}§
    … …  
    29963112
    29973113The common case is printing out a sequence of variables separated by whitespace.
    2998 \begin{quote2}
     3114\begin{cquote}
    29993115\begin{tabular}{@{}l@{\hspace{3em}}l@{}}
    30003116\multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}}        & \multicolumn{1}{c}{\textbf{\CC}}      \\
    … …  
    30173133\end{cfa}
    30183134\end{tabular}
    3019 \end{quote2}
     3135\end{cquote}
    30203136The \CFA form has half the characters of the \CC form, and is similar to \Index*{Python} I/O with respect to implicit separators.
    30213137Similar simplification occurs for \Index{tuple} I/O, which prints all tuple values separated by ``\lstinline[showspaces=true]@, @''.
    … …  
    30293145Finally, \CFA uses the logical-or operator for I/O as it is the lowest-priority overloadable operator, other than assignment.
    30303146Therefore, fewer output expressions require parenthesis.
    3031 \begin{quote2}
     3147\begin{cquote}
    30323148\begin{tabular}{@{}ll@{}}
    30333149\textbf{\CFA:}
    … …  
    30483164\end{cfa}
    30493165\end{tabular}
    3050 \end{quote2}
     3166\end{cquote}
    30513167There is a weak similarity between the \CFA logical-or operator and the Shell pipe-operator for moving data, where data flows in the correct direction for input but the opposite direction for output.
    30523168
    … …  
    32783394        sout | sepDisable | 1 | 2 | 3 | endl;           // globally turn off implicit separator
    32793395        sout | sepEnable | 1 | 2 | 3 | endl;            // globally turn on implicit separator
    3280        
     3396
    32813397        sout | 1 | sepOff | 2 | 3 | endl;                       // locally turn on implicit separator
    32823398        sout | sepDisable | 1 | sepOn | 2 | 3 | endl; // globally turn off implicit separator
    … …  
    34213537        int id;
    34223538        float size;
    3423         Parts *optionalParts;
     3539        Parts * optionalParts;
    34243540};
    34253541
    … …  
    36353751
    36363752Auto type-inferencing occurs in a declaration where a variable's type is inferred from its initialization ex\-pression type.
    3637 \begin{quote2}
     3753\begin{cquote}
    36383754\begin{tabular}{@{}l@{\hspace{3em}}ll@{}}
    36393755\multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CC}} & \multicolumn{1}{c}{\textbf{\Indexc{gcc}}} \\
    … …  
    36593775\end{cfa}
    36603776\end{tabular}
    3661 \end{quote2}
     3777\end{cquote}
    36623778The two important capabilities are:
    36633779\begin{itemize}
    … …  
    38073923
    38083924generic(type T)
    3809 typedef int (*predicate)(T);
     3925typedef int (* predicate)(T);
    38103926generic(type Captured, type T)
    3811 typedef void (*callback)(Captured, T);
     3927typedef void (* callback)(Captured, T);
    38123928
    38133929generic(type T)
    3814 void find(int length, T *array,
     3930void find(int length, T * array,
    38153931        predicate(T) p, callback(void *, T)f) {
    38163932        int i;
    … …  
    38363952struct LinkedListElem {
    38373953        T elem;
    3838         LinkedListElem(T) *next;
     3954        LinkedListElem(T) * next;
    38393955};
    38403956
    3841 LinkedListElem *++?(LinkedListElem **elem) {
    3842         return *elem = elem->next;
     3957LinkedListElem *++?(LinkedListElem ** elem) {
     3958        return * elem = elem->next;
    38433959}
    38443960
    38453961generic (type T)
    38463962struct LinkedList {
    3847         LinkedListElem(T) *head;
     3963        LinkedListElem(T) * head;
    38483964        unsigned int size;
    38493965}
    38503966
    38513967generic (type T | bool ?==?(T, T))
    3852 bool contains(LinkedList(T) *list, T elem) {
    3853         for(LinkedListElem *iter = list->head; iter != 0; ++iter) {
     3968bool contains(LinkedList(T) * list, T elem) {
     3969        for(LinkedListElem * iter = list->head; iter != 0; ++iter) {
    38543970        if (iter->elem == elem) return true;
    38553971        }
    … …  
    40644180// transferring requires mutual exclusion and calls deleteJob
    40654181
    4066 void transferJob(mutex Worker &from, Worker &to) {
     4182void transferJob(mutex Worker & from, Worker & to) {
    40674183        ...
    40684184        deleteJob(j);
    … …  
    50025118#include <unistd.h>
    50035119}
    5004 size_t fileSize( const char *path ) {
     5120size_t fileSize( const char * path ) {
    50055121        struct stat s;
    50065122        stat(path, &s);
    … …  
    50395155#[link(name = "libc")]
    50405156extern {
    5041         fn stat(path: *const u8,
    5042         buf: *mut stat_t) -> c_int;
    5043 }
    5044 fn fileSize(path: *const u8) -> size_t
     5157        fn stat(path: * const u8,
     5158        buf: * mut stat_t) -> c_int;
     5159}
     5160fn fileSize(path: * const u8) -> size_t
    50455161{
    50465162        unsafe {
    … …  
    50645180generic(type T, type N |
    50655181        { int ?<?(N, N); })
    5066 T *maximize(N (*f)(const T&),
     5182T * maximize(N (*f)(const T&),
    50675183        int n, T *a) {
    5068         T *bestX = NULL;
     5184        T * bestX = NULL;
    50695185        N bestN;
    50705186        for (int i = 0; i < n; i++) {
    … …  
    50785194}
    50795195
    5080 string *longest(int n, string *p)
     5196string * longest(int n, string *p)
    50815197{
    50825198        return maximize(length, n, p);
    … …  
    50865202\begin{cfa}
    50875203template<typename T, typename F>
    5088 T *maximize(const F &f,
     5204T * maximize(const F &f,
    50895205        int n, T *a) {
    50905206        typedef decltype(f(a[0])) N;
    5091         T *bestX = NULL;
     5207        T * bestX = NULL;
    50925208        N bestN;
    50935209        for (int i = 0; i < n; i++) {
    … …  
    51015217}
    51025218
    5103 string *longest(int n, string *p) {
     5219string * longest(int n, string *p) {
    51045220        return maximize(
    51055221        [](const string &s) {
    … …  
    52595375\begin{cfa}
    52605376task Nonzero {
    5261         int *data;
     5377        int * data;
    52625378        int start;
    52635379        int end;
    … …  
    57225838\CFA introduces the following new keywords.
    57235839
    5724 \begin{quote2}
     5840\begin{cquote}
    57255841\input{../refrat/keywords}
    5726 \end{quote2}
     5842\end{cquote}
    57275843
    57285844
    … …  
    57315847
    57325848\Celeven prescribes the following standard header-files~\cite[\S~7.1.2]{C11} and \CFA adds to this list:
    5733 \begin{quote2}
     5849\begin{cquote}
    57345850\begin{tabular}{@{}llllll|l@{}}
    57355851\multicolumn{6}{c|}{C11} & \multicolumn{1}{c}{\CFA}             \\
    … …  
    57915907\end{tabular}
    57925908\end{tabular}
    5793 \end{quote2}
     5909\end{cquote}
    57945910For the prescribed head-files, \CFA uses header interposition to wraps these includes in an ©extern "C"©;
    57955911hence, names in these include files are not mangled\index{mangling!name} (see~\VRef{s:Interoperability}).
    … …  
    58515967void * memalign( size_t align, size_t size );§\indexc{memalign}§
    58525968int posix_memalign( void ** ptr, size_t align, size_t size );§\indexc{posix_memalign}§
    5853 }
    5854 
    5855 // §\CFA§ safe equivalents, i.e., implicit size specification
    5856 forall( dtype T | sized(T) ) T * malloc( void );
    5857 forall( dtype T | sized(T) ) T * calloc( size_t dim );
    5858 forall( dtype T | sized(T) ) T * realloc( T * ptr, size_t size );
    5859 forall( dtype T | sized(T) ) T * memalign( size_t align );
    5860 forall( dtype T | sized(T) ) T * aligned_alloc( size_t align );
    5861 forall( dtype T | sized(T) ) int posix_memalign( T ** ptr, size_t align );
    5862 
    5863 // §\CFA§ safe general allocation, fill, resize, array
    5864 forall( dtype T | sized(T) ) T * alloc( void );§\indexc{alloc}§
    5865 forall( dtype T | sized(T) ) T * alloc( char fill );
    5866 forall( dtype T | sized(T) ) T * alloc( size_t dim );
    5867 forall( dtype T | sized(T) ) T * alloc( size_t dim, char fill );
    5868 forall( dtype T | sized(T) ) T * alloc( T ptr[], size_t dim );
    5869 forall( dtype T | sized(T) ) T * alloc( T ptr[], size_t dim, char fill );
    5870 
    5871 // §\CFA§ safe general allocation, align, fill, array
    5872 forall( dtype T | sized(T) ) T * align_alloc( size_t align );
    5873 forall( dtype T | sized(T) ) T * align_alloc( size_t align, char fill );
    5874 forall( dtype T | sized(T) ) T * align_alloc( size_t align, size_t dim );
    5875 forall( dtype T | sized(T) ) T * align_alloc( size_t align, size_t dim, char fill );
    58765969
    58775970// C unsafe initialization/copy
    5878 extern "C" {
    58795971void * memset( void * dest, int c, size_t size );
    58805972void * memcpy( void * dest, const void * src, size_t size );
    58815973}
    58825974
     5975forall( dtype T | sized(T) ) {
     5976// §\CFA§ safe equivalents, i.e., implicit size specification
     5977        T * malloc( void );
     5978        T * calloc( size_t dim );
     5979        T * realloc( T * ptr, size_t size );
     5980        T * memalign( size_t align );
     5981        T * aligned_alloc( size_t align );
     5982        int posix_memalign( T ** ptr, size_t align );
     5983
     5984// §\CFA§ safe general allocation, fill, resize, array
     5985        T * alloc( void );§\indexc{alloc}§
     5986        T * alloc( char fill );
     5987        T * alloc( size_t dim );
     5988        T * alloc( size_t dim, char fill );
     5989        T * alloc( T ptr[], size_t dim );
     5990        T * alloc( T ptr[], size_t dim, char fill );
     5991
     5992// §\CFA§ safe general allocation, align, fill, array
     5993        T * align_alloc( size_t align );
     5994        T * align_alloc( size_t align, char fill );
     5995        T * align_alloc( size_t align, size_t dim );
     5996        T * align_alloc( size_t align, size_t dim, char fill );
     5997
    58835998// §\CFA§ safe initialization/copy, i.e., implicit size specification
    5884 forall( dtype T | sized(T) ) T * memset( T * dest, char c );§\indexc{memset}§
    5885 forall( dtype T | sized(T) ) T * memcpy( T * dest, const T * src );§\indexc{memcpy}§
     5999        T * memset( T * dest, char c );§\indexc{memset}§
     6000        T * memcpy( T * dest, const T * src );§\indexc{memcpy}§
    58866001
    58876002// §\CFA§ safe initialization/copy array
    5888 forall( dtype T | sized(T) ) T * memset( T dest[], size_t dim, char c );
    5889 forall( dtype T | sized(T) ) T * memcpy( T dest[], const T src[], size_t dim );
     6003        T * amemset( T dest[], char c, size_t dim );
     6004        T * amemcpy( T dest[], const T src[], size_t dim );
     6005}
    58906006
    58916007// §\CFA§ allocation/deallocation and constructor/destructor
    … …  
    59036019
    59046020
    5905 \subsection{Conversion}
     6021\subsection{String to Value Conversion}
    59066022
    59076023\leavevmode
    … …  
    59476063forall( otype T | { int ?<?( T, T ); } )
    59486064void qsort( const T * arr, size_t dim );§\indexc{qsort}§
     6065
     6066forall( otype E | { int ?<?( E, E ); } ) {
     6067        E * bsearch( E key, const E * vals, size_t dim );§\indexc{bsearch}§     §\C{// location}§
     6068        size_t bsearch( E key, const E * vals, size_t dim );§\C{// position}§
     6069        E * bsearchl( E key, const E * vals, size_t dim );§\indexc{bsearchl}§
     6070        size_t bsearchl( E key, const E * vals, size_t dim );
     6071        E * bsearchu( E key, const E * vals, size_t dim );§\indexc{bsearchu}§
     6072        size_t bsearchu( E key, const E * vals, size_t dim );
     6073}
     6074
     6075forall( otype K, otype E | { int ?<?( K, K ); K getKey( const E & ); } ) {
     6076        E * bsearch( K key, const E * vals, size_t dim );
     6077        size_t bsearch( K key, const E * vals, size_t dim );
     6078        E * bsearchl( K key, const E * vals, size_t dim );
     6079        size_t bsearchl( K key, const E * vals, size_t dim );
     6080        E * bsearchu( K key, const E * vals, size_t dim );
     6081        size_t bsearchu( K key, const E * vals, size_t dim );
     6082}
     6083
     6084forall( otype E | { int ?<?( E, E ); } ) {
     6085        void qsort( E * vals, size_t dim );§\indexc{qsort}§
     6086}
    59496087\end{cfa}
    59506088
    … …  
    59736111\leavevmode
    59746112\begin{cfa}[aboveskip=0pt,belowskip=0pt]
    5975 void rand48seed( long int s );§\indexc{rand48seed}§
    5976 char rand48();§\indexc{rand48}§
    5977 int rand48();
    5978 unsigned int rand48();
    5979 long int rand48();
    5980 unsigned long int rand48();
    5981 float rand48();
    5982 double rand48();
    5983 float _Complex rand48();
    5984 double _Complex rand48();
    5985 long double _Complex rand48();
     6113void srandom( unsigned int seed );§\indexc{srandom}§
     6114char random( void );§\indexc{random}§
     6115char random( char u );                                          §\C{// [0,u)}§
     6116char random( char l, char u );                          §\C{// [l,u)}§
     6117int random( void );
     6118int random( int u );                                            §\C{// [0,u)}§
     6119int random( int l, int u );                                     §\C{// [l,u)}§
     6120unsigned int random( void );
     6121unsigned int random( unsigned int u );          §\C{// [0,u)}§
     6122unsigned int random( unsigned int l, unsigned int u ); §\C{// [l,u)}§
     6123long int random( void );
     6124long int random( long int u );                          §\C{// [0,u)}§
     6125long int random( long int l, long int u );      §\C{// [l,u)}§
     6126unsigned long int random( void );
     6127unsigned long int random( unsigned long int u ); §\C{// [0,u)}§
     6128unsigned long int random( unsigned long int l, unsigned long int u ); §\C{// [l,u)}§
     6129float random( void );                                            §\C{// [0.0, 1.0)}§
     6130double random( void );                                           §\C{// [0.0, 1.0)}§
     6131float _Complex random( void );                           §\C{// [0.0, 1.0)+[0.0, 1.0)i}§
     6132double _Complex random( void );                          §\C{// [0.0, 1.0)+[0.0, 1.0)i}§
     6133long double _Complex random( void );             §\C{// [0.0, 1.0)+[0.0, 1.0)i}§
    59866134\end{cfa}
    59876135
    … …  
    63596507double scalbln( double, long int );
    63606508long double scalbln( long double, long int );
     6509\end{cfa}
     6510
     6511
     6512\section{Time Keeping}
     6513\label{s:TimeKeeping}
     6514
     6515
     6516%\subsection{\texorpdfstring{\protect\lstinline@Duration@}{Duration}}
     6517\subsection{\texorpdfstring{\LstBasicStyle{Duration}}{Duration}}
     6518\label{s:Duration}
     6519
     6520\leavevmode
     6521\begin{cfa}[aboveskip=0pt,belowskip=0pt]
     6522struct Duration {
     6523        int64_t tv;                                                     §\C{// nanoseconds}§
     6524};
     6525
     6526void ?{}( Duration & dur );
     6527void ?{}( Duration & dur, zero_t );
     6528
     6529Duration ?=?( Duration & dur, zero_t );
     6530
     6531Duration +?( Duration rhs );
     6532Duration ?+?( Duration & lhs, Duration rhs );
     6533Duration ?+=?( Duration & lhs, Duration rhs );
     6534
     6535Duration -?( Duration rhs );
     6536Duration ?-?( Duration & lhs, Duration rhs );
     6537Duration ?-=?( Duration & lhs, Duration rhs );
     6538
     6539Duration ?*?( Duration lhs, int64_t rhs );
     6540Duration ?*?( int64_t lhs, Duration rhs );
     6541Duration ?*=?( Duration & lhs, int64_t rhs );
     6542
     6543int64_t ?/?( Duration lhs, Duration rhs );
     6544Duration ?/?( Duration lhs, int64_t rhs );
     6545Duration ?/=?( Duration & lhs, int64_t rhs );
     6546double div( Duration lhs, Duration rhs );
     6547
     6548Duration ?%?( Duration lhs, Duration rhs );
     6549Duration ?%=?( Duration & lhs, Duration rhs );
     6550
     6551_Bool ?==?( Duration lhs, Duration rhs );
     6552_Bool ?!=?( Duration lhs, Duration rhs );
     6553_Bool ?<? ( Duration lhs, Duration rhs );
     6554_Bool ?<=?( Duration lhs, Duration rhs );
     6555_Bool ?>? ( Duration lhs, Duration rhs );
     6556_Bool ?>=?( Duration lhs, Duration rhs );
     6557
     6558_Bool ?==?( Duration lhs, zero_t );
     6559_Bool ?!=?( Duration lhs, zero_t );
     6560_Bool ?<? ( Duration lhs, zero_t );
     6561_Bool ?<=?( Duration lhs, zero_t );
     6562_Bool ?>? ( Duration lhs, zero_t );
     6563_Bool ?>=?( Duration lhs, zero_t );
     6564
     6565Duration abs( Duration rhs );
     6566
     6567Duration ?`ns( int64_t nsec );
     6568Duration ?`us( int64_t usec );
     6569Duration ?`ms( int64_t msec );
     6570Duration ?`s( int64_t sec );
     6571Duration ?`s( double sec );
     6572Duration ?`m( int64_t min );
     6573Duration ?`m( double min );
     6574Duration ?`h( int64_t hours );
     6575Duration ?`h( double hours );
     6576Duration ?`d( int64_t days );
     6577Duration ?`d( double days );
     6578Duration ?`w( int64_t weeks );
     6579Duration ?`w( double weeks );
     6580
     6581int64_t ?`ns( Duration dur );
     6582int64_t ?`us( Duration dur );
     6583int64_t ?`ms( Duration dur );
     6584int64_t ?`s( Duration dur );
     6585int64_t ?`m( Duration dur );
     6586int64_t ?`h( Duration dur );
     6587int64_t ?`d( Duration dur );
     6588int64_t ?`w( Duration dur );
     6589
     6590Duration max( Duration lhs, Duration rhs );
     6591Duration min( Duration lhs, Duration rhs );
     6592\end{cfa}
     6593
     6594
     6595%\subsection{\texorpdfstring{\protect\lstinline@\timeval@}{timeval}}
     6596\subsection{\texorpdfstring{\LstBasicStyle{timeval}}{timeval}}
     6597\label{s:timeval}
     6598
     6599\leavevmode
     6600\begin{cfa}[aboveskip=0pt,belowskip=0pt]
     6601void ?{}( timeval & t );
     6602void ?{}( timeval & t, time_t sec, suseconds_t usec );
     6603void ?{}( timeval & t, time_t sec );
     6604void ?{}( timeval & t, zero_t );
     6605void ?{}( timeval & t, Time time );
     6606
     6607timeval ?=?( timeval & t, zero_t );
     6608timeval ?+?( timeval & lhs, timeval rhs );
     6609timeval ?-?( timeval & lhs, timeval rhs );
     6610_Bool ?==?( timeval lhs, timeval rhs );
     6611_Bool ?!=?( timeval lhs, timeval rhs );
     6612\end{cfa}
     6613
     6614
     6615%\subsection{\texorpdfstring{\protect\lstinline@timespec@}{timespec}}
     6616\subsection{\texorpdfstring{\LstBasicStyle{timespec}}{timespec}}
     6617\label{s:timespec}
     6618
     6619\leavevmode
     6620\begin{cfa}[aboveskip=0pt,belowskip=0pt]
     6621void ?{}( timespec & t );
     6622void ?{}( timespec & t, time_t sec, __syscall_slong_t nsec );
     6623void ?{}( timespec & t, time_t sec );
     6624void ?{}( timespec & t, zero_t );
     6625void ?{}( timespec & t, Time time );
     6626
     6627timespec ?=?( timespec & t, zero_t );
     6628timespec ?+?( timespec & lhs, timespec rhs );
     6629timespec ?-?( timespec & lhs, timespec rhs );
     6630_Bool ?==?( timespec lhs, timespec rhs );
     6631_Bool ?!=?( timespec lhs, timespec rhs );
     6632\end{cfa}
     6633
     6634
     6635%\subsection{\texorpdfstring{\protect\lstinline@itimerval@}{itimerval}}
     6636\subsection{\texorpdfstring{\LstBasicStyle{itimerval}}{itimerval}}
     6637\label{s:itimerval}
     6638
     6639\leavevmode
     6640\begin{cfa}[aboveskip=0pt,belowskip=0pt]
     6641void ?{}( itimerval & itv, Duration alarm );
     6642void ?{}( itimerval & itv, Duration alarm, Duration interval );
     6643\end{cfa}
     6644
     6645
     6646%\subsection{\texorpdfstring{\protect\lstinline@Time@}{Time}}
     6647\subsection{\texorpdfstring{\LstBasicStyle{Time}}{Time}}
     6648\label{s:Time}
     6649
     6650\leavevmode
     6651\begin{cfa}[aboveskip=0pt,belowskip=0pt]
     6652struct Time {
     6653        uint64_t tv;                                            §\C{// nanoseconds since UNIX epoch}§
     6654};
     6655
     6656void ?{}( Time & time );
     6657void ?{}( Time & time, zero_t );
     6658
     6659Time ?=?( Time & time, zero_t );
     6660
     6661void ?{}( Time & time, timeval t );
     6662Time ?=?( Time & time, timeval t );
     6663
     6664void ?{}( Time & time, timespec t );
     6665Time ?=?( Time & time, timespec t );
     6666
     6667Time ?+?( Time & lhs, Duration rhs );
     6668Time ?+?( Duration lhs, Time rhs );
     6669Time ?+=?( Time & lhs, Duration rhs );
     6670
     6671Duration ?-?( Time lhs, Time rhs );
     6672Time ?-?( Time lhs, Duration rhs );
     6673Time ?-=?( Time & lhs, Duration rhs );
     6674_Bool ?==?( Time lhs, Time rhs );
     6675_Bool ?!=?( Time lhs, Time rhs );
     6676_Bool ?<?( Time lhs, Time rhs );
     6677_Bool ?<=?( Time lhs, Time rhs );
     6678_Bool ?>?( Time lhs, Time rhs );
     6679_Bool ?>=?( Time lhs, Time rhs );
     6680
     6681char * yy_mm_dd( Time time, char * buf );
     6682char * ?`ymd( Time time, char * buf ) { // short form
     6683        return yy_mm_dd( time, buf );
     6684} // ymd
     6685
     6686char * mm_dd_yy( Time time, char * buf );
     6687char * ?`mdy( Time time, char * buf ) { // short form
     6688        return mm_dd_yy( time, buf );
     6689} // mdy
     6690
     6691char * dd_mm_yy( Time time, char * buf );
     6692char * ?`dmy( Time time, char * buf ) { // short form
     6693        return dd_mm_yy( time, buf );;
     6694} // dmy
     6695
     6696size_t strftime( char * buf, size_t size, const char * fmt, Time time );
     6697forall( dtype ostype | ostream( ostype ) ) ostype & ?|?( ostype & os, Time time );
     6698\end{cfa}
     6699
     6700
     6701\section{Clock}
     6702
     6703\subsection{C time}
     6704\label{s:Ctime}
     6705
     6706\leavevmode
     6707\begin{cfa}[aboveskip=0pt,belowskip=0pt]
     6708char * ctime( time_t tp );
     6709char * ctime_r( time_t tp, char * buf );
     6710tm * gmtime( time_t tp );
     6711tm * gmtime_r( time_t tp, tm * result );
     6712tm * localtime( time_t tp );
     6713tm * localtime_r( time_t tp, tm * result );
     6714\end{cfa}
     6715
     6716
     6717%\subsection{\texorpdfstring{\protect\lstinline@Clock@}{Clock}}
     6718\subsection{\texorpdfstring{\LstBasicStyle{Clock}}{Clock}}
     6719\label{s:Clock}
     6720
     6721\leavevmode
     6722\begin{cfa}[aboveskip=0pt,belowskip=0pt]
     6723struct Clock {
     6724        Duration offset;                                        §\C{// for virtual clock: contains offset from real-time}§
     6725        int clocktype;                                          §\C{// implementation only -1 (virtual), CLOCK\_REALTIME}§
     6726};
     6727
     6728void resetClock( Clock & clk );
     6729void resetClock( Clock & clk, Duration adj );
     6730void ?{}( Clock & clk );
     6731void ?{}( Clock & clk, Duration adj );
     6732
     6733Duration getResNsec();                                  §\C{// with nanoseconds}§
     6734Duration getRes();                                              §\C{// without nanoseconds}§
     6735
     6736Time getTimeNsec();                                             §\C{// with nanoseconds}§
     6737Time getTime();                                                 §\C{// without nanoseconds}§
     6738Time getTime( Clock & clk );
     6739Time ?()( Clock & clk );
     6740timeval getTime( Clock & clk );
     6741tm getTime( Clock & clk );
    63616742\end{cfa}
    63626743
    … …  
    65326913The following factorial programs contrast using GMP with the \CFA and C interfaces, where the output from these programs appears in \VRef[Figure]{f:MultiPrecisionFactorials}.
    65336914(Compile with flag \Indexc{-lgmp} to link with the GMP library.)
    6534 \begin{quote2}
     6915\begin{cquote}
    65356916\begin{tabular}{@{}l@{\hspace{\parindentlnth}}|@{\hspace{\parindentlnth}}l@{}}
    65366917\multicolumn{1}{c|@{\hspace{\parindentlnth}}}{\textbf{\CFA}}    & \multicolumn{1}{@{\hspace{\parindentlnth}}c}{\textbf{C}}      \\
    … …  
    65646945\end{cfa}
    65656946\end{tabular}
    6566 \end{quote2}
     6947\end{cquote}
    65676948
    65686949\begin{figure}
    … …  
    66597040\end{cfa}
    66607041
    6661 
    66627042\bibliographystyle{plain}
    6663 \bibliography{cfa}
     7043\bibliography{pl}
    66647044
    66657045
Note: See TracChangeset for help on using the changeset viewer.