Changeset 4096de0


Ignore:
Timestamp:
Jul 6, 2016, 9:11:20 PM (8 years ago)
Author:
Peter A. Buhr <pabuhr@…>
Branches:
ADT, aaron-thesis, arm-eh, ast-experimental, cleanup-dtors, ctor, deferred_resn, demangler, enum, forall-pointer-decay, jacob/cs343-translation, jenkins-sandbox, master, memory, new-ast, new-ast-unique-expr, new-env, no_list, persistent-indexer, pthread-emulation, qualifiedEnum, resolv-new, with_gc
Children:
a17e7b8
Parents:
99f11dd
Message:

write pointer/reference section, update LaTeX macros

Location:
doc
Files:
6 edited

Legend:

Unmodified
Added
Removed
  • doc/LaTeXmacros/common.tex

    r99f11dd r4096de0  
    1111%% Created On       : Sat Apr  9 10:06:17 2016
    1212%% Last Modified By : Peter A. Buhr
    13 %% Last Modified On : Mon Jun 20 09:35:20 2016
    14 %% Update Count     : 178
     13%% Last Modified On : Sun Jul  3 08:36:24 2016
     14%% Update Count     : 200
    1515%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
    1616
     
    2727\righthyphenmin=4
    2828
    29 \usepackage{pslatex}                            % reduce size of san serif font
     29%\usepackage{pslatex}                           % reduce size of san serif font
    3030
    3131\usepackage[ignoredisplayed]{enumitem}  % do not affect trivlist
     
    3636\setlist[enumerate]{listparindent=\parindent}% global
    3737\setlist[enumerate,2]{leftmargin=\parindent,labelsep=*,align=parleft,label=\alph*.}% local
    38 \setlist[description]{listparindent=\parindent,leftmargin=\parindent,labelsep=*}
     38\setlist[description]{itemsep=0pt,listparindent=\parindent,leftmargin=\parindent,labelsep=1.5ex}
    3939
    4040% Names used in the document.
     
    5252\newlength{\parindentlnth}
    5353\setlength{\parindentlnth}{\parindent}
     54
     55\newlength{\gcolumnposn}
     56\newlength{\columnposn}
     57\setlength{\gcolumnposn}{2.5in}
     58\setlength{\columnposn}{\gcolumnposn}
     59\newcommand{\C}[2][\@empty]{\ifx#1\@empty\else\global\setlength{\columnposn}{#1}\global\columnposn=\columnposn\fi\hfill\makebox[\textwidth-\columnposn][l]{\lst@commentstyle{#2}}}
     60\newcommand{\CRT}{\global\columnposn=\gcolumnposn}
    5461
    5562% allow escape sequence in lstinline
     
    123130\newcommand{\indexc}[1]{\index{#1@\lstinline$#1$}}
    124131
     132% Denote newterms in particular font and index them without particular font and in lowercase, e.g., \newterm{abc}.
     133% The option parameter provides an index term different from the new term, e.g., \newterm[\texttt{abc}]{abc}
     134% The star version does not lowercase the index information, e.g., \newterm*{IBM}.
    125135\newcommand{\newtermFontInline}{\emph}
    126136\newcommand{\newterm}{\@ifstar\@snewterm\@newterm}
     
    204214\lstset{
    205215language=CFA,
    206 columns=flexible,
     216columns=fullflexible,
    207217basicstyle=\linespread{0.9}\sf,
    208218stringstyle=\tt,
  • doc/refrat/refrat.tex

    r99f11dd r4096de0  
    1111%% Created On       : Wed Apr  6 14:52:25 2016
    1212%% Last Modified By : Peter A. Buhr
    13 %% Last Modified On : Sat Jun 18 19:21:30 2016
    14 %% Update Count     : 74
     13%% Last Modified On : Wed Jun 22 14:18:30 2016
     14%% Update Count     : 77
    1515%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
    1616
     
    4949\renewcommand{\UrlFont}{\small\sf}
    5050
     51\setlength{\topmargin}{-0.45in}                                                 % move running title into header
     52\setlength{\headsep}{0.25in}
     53
    5154%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
    5255
     
    6972%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
    7073
    71 \begin{document}
    72 \pagestyle{headings}
    73 \linenumbers                                            % comment out to turn off line numbering
    74 
    7574\title{\Huge
    7675\vspace*{1in}
    7776\CFA (\CFL) Reference Manual and Rationale
    7877}% title
     78
    7979\author{\huge
    8080Glen Ditchfield and Peter A. Buhr
    8181}% author
     82
    8283\date{
    83 DRAFT \\
    84 \today
     84DRAFT \\ \today
    8585}% date
    8686
     87%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
     88
     89\begin{document}
     90\pagestyle{headings}
     91% changed after setting pagestyle
     92\renewcommand{\chaptermark}[1]{\markboth{\thechapter\quad #1}{\thechapter\quad #1}}
     93\renewcommand{\sectionmark}[1]{\markboth{\thesection\quad #1}{\thesection\quad #1}}
    8794\pagenumbering{roman}
    88 \pagestyle{plain}
     95\linenumbers                                            % comment out to turn off line numbering
    8996
    9097\maketitle
    91 
     98\thispagestyle{empty}
    9299\vspace*{\fill}
    93 \thispagestyle{empty}
    94100\noindent
    95101\copyright\,2015 Glen Ditchfield \\ \\
  • doc/user/Cdecl.fig

    r99f11dd r4096de0  
    88-2
    991200 2
    10 6 1125 1200 2025 1650
    11 2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
    12          1275 1200 2025 1200 2025 1350 1275 1350 1275 1200
    13 2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
    14          1425 1200 1425 1350
    15 2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
    16          1575 1200 1575 1350
    17 2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
    18          1725 1200 1725 1350
    19 2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
    20          1875 1200 1875 1350
    21 2 1 0 1 0 7 50 -1 -1 4.000 0 0 -1 1 0 2
    22         1 1 1.00 45.00 90.00
    23          1350 1275 1350 1500
    24 2 1 0 1 0 7 50 -1 -1 4.000 0 0 -1 1 0 2
    25         1 1 1.00 45.00 90.00
    26          1500 1275 1500 1500
    27 2 1 0 1 0 7 50 -1 -1 4.000 0 0 -1 1 0 2
    28         1 1 1.00 45.00 90.00
    29          1650 1275 1650 1500
    30 2 1 0 1 0 7 50 -1 -1 4.000 0 0 -1 1 0 2
    31         1 1 1.00 45.00 90.00
    32          1800 1275 1800 1500
    33 2 1 0 1 0 7 50 -1 -1 4.000 0 0 -1 1 0 2
    34         1 1 1.00 45.00 90.00
    35          1950 1275 1950 1500
    36 4 1 0 50 -1 4 10 0.0000 2 105 90 1350 1650 0\001
    37 4 1 0 50 -1 4 10 0.0000 2 105 90 1500 1650 1\001
    38 4 1 0 50 -1 4 10 0.0000 2 105 90 1650 1650 2\001
    39 4 1 0 50 -1 4 10 0.0000 2 105 90 1800 1650 3\001
    40 4 1 0 50 -1 4 10 0.0000 2 105 90 1950 1650 4\001
    41 4 1 0 50 -1 4 10 0.0000 2 75 75 1200 1325 x\001
    42 -6
    43 6 2325 1200 3600 1350
    44 6 2475 1200 3600 1350
    45106 2850 1200 3600 1350
    46112 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
     
    54192 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
    5520         2850 1200 3600 1200 3600 1350 2850 1350 2850 1200
    56 4 1 0 50 -1 4 10 0.0000 2 105 90 2925 1325 0\001
    57 4 1 0 50 -1 4 10 0.0000 2 105 90 3075 1325 1\001
    58 4 1 0 50 -1 4 10 0.0000 2 105 90 3225 1325 2\001
    59 4 1 0 50 -1 4 10 0.0000 2 105 90 3375 1325 3\001
    60 4 1 0 50 -1 4 10 0.0000 2 105 90 3525 1325 4\001
     214 1 0 50 -1 4 10 0.0000 2 120 90 2925 1325 0\001
     224 1 0 50 -1 4 10 0.0000 2 120 90 3075 1325 1\001
     234 1 0 50 -1 4 10 0.0000 2 120 90 3225 1325 2\001
     244 1 0 50 -1 4 10 0.0000 2 120 90 3375 1325 3\001
     254 1 0 50 -1 4 10 0.0000 2 120 90 3525 1325 4\001
    6126-6
    62272 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
     28         1275 1200 2025 1200 2025 1350 1275 1350 1275 1200
     292 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
     30         1425 1200 1425 1350
     312 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
     32         1575 1200 1575 1350
     332 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
     34         1725 1200 1725 1350
     352 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
     36         1875 1200 1875 1350
     372 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
     38        1 1 1.00 45.00 60.00
     39         1950 1275 1950 1500
     402 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
     41        1 1 1.00 45.00 60.00
     42         1350 1275 1350 1500
     432 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
     44        1 1 1.00 45.00 60.00
     45         1500 1275 1500 1500
     462 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
     47        1 1 1.00 45.00 60.00
     48         1650 1275 1650 1500
     492 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
     50        1 1 1.00 45.00 60.00
     51         1800 1275 1800 1500
     522 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
    6353         2475 1200 2625 1200 2625 1350 2475 1350 2475 1200
    64 2 1 0 1 0 7 50 -1 -1 4.000 0 0 -1 1 0 2
    65         1 1 1.00 45.00 90.00
     542 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
     55        1 1 1.00 45.00 60.00
    6656         2550 1275 2850 1275
    67 -6
    68 4 1 0 50 -1 4 10 0.0000 2 75 75 2400 1325 x\001
    69 -6
     574 1 0 50 -1 4 10 0.0000 2 120 90 1350 1650 0\001
     584 1 0 50 -1 4 10 0.0000 2 120 90 1500 1650 1\001
     594 1 0 50 -1 4 10 0.0000 2 120 90 1650 1650 2\001
     604 1 0 50 -1 4 10 0.0000 2 120 90 1800 1650 3\001
     614 1 0 50 -1 4 10 0.0000 2 120 90 1950 1650 4\001
     624 1 0 50 -1 4 10 0.0000 2 90 90 1200 1325 x\001
     634 1 0 50 -1 4 10 0.0000 2 90 90 2400 1325 x\001
  • doc/user/Makefile

    r99f11dd r4096de0  
    1313FIGURES = ${addsuffix .tex, \
    1414Cdecl \
     15pointer1 \
    1516}
    1617
    1718PICTURES = ${addsuffix .pstex, \
     19pointer2 \
    1820}
    1921
     
    7173        fig2dev -L ps $< > $@
    7274
     75%.pstex : %.fig
     76        fig2dev -L pstex $< > $@
     77        fig2dev -L pstex_t -p $@ $< > $@_t
     78
    7379# Local Variables: #
    7480# compile-command: "make" #
  • doc/user/pointer2.fig

    r99f11dd r4096de0  
    88-2
    991200 2
    10 6 2775 1500 4425 2250
     102 1 0 1 4 7 100 -1 -1 0.000 0 0 -1 1 0 2
     11        1 1 1.00 45.00 90.00
     12         2550 1800 1800 1950
     132 1 0 1 4 7 50 -1 -1 0.000 0 0 -1 1 0 2
     14        1 1 1.00 45.00 90.00
     15         2550 1950 1800 1800
    11162 2 0 1 0 7 100 0 -1 0.000 0 0 -1 0 0 5
    12          3150 1950 4050 1950 4050 2250 3150 2250 3150 1950
     17         1500 1500 1800 1500 1800 1800 1500 1800 1500 1500
    13182 2 0 1 0 7 100 0 -1 0.000 0 0 -1 0 0 5
    14          3150 1500 4050 1500 4050 1800 3150 1800 3150 1500
    15 4 2 0 100 0 4 10 0.0000 2 120 270 3075 2250 112\001
    16 4 2 0 100 0 4 10 0.0000 2 120 270 3075 1800 108\001
    17 4 2 0 100 0 4 10 0.0000 2 150 180 3075 2075 p2\001
    18 4 0 0 100 0 4 10 0.0000 2 120 270 4125 2150 int *\001
    19 4 0 0 100 0 4 10 0.0000 2 120 270 4125 1700 int *\001
    20 4 2 0 100 0 4 10 0.0000 2 150 180 3075 1625 p1\001
    21 4 1 0 100 0 4 10 0.0000 2 120 270 3600 2150 100\001
    22 4 1 0 100 0 4 10 0.0000 2 120 270 3600 1725 104\001
    23 -6
     19         1500 1950 1800 1950 1800 2250 1500 2250 1500 1950
    24202 2 0 1 0 7 100 0 -1 0.000 0 0 -1 0 0 5
    25          1500 1950 2400 1950 2400 2250 1500 2250 1500 1950
     21         2550 1500 2850 1500 2850 1800 2550 1800 2550 1500
    26222 2 0 1 0 7 100 0 -1 0.000 0 0 -1 0 0 5
    27          1500 1500 2400 1500 2400 1800 1500 1800 1500 1500
    28 4 1 0 100 0 4 10 0.0000 2 120 90 1950 1700 3\001
    29 4 1 0 100 0 4 10 0.0000 2 120 90 1950 2150 3\001
     23         2550 1950 2850 1950 2850 2250 2550 2250 2550 1950
     242 1 0 1 4 7 100 -1 -1 0.000 0 0 -1 1 0 2
     25        1 1 1.00 45.00 90.00
     26         3600 1800 2850 1950
     272 2 0 1 0 7 100 0 -1 0.000 0 0 -1 0 0 5
     28         3600 1500 3900 1500 3900 1800 3600 1800 3600 1500
    30294 2 0 100 0 4 10 0.0000 2 120 270 1425 2250 104\001
    31304 2 0 100 0 4 10 0.0000 2 120 270 1425 1800 100\001
    32314 2 0 100 0 4 10 0.0000 2 90 90 1425 1625 x\001
    33324 2 0 100 0 4 10 0.0000 2 120 90 1425 2075 y\001
    34 4 0 0 100 0 4 10 0.0000 2 120 165 2475 2150 int\001
    35 4 0 0 100 0 4 10 0.0000 2 120 165 2475 1700 int\001
     334 1 0 100 0 4 10 0.0000 2 120 90 1650 1700 3\001
     344 1 0 100 0 4 10 0.0000 2 120 90 1650 2150 3\001
     354 0 0 100 0 4 10 0.0000 2 120 165 1875 2150 int\001
     364 0 0 100 0 4 10 0.0000 2 120 165 1875 1700 int\001
     374 2 0 100 0 4 10 0.0000 2 120 270 2475 2250 112\001
     384 2 0 100 0 4 10 0.0000 2 150 180 2475 2075 p2\001
     394 2 0 100 0 4 10 0.0000 2 120 270 2475 1800 108\001
     404 2 0 100 0 4 10 0.0000 2 150 180 2475 1625 p1\001
     414 1 0 100 0 4 10 0.0000 2 120 270 2700 1700 104\001
     424 1 0 100 0 4 10 0.0000 2 120 270 2700 2150 100\001
     434 0 0 100 0 4 10 0.0000 2 120 270 2925 2150 int *\001
     444 0 0 100 0 4 10 0.0000 2 120 270 2925 1700 int *\001
     454 2 0 100 0 4 10 0.0000 2 120 270 3525 1800 116\001
     464 2 0 100 0 4 10 0.0000 2 150 180 3525 1625 p3\001
     474 1 0 100 0 4 10 0.0000 2 120 270 3750 1700 112\001
     484 0 0 100 0 4 10 0.0000 2 120 330 3975 1700 int **\001
  • doc/user/user.tex

    r99f11dd r4096de0  
    1111%% Created On       : Wed Apr  6 14:53:29 2016
    1212%% Last Modified By : Peter A. Buhr
    13 %% Last Modified On : Mon Jun 20 10:47:22 2016
    14 %% Update Count     : 575
     13%% Last Modified On : Wed Jul  6 21:08:24 2016
     14%% Update Count     : 1070
    1515%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
    1616
     
    3636\usepackage{epic,eepic}
    3737\usepackage{upquote}                                                                    % switch curled `'" to straight
     38\usepackage{calc}
    3839\usepackage{xspace}
     40\usepackage{graphicx}
    3941\usepackage{varioref}                                                                   % extended references
    4042\usepackage{listings}                                                                   % format program code
     
    5052\renewcommand{\UrlFont}{\small\sf}
    5153
    52 \makeatletter
    53 \renewcommand{\pagestyle}[1]{
    54   \@ifundefined{ps@#1}%
    55     \undefinedpagestyle
    56     {\def\@tempa{#1}\def\@tempb{headings}\def\@tempc{myheadings}%
    57      \ifx\@tempa\@tempb\setlength{\topmargin}{-0.25in}\setlength{\headsep}{0.25in}%
    58      \else\ifx\@tempa\@tempc\setlength{\topmargin}{-0.25in}\setlength{\headsep}{0.25in}\fi\fi%
    59      \@nameuse{ps@#1}}}% pagestyle
    60 \makeatother
    61 
     54\setlength{\topmargin}{-0.45in}                                                 % move running title into header
     55\setlength{\headsep}{0.25in}
    6256
    6357%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
     
    10599\begin{document}
    106100\pagestyle{headings}
     101% changed after setting pagestyle
     102\renewcommand{\sectionmark}[1]{\markboth{\thesection\quad #1}{\thesection\quad #1}}
     103\renewcommand{\subsectionmark}[1]{\markboth{\thesubsection\quad #1}{\thesubsection\quad #1}}
    107104\pagenumbering{roman}
    108105\linenumbers                                            % comment out to turn off line numbering
    109106
    110107\maketitle
    111 
     108\thispagestyle{empty}
    112109\vspace*{\fill}
    113 \thispagestyle{empty}
    114110\noindent
    115111\copyright\,2016 \CFA Project \\ \\
     
    120116
    121117\clearpage
     118\thispagestyle{plain}
    122119\pdfbookmark[1]{Contents}{section}
    123120\tableofcontents
    124121
    125122\clearpage
    126 \markright{\CFA User Manual}
     123\thispagestyle{plain}
    127124\pagenumbering{arabic}
    128125
     
    306303\begin{lstlisting}
    307304#ifndef __CFORALL__
    308 #include <stdio.h>                              // C header file
     305#include <stdio.h>                              §\C{// C header file}§
    309306#else
    310 #include <fstream>                              // §\CFA{}§ header file
     307#include <fstream>                              §\C{// \CFA header file}§
    311308#endif
    312309\end{lstlisting}
     
    318315Numeric constants are extended to allow \Index{underscore}s within constants\index{constant!underscore}, e.g.:
    319316\begin{lstlisting}
    320 2®_®147®_®483®_®648;                                    // decimal constant
    321 56_ul;                                                  // decimal unsigned long constant
    322 0_377;                                                  // octal constant
    323 0x_ff_ff;                                               // hexadecimal constant
    324 0x_ef3d_aa5c;                                   // hexadecimal constant
    325 3.141_592_654;                                  // floating point constant
    326 10_e_+1_00;                                             // floating point constant
    327 0x_ff_ff_p_3;                                   // hexadecimal floating point
    328 0x_1.ffff_ffff_p_128_l;                 // hexadecimal floating point long constant
    329 L_"\x_ff_ee";                                   // wide character constant
     3172®_®147®_®483®_®648;                    §\C{// decimal constant}§
     31856_ul;                                                  §\C{// decimal unsigned long constant}§
     3190_377;                                                  §\C{// octal constant}§
     3200x_ff_ff;                                               §\C{// hexadecimal constant}§
     3210x_ef3d_aa5c;                                   §\C{// hexadecimal constant}§
     3223.141_592_654;                                  §\C{// floating point constant}§
     32310_e_+1_00;                                             §\C{// floating point constant}§
     3240x_ff_ff_p_3;                                   §\C{// hexadecimal floating point}§
     3250x_1.ffff_ffff_p_128_l;                 §\C{// hexadecimal floating point long constant}§
     326L_"\x_ff_ee";                                   §\C{// wide character constant}§
    330327\end{lstlisting}
    331328The rules for placement of underscores is as follows:
     
    363360\end{quote2}
    364361Is this an array of 5 pointers to integers or a pointer to an array of 5 integers?
     362The fact this declaration is unclear to many C programmers means there are \Index{productivity} and \Index{safety} issues even for basic programs.
    365363Another 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.
    366364For example, a routine returning a pointer to an array of integers is defined and used in the following way:
    367365\begin{lstlisting}
    368 int (*f())[5] {...};                    // definition mimics usage
     366int (*f())[5] {...};                    §\C{}§
    369367... (*f())[3] += 1;
    370368\end{lstlisting}
    371369Essentially, the return type is wrapped around the routine name in successive layers (like an onion).
    372 While attempting to make the two contexts consistent was a laudable goal, it has not worked out in practice.
     370While attempting to make the two contexts consistent is a laudable goal, it has not worked out in practice.
    373371
    374372\CFA provides its own type, variable and routine declarations, using a different syntax.
    375373The new declarations place qualifiers to the left of the base type, while C declarations place qualifiers to the right of the base type.
    376374In the following example, \R{red} is for the base type and \B{blue} is for the qualifiers.
    377 The \CFA declarations move the qualifiers to the left of the base type, i.e., blue to the left of the red, while the qualifiers have the same meaning but are ordered left to left to right to specify the variable's type.
     375The \CFA declarations move the qualifiers to the left of the base type, i.e., 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.
    378376\begin{quote2}
    379377\begin{tabular}{@{}l@{\hspace{3em}}l@{}}
     
    408406\end{tabular}
    409407\end{quote2}
     408The downside of this semantics is the need to separate regular and pointer declarations:
     409\begin{quote2}
     410\begin{tabular}{@{}l@{\hspace{3em}}l@{}}
     411\multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}}        & \multicolumn{1}{c}{\textbf{C}}        \\
     412\begin{lstlisting}
     413®*® int x;
     414int y;
     415\end{lstlisting}
     416&
     417\begin{lstlisting}
     418int ®*®x, y;
     419
     420\end{lstlisting}
     421\end{tabular}
     422\end{quote2}
     423which is \Index{prescribing} a safety benefit.
    410424Other examples are:
    411425\begin{quote2}
     
    493507e.g.:
    494508\begin{lstlisting}
    495 x;                                                              // int x
    496 *y;                                                             // int *y
    497 f( p1, p2 );                                    // int f( int p1, int p2 );
    498 f( p1, p2 ) {}                                  // int f( int p1, int p2 ) {}
     509x;                                                              §\C{// int x}§
     510*y;                                                             §\C{// int *y}§
     511f( p1, p2 );                                    §\C{// int f( int p1, int p2 );}§
     512f( p1, p2 ) {}                                  §\C{// int f( int p1, int p2 ) {}}§
    499513\end{lstlisting}
    500514
     
    504518
    505519
    506 \section{Reference Pointers}
     520\section{Pointer / Reference}
     521
     522C provides a \newterm{pointer type};
     523\CFA adds a \newterm{reference type}.
     524Both types contain an \newterm{address}, which is normally a location in memory.
     525Special addresses are used to denote certain states or access co-processor memory.
     526By convention, no variable is placed at address 0, so addresses like 0, 1, 2, 3 are often used to denote no-value or other special states.
     527Often dereferencing a special state causes a memory fault, so checking is necessary during execution.
     528If the programming language assigns addresses, a program's execution is \Index{sound}, i.e., all addresses are to valid memory locations.
     529C allows programmers to assign addresses, so there is the potential for incorrect addresses, both inside and outside of the computer address-space.
    507530
    508531Program variables are implicit pointers to memory locations generated by the compiler and automatically dereferenced, as in:
    509532\begin{quote2}
    510 \begin{tabular}{@{}l|l@{}}
    511 \multicolumn{1}{c|}{Variables} & \multicolumn{1}{c}{Compiler generated addresses (100, 104) and dereferencing} \\
    512 \hline
    513 \begin{lstlisting}
    514 int x, y;
     533\begin{tabular}{@{}lll@{}}
     534\begin{lstlisting}
     535int x;
    515536x = 3;
     537int y;
    516538y = x;
    517539\end{lstlisting}
    518540&
    519 \begin{lstlisting}
    520 int * const x = (int *)100, * const y = (int *)104;
    521 *x = 3;         // implicit dereference
    522 *y = *x;
     541\raisebox{-0.45\totalheight}{\input{pointer1}}
     542&
     543\begin{lstlisting}
     544int * const x = (int *)100
     545*x = 3;                 // implicit dereference
     546int * const y = (int *)104;
     547*y = *x;                // implicit dereference
    523548\end{lstlisting}
    524549\end{tabular}
    525550\end{quote2}
    526 A variable name only points to one location during its lifetime, i.e., it is a \Index{non-mutable} pointer.
    527 For example, the variables ©x© and ©y© are constant pointers.
    528 Variable addresses are usually not stored in memory and loaded before dereferencing;
    529 instead, variable addresses are stored in instructions, so an instruction fetch implicitly gets the variable's address.
     551where the right example is how the compiler logically interpreters variables.
     552Since a variable name only points to one location during its lifetime, it is a \Index{immutable} pointer;
     553hence, variables ©x© and ©y© are constant pointers in the compiler interpretation.
     554In general, variable addresses are stored in instructions instead of loaded independently, so an instruction fetch implicitly loads a variable's address.
    530555\begin{quote2}
    531556\begin{tabular}{@{}l|l@{}}
    532557\begin{lstlisting}
    533 x = x + 1
    534 &x = *(&x) + 1
    535 (100) = *(100) + 1
     558lda             r1,100                  // load address of x
     559ld              r2,(r1)                   // load value of x
     560lda             r3,104                  // load address of y
     561st              r2,(r3)                   // store x into y
    536562\end{lstlisting}
    537563&
    538564\begin{lstlisting}
    539 ld              r1,(100)                        // address of x
    540 add             r1,1
    541 st              r1,(100)                        // address of x
     565
     566ld              r2,(100)                // load value of x
     567
     568st              r2,(104)                // store x into y
    542569\end{lstlisting}
    543570\end{tabular}
    544571\end{quote2}
    545 Finally, the non-mutable nature of variables and the fact that there is no storage for a variable address means pointer assignment is impossible.
    546 Therefore, the expression ©x = y© only has one meaning, ©*x = *y©, i.e., copy the variable values, so explicitly writing the dereferences is unnecessary even though it occurs implicitly as part of instruction decoding.
    547 
    548 A variable name is generalized by a \newterm{pointer}, which is a mutable pointer variable that can point to more than one memory location during its life-time (like an integer variable versus a literal).
     572Finally, the immutable nature of a variable's address and the fact that there is no storage for a variable address means pointer assignment is impossible.
     573Therefore, the expression ©x = y© only has one meaning, ©*x = *y©, i.e., manipulate values, which is why explicitly writing the dereferences is unnecessary even though it occurs implicitly as part of instruction decoding.
     574
     575A pointer/reference is a generalization of a variable name, i.e., a mutable address that can point to more than one memory location during its lifetime.
     576(Similarly, an integer variable can contain multiple integer literals during its lifetime versus an integer constant representing a single literal during its lifetime and may not occupy storage as the literal is embedded directly into instructions.)
    549577Hence, a pointer occupies memory to store its current address, and the pointer's value is loaded by dereferencing, e.g.:
    550 \begin{lstlisting}
    551 int x, y, z, ®*® p1, ®*® p2;
    552 p1 = ®&®x;                                      // p1 points to x
    553 p2 = p1;                                        // p2 also points to x
    554 p1 = ®&®y;                                      // p1 points to y
    555 p2 = p1 + 1;                            // p2 points to z, pointer arithmetic
    556 \end{lstlisting}
    557 In many cases, a pointer name is anonymous (dynamically computed), so it cannot be stored directly in an instruction like a variable name.
    558 
    559 Pointers have a duality: an address in memory or the value at that address.
    560 In many cases, the compiler can infer which of these operations are needed:
    561 \begin{lstlisting}
    562 p2 = p1 + x;                            // compiler infers *p2 = *p1 + x;
    563 \end{lstlisting}
    564 because adding the integer value of ©x© to the address of ©p1© and storing the resulting address into ©p2© is an unlikely operation.
     578\begin{quote2}
     579\begin{tabular}{@{}ll@{}}
     580\begin{lstlisting}
     581int x, y, ®*® p1, ®*® p2, ®**® p3;
     582p1 = ®&®x;               // p1 points to x
     583p2 = p1;                 // p2 also points to x
     584p1 = ®&®y;               // p1 points to y
     585p1 = p2 + 1;    // p1 points to y, pointer arithmetic
     586p3 = &p2;               // p3 points to p2
     587\end{lstlisting}
     588&
     589\raisebox{-0.45\totalheight}{\input{pointer2.pstex_t}}
     590\end{tabular}
     591\end{quote2}
     592
     593Notice, an address has a duality\index{address!duality}: a location in memory or the value at that location.
     594In many cases, the compiler can infer the meaning:
     595\begin{lstlisting}
     596p2 = p1 + x;                            §\C{// compiler infers *p2 = *p1 + x;}§
     597\end{lstlisting}
     598because adding the arbitrary integer value in ©x© to the address of ©p1© and storing the resulting address into ©p2© is an unlikely operation.
    565599Algol68~\cite{Algol68} inferences pointer dereferencing to select the best meaning for each pointer usage.
    566 However, there are ambiguous cases, especially when pointer arithmetic is possible, as in C:
    567 \begin{lstlisting}
    568 p1 = p2;                                        // p1 = p2 or *p1 = *p2
    569 p1 = p1 + 1;                            // p1 = p1 + 1 or *p1 = *p1 + 1
    570 \end{lstlisting}
    571 
    572 Most programming languages pick a default operation and supply an explicit operation to resolve the pointer-duality ambiguity.
    573 In C, the default operation for pointers is manipulate the pointer value and the pointed-to value is explicitly accessed by dereferencing ©*©.
    574 \begin{lstlisting}
    575 p1 = p2;                                        // pointer value assignment
    576 *p1 = *p1 + 1;                          // pointed-to value assignment/operation
    577 \end{lstlisting}
    578 which works well for low-level memory management, such as ©malloc©/©free©, where manipulation of addresses in the primary operation, and data is only occasionally accessed.
    579 
    580 However, in the majority of pointer usages, the pointed-to value is required rather than the pointer address.
    581 \begin{lstlisting}
    582 *p2 = ((*p1 + *p2) * (*p2 - *p1)) / (*p1 - *p2);
    583 \end{lstlisting}
    584 And, it is tedious and error prone to explicitly write the dereferencing, especially when pointer arithmetic with integer values is allowed.
    585 It is better to have the compiler generate the dereferencing:
    586 \begin{lstlisting}
    587 p2 = ((p1 + p2) * (p2 - p1)) / (p1 - p2);
    588 \end{lstlisting}
    589 
    590 To provide this capability, it is necessary to switch the default operation to resolve the pointer-duality ambiguity, which requires a new kind of pointer called a \newterm{reference} pointer.
    591 \begin{lstlisting}
    592 int x, y, z, ®&® r1, ®&® r2;    // & denotes reference pointer
    593 r1 ®:=® &x;                                     // r1 points to x
    594 r2 ®:=® &r1;                                    // r2 also points to x
    595 r1 ®:=® &y;                                     // r1 points to y
    596 r2 ®:=® &r1 + 1;                                // r2 points to z
    597 r2 = ((r1 + r2) * (r2 - r1)) / (r1 - r2); // implicit dereferencing
    598 \end{lstlisting}
    599 Hence, a reference pointer behaves like a variable name for the current variable it is pointing-to, so dereferencing a reference pointer returns the address of its pointed-to value, i.e., the address in the reference pointer.
    600 Notice, the explicit operator ©:=© to denote pointer assignment to a reference pointer to support both aspects of pointer duality.
    601 Note, \CC deals with the pointer duality by making a reference pointer a constant (©const©), like a plain variable, so there is no reference assignment.
    602 
    603 Like pointers, it is possible to use ©const© qualifiers with a reference:
    604 \begin{lstlisting}
    605 const int cx = 5;                       // cannot change cx;
    606 const int & r3 = &cx;           // cannot change what r3 is pointing to
    607 r3 ®:=® &cx;                                    // can change r3
    608 r3 = 7;                                         // error, cannot change cx
    609 int & const r4 = &x;            // must be initialized, §\CC§ reference
    610 r4 ®:=® &x;                                     // error, cannot change r4
    611 const int & const r5 = &cx;     // must be initialized, §\CC§ reference
    612 r5 = 7;                                         // error, cannot change cx
    613 r5 ®:=® &cx;                                    // error, cannot change r5
    614 \end{lstlisting}
    615 Note, for type ©& const©, there is no pointer assignment, so ©r4 := &x© is disallowed, and the pointer value cannot be ©0©.
    616 Since there is only one meaning for ©r4 = x©, which is to change the value of the variable pointed to by ©r4©, therefore:
    617 \begin{itemize}
    618 \item
    619 it in impossible to take the address of ©r4© as it always means the address of what ©r4© is pointing to.
    620 \item
    621 the dereference at initialization is optional because there can only be one
    622 \begin{lrbox}{\LstBox}%
    623 \footnotesize%
    624 \begin{lstlisting}%
     600However, there are ambiguous cases, especially when \Index{pointer arithmetic} is possible, as in C:
     601\begin{lstlisting}
     602p1 = p2;                                        §\C{// p1 = p2 or *p1 = *p2}§
     603p1 = p1 + 1;                            §\C{// p1 = p1 + 1 or *p1 = *p1 + 1}§
     604\end{lstlisting}
     605
     606Most languages pick one meaning as the default and the programmer explicitly indicates the other meaning to resolve the address-duality ambiguity\index{address!duality ambiguity}.
     607In C, the default meaning for pointers is to manipulate the pointer's address and the pointed-to value is explicitly accessed by the dereference operator ©*©.
     608\begin{lstlisting}
     609p1 = p2;                                        §\C{// pointer address assignment}§
     610*p1 = *p1 + 1;                          §\C{// pointed-to value assignment / operation}§
     611\end{lstlisting}
     612which works well for situations where manipulation of addresses in the primary meaning and data is rarely accessed, such as storage management (©malloc©/©free©).
     613
     614However, in most other situations, the pointed-to value is requested more often than the pointer address.
     615\begin{lstlisting}
     616*p2 = ((*p1 + *p2) * (**p3 - *p1)) / (**p3 - 15);
     617\end{lstlisting}
     618In this case, it is tedious to explicitly write the dereferencing, and error prone when pointer arithmetic is allowed.
     619It is better to have the compiler generate the dereferencing and have no implicit pointer arithmetic:
     620\begin{lstlisting}
     621p2 = ((p1 + p2) * (p3 - p1)) / (p3 - 15);
     622\end{lstlisting}
     623
     624To switch the default meaning for an address requires a new kind of pointer, called a \newterm{reference} and denoted by ©&©.
     625\begin{lstlisting}
     626int x, y, ®&® r1, ®&® r2, ®&&® r3;
     627®&®r1 = &x;                                     §\C{// r1 points to x}§
     628®&®r2 = &r1;                            §\C{// r2 also points to x}§
     629®&®r1 = &y;                                     §\C{// r2 also points to x}§
     630®&®r1 = &r2 + 1;                        §\C{// r1 points to y, pointer arithmetic}§
     631®&®r3 = ®&®&r2;                         §\C{// r3 points to r2}§
     632r2 = ((r1 + r2) * (r3 - r1)) / (r3 - 15); §\C{// implicit dereferencing}§
     633\end{lstlisting}
     634Except for auto-dereferencing by the compiler, this reference example is the same as the pointer example.
     635Hence, a reference behaves like the variable name for the current variable it is pointing-to.
     636The simplest way to understand a reference is to imagine the compiler inserting a dereference operator before the reference variable for each reference qualifier in a declaration, e.g.:
     637\begin{lstlisting}
     638r2 = ((r1 + r2) * (r3 - r1)) / (r3 - 15);
     639\end{lstlisting}
     640is rewritten as:
     641\begin{lstlisting}
     642®*®r2 = ((®*®r1 + ®*®r2) ®*® (®**®r3 - ®*®r1)) / (®**®r3 - 15);
     643\end{lstlisting}
     644When a reference appears beside a dereference, e.g., ©&*©, they cancel out.\footnote{
     645The unary ©&© operator yields the address of its operand.
     646If the operand has type ``type'', the result has type ``pointer to type''.
     647If the operand is the result of a unary ©*© operator, neither that operator nor the ©&© operator is evaluated and the result is as if both were omitted, except that the constraints on the operators still apply and the result is not an lvalue.~\cite[\S~6.5.3.2--3]{C11}}
     648Hence, assigning to a reference requires the address of the reference variable (\Index{lvalue}):
     649\begin{lstlisting}
     650(&®*®)r1 = &x;                          §\C{// (\&*) cancel out giving variable r1 not the variable pointed-to by r1}§
     651\end{lstlisting}
     652Similarly, the address of a reference can be obtained for assignment or computation (\Index{rvalue}):
     653\begin{lstlisting}
     654(&®*®)r3 = &(&®*®)r2;           §\C{// (\&*) cancel out giving the address of variable r2}§
     655\end{lstlisting}
     656\Index{Cancellation}\index{pointer!cancellation rule} works to arbitrary depth, and pointer and reference values are interchangeable because both contain addresses.
     657\begin{lstlisting}
     658int x, *p1 = &x, **p2 = &p1, ***p3 = &p2,
     659                 &r1 = &x, &&r2 = &&r1, &&&r3 = &&r2;
     660***p3 = 3;                                      §\C{// change x}§
     661r3 = 3;                                         §\C{// change x, ***r3}§
     662**p3 = ...;                                     §\C{// change p1}§
     663&r3 = ...;                                      §\C{// change r1, (\&*)**r3, 1 cancellation}§
     664*p3 = ...;                                      §\C{// change p2}§
     665&&r3 = ...;                                     §\C{// change r2, (\&(\&*)*)*r3, 2 cancellations}§
     666&&&r3 = p3;                                     §\C{// change r3 to p3, (\&(\&(\&*)*)*)r3, 3 cancellations}§
     667\end{lstlisting}
     668Finally, implicit dereferencing and cancellation are a static (compilation) phenomenon not a dynamic one.
     669That is, all implicit dereferencing and any cancellation is carried out prior to the start of the program, so reference performance is equivalent to pointer performance.
     670A programmer selects a pointer or reference type solely on whether the address is dereferences frequently or infrequently, which dictates the amount of direct aid from the compiler;
     671otherwise, everything else is equal.
     672
     673Interestingly, \CC deals with the address duality by making the pointed-to value the default, and prevent\-ing changes to the reference address, which eliminates half of the duality.
     674Java deals with the address duality by making address assignment the default and providing a \Index{clone} mechanism to change the pointed-to value.
     675
     676As for pointers, references may have qualifiers:
     677\begin{lstlisting}
     678const int cx = 5;                       §\C{// cannot change cx;}§
     679const int & r3 = &cx;           §\C{// cannot change what r3 is pointing to}§
     680®&®r3 = &cx;                            §\C{// can change r3}§
     681r3 = 7;                                         §\C{// error, cannot change cx}§
     682int & const r4 = &x;            §\C{// must be initialized, \CC reference}§
     683®&®r4 = &x;                                     §\C{// error, cannot change r4}§
     684const int & const r5 = &cx;     §\C{// must be initialized, \CC reference}§
     685r5 = 7;                                         §\C{// error, cannot change cx}§
     686®&®r5 = &cx;                            §\C{// error, cannot change r5}§
     687\end{lstlisting}
     688Hence, for type ©& const©, there is no pointer assignment, so ©&r4 = &x© is disallowed, and \emph{the address value cannot be ©0©}.
     689in effect, the compiler is managing the addresses not the programmer.
     690
     691\Index{Initialization} is different than \Index{assignment} because initialization occurs on an empty (uninitialized) storage on an object, while assignment occurs on possible initialized storage for an object.
     692There are three initialization contexts in \CFA: declaration initialization, argument/parameter binding, return/temporary binding.
     693For reference (like pointer) initialization, the initializing value must be an address (lvalue) not a value (rvalue).
     694\begin{lstlisting}
     695int * p = &x;                           §\C{// both \&x and x are possible interpretations}§
     696int & r = x;                            §\C{// x unlikely interpretation, because of auto-dereferencing}§
     697\end{lstlisting}
     698Hence, the compiler implicitly inserts a reference, ©&©, before the initialization expression:
     699Similarly, when a reference is used for a parameter/return type, the call-site argument does not require a reference.
     700\begin{lstlisting}
     701int & f( int & ri );            §\C{// reference parameter and return}§
     702z = f( x ) + f( y );            §\C{// reference not required}§
     703\end{lstlisting}
     704Within routine ©f©, it is possible to change the argument by changing the corresponding parameter, and parameter ©ri© can be locally reassigned within ©f©.
     705The return reference from ©f© is copied into a compiler generated temporary, which is logically treated as an initialization.
     706
     707When a pointer/reference parameter has a ©const© value (immutable), it is possible to pass literals and expressions.
     708\begin{lstlisting}
     709void f( const int & cri );
     710void g( const int * cri );
     711f( 3 );                  g( &3 );
     712f( x + y );             g( &(x + y) );
     713\end{lstlisting}
     714Here, the compiler passes the address to the literal 3 or the temporary for the expression ©x + y©, knowing the argument cannot be changed through the parameter.
     715(The ©&© is necessary for the pointer parameter to make the types match, and is common for a C programmer.)
     716\CFA extends this semantics to a mutable pointer/reference parameter, and the compiler implicitly creates the necessary temporary (copying the argument), which is subsequently pointed to by the reference parameter, which can be changed.
     717Essentially, there is an implicit rvalue to lvalue conversion in this case.\footnote{
     718This conversion attempts to address the \newterm{const Hell} problem, when the innocent addition of a ©const© qualifier causes a cascade of type failures, requiring an unknown number of additional ©const© qualifiers, until it is discovered a ©const© qualifier cannot be added and all the ©const© qualifiers must be removed.}
     719The implicit conversion allows seamless calls to any routine without having to explicit name/copy the literal/expression to allow the call.
     720
     721While \CFA attempts to handle pointers and references in a uniform, symmetric manner, C handles routine pointers in an inconsistent way: a routine pointer is both a reference and a pointer (particle and wave).
     722\begin{lstlisting}
    625723void f( int p ) {...}
    626 void (*fp)( int ) = &f;         // equivalent initialization
    627 void (*fp)( int ) = f;          // missing dereference allowed
    628 \end{lstlisting}%
    629 \end{lrbox}%
    630 meaning.\footnote{
    631 This case is similar to initializing a routine pointer, where the routine constant should be dereferenced.
    632 \newline
    633 \usebox{\LstBox}
    634 }% footnote
    635 \begin{lstlisting}
    636 int & const r4 = &x;            // equivalent initialization
    637 int & const r4 = x;                     // missing dereference allowed
    638 \end{lstlisting}
    639 \end{itemize}
    640 Similarly, when a ©const© reference is used for a parameters type, the call-site argument does not require a reference.
    641 \begin{lstlisting}
    642 void f( int & ri, int & const cri );
    643 f( &x, x );                                     // reference not required for second argument
    644 \end{lstlisting}
    645 Within routine ©f©, it is possible to change an argument by changing the corresponding parameter, and parameter ©ri© can be locally reassigned within ©f©.
    646 
    647 Finally, when a reference parameter has a ©const© value, it is possible to pass literals and expressions.
    648 \begin{lstlisting}
    649 void g( const int & ri, const int & const cri );
    650 f( &3, 3 );
    651 f( &(x + y), x + y );
    652 \end{lstlisting}
    653 At the call site, the compiler implicitly creates the necessary temporary that is subsequently pointed to by the reference parameter.
    654 Hence, changing the parameter only changes the temporary at the call site.
    655 For the non-©const© parameter, requiring the reference on the literal or expression makes it clear that nothing is changing at the call site and allows the call to proceed, where other languages require the programmer to explicitly create the temporary for the argument.
     724void (*fp)( int ) = &f;         §\C{// pointer initialization}§
     725void (*fp)( int ) = f;          §\C{// reference initialization}§
     726(*fp)(3);                                       §\C{// pointer invocation}§
     727fp(3);                                          §\C{// reference invocation}§
     728\end{lstlisting}
     729A routine variable is best described by a ©const© reference:
     730\begin{lstlisting}
     731const void (&fp)( int ) = f;
     732fp( 3 );
     733fp = ...                                        §\C{// change code not allowed}§
     734&fp = ...;                                      §\C{// change routine refernce allowed}§
     735\end{lstlisting}
     736because the value of the routine variable is a routine literal, i.e., the routine code is normally immutable during execution.\footnote{
     737Dynamic code rewriting is possible but only in special circumstances.}
     738\CFA allows this additional use of references for routine variables in an attempt to give a more consistent meaning for routine variables.
     739
    656740
    657741\section{Type Operators}
     
    696780in both cases the type is assumed to be void as opposed to old style C defaults of int return type and unknown parameter types, respectively, as in:
    697781\begin{lstlisting}
    698 [§\,§] g();                                                     // no input or output parameters
    699 [ void ] g( void );                             // no input or output parameters
     782[§\,§] g();                                             §\C{// no input or output parameters}§
     783[ void ] g( void );                             §\C{// no input or output parameters}§
    700784\end{lstlisting}
    701785
     
    715799\begin{lstlisting}
    716800typedef int foo;
    717 int f( int (* foo) );                   // foo is redefined as a parameter name
     801int f( int (* foo) );                   §\C{// foo is redefined as a parameter name}§
    718802\end{lstlisting}
    719803The string ``©int (* foo)©'' declares a C-style named-parameter of type pointer to an integer (the parenthesis are superfluous), while the same string declares a \CFA style unnamed parameter of type routine returning integer with unnamed parameter of type pointer to foo.
     
    723807C-style declarations can be used to declare parameters for \CFA style routine definitions, e.g.:
    724808\begin{lstlisting}
    725 [ int ] f( * int, int * );              // returns an integer, accepts 2 pointers to integers
    726 [ * int, int * ] f( int );              // returns 2 pointers to integers, accepts an integer
     809[ int ] f( * int, int * );              §\C{// returns an integer, accepts 2 pointers to integers}§
     810[ * int, int * ] f( int );              §\C{// returns 2 pointers to integers, accepts an integer}§
    727811\end{lstlisting}
    728812The reason for allowing both declaration styles in the new context is for backwards compatibility with existing preprocessor macros that generate C-style declaration-syntax, as in:
    729813\begin{lstlisting}
    730814#define ptoa( n, d ) int (*n)[ d ]
    731 int f( ptoa( p, 5 ) ) ...               // expands to int f( int (*p)[ 5 ] )
    732 [ int ] f( ptoa( p, 5 ) ) ...   // expands to [ int ] f( int (*p)[ 5 ] )
     815int f( ptoa( p, 5 ) ) ...               §\C{// expands to int f( int (*p)[ 5 ] )}§
     816[ int ] f( ptoa( p, 5 ) ) ...   §\C{// expands to [ int ] f( int (*p)[ 5 ] )}§
    733817\end{lstlisting}
    734818Again, programmers are highly encouraged to use one declaration form or the other, rather than mixing the forms.
     
    752836        int z;
    753837        ... x = 0; ... y = z; ...
    754         ®return;® // implicitly return x, y
     838        ®return;® §\C{// implicitly return x, y}§
    755839}
    756840\end{lstlisting}
     
    762846[ int x, int y ] f() {
    763847        ...
    764 } // implicitly return x, y
     848} §\C{// implicitly return x, y}§
    765849\end{lstlisting}
    766850In this case, the current values of ©x© and ©y© are returned to the calling routine just as if a ©return© had been encountered.
     
    772856as well, parameter names are optional, e.g.:
    773857\begin{lstlisting}
    774 [ int x ] f ();                                 // returning int with no parameters
    775 [ * int ] g (int y);                    // returning pointer to int with int parameter
    776 [ ] h (int,char);                               // returning no result with int and char parameters
    777 [ * int,int ] j (int);                  // returning pointer to int and int, with int parameter
     858[ int x ] f ();                                 §\C{// returning int with no parameters}§
     859[ * int ] g (int y);                    §\C{// returning pointer to int with int parameter}§
     860[ ] h (int,char);                               §\C{// returning no result with int and char parameters}§
     861[ * int,int ] j (int);                  §\C{// returning pointer to int and int, with int parameter}§
    778862\end{lstlisting}
    779863This syntax allows a prototype declaration to be created by cutting and pasting source text from the routine definition header (or vice versa).
     
    802886The syntax for pointers to \CFA routines specifies the pointer name on the right, e.g.:
    803887\begin{lstlisting}
    804 * [ int x ] () fp;                      // pointer to routine returning int with no parameters
    805 * [ * int ] (int y) gp;         // pointer to routine returning pointer to int with int parameter
    806 * [ ] (int,char) hp;            // pointer to routine returning no result with int and char parameters
    807 * [ * int,int ] (int) jp;       // pointer to routine returning pointer to int and int, with int parameter
     888* [ int x ] () fp;                      §\C{// pointer to routine returning int with no parameters}§
     889* [ * int ] (int y) gp;         §\C{// pointer to routine returning pointer to int with int parameter}§
     890* [ ] (int,char) hp;            §\C{// pointer to routine returning no result with int and char parameters}§
     891* [ * int,int ] (int) jp;       §\C{// pointer to routine returning pointer to int and int, with int parameter}§
    808892\end{lstlisting}
    809893While parameter names are optional, \emph{a routine name cannot be specified};
    810894for example, the following is incorrect:
    811895\begin{lstlisting}
    812 * [ int x ] f () fp;                    // routine name "f" is not allowed
     896* [ int x ] f () fp;            §\C{// routine name "f" is not allowed}§
    813897\end{lstlisting}
    814898
     
    833917whereas a named (keyword) call may be:
    834918\begin{lstlisting}
    835 p( z : 3, x : 4, y : 7 ); // rewrite $\Rightarrow$ p( 4, 7, 3 )
     919p( z : 3, x : 4, y : 7 );       §\C{// rewrite $\Rightarrow$ p( 4, 7, 3 )}§
    836920\end{lstlisting}
    837921Here the order of the arguments is unimportant, and the names of the parameters are used to associate argument values with the corresponding parameters.
     
    850934For example, the following routine prototypes and definition are all valid.
    851935\begin{lstlisting}
    852 void p( int, int, int );                        // equivalent prototypes
     936void p( int, int, int );                        §\C{// equivalent prototypes}§
    853937void p( int x, int y, int z );
    854938void p( int y, int x, int z );
    855939void p( int z, int y, int x );
    856 void p( int q, int r, int s ) {}        // match with this definition
     940void p( int q, int r, int s ) {}        §\C{// match with this definition}§
    857941\end{lstlisting}
    858942Forcing matching parameter names in routine prototypes with corresponding routine definitions is possible, but goes against a strong tradition in C programming.
     
    869953the allowable positional calls are:
    870954\begin{lstlisting}
    871 p();                            // rewrite $\Rightarrow$ p( 1, 2, 3 )
    872 p( 4 );                         // rewrite $\Rightarrow$ p( 4, 2, 3 )
    873 p( 4, 4 );                      // rewrite $\Rightarrow$ p( 4, 4, 3 )
    874 p( 4, 4, 4 );           // rewrite $\Rightarrow$ p( 4, 4, 4 )
     955p();                            §\C{// rewrite $\Rightarrow$ p( 1, 2, 3 )}§
     956p( 4 );                         §\C{// rewrite $\Rightarrow$ p( 4, 2, 3 )}§
     957p( 4, 4 );                      §\C{// rewrite $\Rightarrow$ p( 4, 4, 3 )}§
     958p( 4, 4, 4 );           §\C{// rewrite $\Rightarrow$ p( 4, 4, 4 )}§
    875959// empty arguments
    876 p(  , 4, 4 );           // rewrite $\Rightarrow$ p( 1, 4, 4 )
    877 p( 4,  , 4 );           // rewrite $\Rightarrow$ p( 4, 2, 4 )
    878 p( 4, 4,   );           // rewrite $\Rightarrow$ p( 4, 4, 3 )
    879 p( 4,  ,   );           // rewrite $\Rightarrow$ p( 4, 2, 3 )
    880 p(  , 4,   );           // rewrite $\Rightarrow$ p( 1, 4, 3 )
    881 p(  ,  , 4 );           // rewrite $\Rightarrow$ p( 1, 2, 4 )
    882 p(  ,  ,   );           // rewrite $\Rightarrow$ p( 1, 2, 3 )
     960p(  , 4, 4 );           §\C{// rewrite $\Rightarrow$ p( 1, 4, 4 )}§
     961p( 4,  , 4 );           §\C{// rewrite $\Rightarrow$ p( 4, 2, 4 )}§
     962p( 4, 4,   );           §\C{// rewrite $\Rightarrow$ p( 4, 4, 3 )}§
     963p( 4,  ,   );           §\C{// rewrite $\Rightarrow$ p( 4, 2, 3 )}§
     964p(  , 4,   );           §\C{// rewrite $\Rightarrow$ p( 1, 4, 3 )}§
     965p(  ,  , 4 );           §\C{// rewrite $\Rightarrow$ p( 1, 2, 4 )}§
     966p(  ,  ,   );           §\C{// rewrite $\Rightarrow$ p( 1, 2, 3 )}§
    883967\end{lstlisting}
    884968Here the missing arguments are inserted from the default values in the parameter list.
     
    904988Default values may only appear in a prototype versus definition context:
    905989\begin{lstlisting}
    906 void p( int x, int y = 2, int z = 3 );          // prototype: allowed
    907 void p( int, int = 2, int = 3 );                        // prototype: allowed
    908 void p( int x, int y = 2, int z = 3 ) {}        // definition: not allowed
     990void p( int x, int y = 2, int z = 3 );          §\C{// prototype: allowed}§
     991void p( int, int = 2, int = 3 );                        §\C{// prototype: allowed}§
     992void p( int x, int y = 2, int z = 3 ) {}        §\C{// definition: not allowed}§
    909993\end{lstlisting}
    910994The reason for this restriction is to allow separate compilation.
     
    9211005\begin{lstlisting}
    9221006p( int x, int y, int z, . . . );
    923 p( 1, 4, 5, 6, z : 3, y : 2 ); // assume p( /* positional */, . . ., /* named */ );
    924 p( 1, z : 3, y : 2, 4, 5, 6 ); // assume p( /* positional */, /* named */, . . . );
     1007p( 1, 4, 5, 6, z : 3, y : 2 ); §\C{// assume p( /* positional */, . . ., /* named */ );}§
     1008p( 1, z : 3, y : 2, 4, 5, 6 ); §\C{// assume p( /* positional */, /* named */, . . . );}§
    9251009\end{lstlisting}
    9261010In the first call, it is necessary for the programmer to conceptually rewrite the call, changing named arguments into positional, before knowing where the ellipse arguments begin.
     
    9311015\begin{lstlisting}
    9321016void p( int x, int y = 2, int z = 3. . . );
    933 p( 1, 4, 5, 6, z : 3 );         // assume p( /* positional */, . . ., /* named */ );
    934 p( 1, z : 3, 4, 5, 6 );         // assume p( /* positional */, /* named */, . . . );
     1017p( 1, 4, 5, 6, z : 3 );         §\C{// assume p( /* positional */, . . ., /* named */ );}§
     1018p( 1, z : 3, 4, 5, 6 );         §\C{// assume p( /* positional */, /* named */, . . . );}§
    9351019\end{lstlisting}
    9361020The first call is an error because arguments 4 and 5 are actually positional not ellipse arguments;
     
    9621046Furthermore, overloading cannot handle accessing default arguments in the middle of a positional list, via a missing argument, such as:
    9631047\begin{lstlisting}
    964 p( 1, /* default */, 5 );               // rewrite $\Rightarrow$ p( 1, 2, 5 )
     1048p( 1, /* default */, 5 );               §\C{// rewrite $\Rightarrow$ p( 1, 2, 5 )}§
    9651049\end{lstlisting}
    9661050
     
    10581142const unsigned int size = 5;
    10591143int ia[size];
    1060 ...                                             // assign values to array ia
    1061 qsort( ia, size );              // sort ascending order using builtin ?<?
     1144...                                             §\C{// assign values to array ia}§
     1145qsort( ia, size );              §\C{// sort ascending order using builtin ?<?}§
    10621146{
    1063         ®int ?<?( int x, int y ) { return x > y; }® // nested routine
    1064         qsort( ia, size );      // sort descending order by local redefinition
     1147        ®int ?<?( int x, int y ) { return x > y; }® §\C{// nested routine}§
     1148        qsort( ia, size );      §\C{// sort descending order by local redefinition}§
    10651149}
    10661150\end{lstlisting}
     
    10701154The following program in undefined in \CFA (and ©gcc©\index{gcc})
    10711155\begin{lstlisting}
    1072 [* [int]( int )] foo() {                // int (*foo())( int )
     1156[* [int]( int )] foo() {                §\C{// int (*foo())( int )}§
    10731157        int ®i® = 7;
    10741158        int bar( int p ) {
    1075                 ®i® += 1;                                       // dependent on local variable
     1159                ®i® += 1;                               §\C{// dependent on local variable}§
    10761160                sout | ®i® | endl;
    10771161        }
    1078         return bar;                                     // undefined because of local dependence
     1162        return bar;                                     §\C{// undefined because of local dependence}§
    10791163}
    10801164int main() {
    1081         * [int](int) fp = foo();        // int (*fp)(int)
     1165        * [int](int) fp = foo();        §\C{// int (*fp)(int)}§
    10821166    sout | fp( 3 ) | endl;
    10831167}
     
    11221206[ unsigned int, char ]
    11231207[ double, double, double ]
    1124 [ * int, int * ]                // mix of CFA and ANSI
     1208[ * int, int * ]                §\C{// mix of CFA and ANSI}§
    11251209[ * [ 5 ] int, * * char, * [ [ int, int ] ] (int, int) ]
    11261210\end{lstlisting}
     
    11291213Examples of declarations using tuple types are:
    11301214\begin{lstlisting}
    1131 [ int, int ] x;                 // 2 element tuple, each element of type int
    1132 * [ char, char ] y;             // pointer to a 2 element tuple
     1215[ int, int ] x;                 §\C{// 2 element tuple, each element of type int}§
     1216* [ char, char ] y;             §\C{// pointer to a 2 element tuple}§
    11331217[ [ int, int ] ] z ([ int, int ]);
    11341218\end{lstlisting}
     
    12281312[ int, int, int, int ] w = [ 1, 2, 3, 4 ];
    12291313int x = 5;
    1230 [ x, w ] = [ w, x ];            // all four tuple coercions
     1314[ x, w ] = [ w, x ];            §\C{// all four tuple coercions}§
    12311315\end{lstlisting}
    12321316Starting on the right-hand tuple in the last assignment statement, w is opened, producing a tuple of four values;
     
    13141398both these examples produce indeterminate results:
    13151399\begin{lstlisting}
    1316 f( x++, x++ );                          // C routine call with side effects in arguments
    1317 [ v1, v2 ] = [ x++, x++ ];      // side effects in righthand side of multiple assignment
     1400f( x++, x++ );                          §\C{// C routine call with side effects in arguments}§
     1401[ v1, v2 ] = [ x++, x++ ];      §\C{// side effects in righthand side of multiple assignment}§
    13181402\end{lstlisting}
    13191403
     
    13351419\end{lstlisting}
    13361420As in C, the rightmost assignment is performed first, i.e., assignment parses right to left.
     1421
     1422
     1423\section{Unnamed Structure Fields}
     1424
     1425C requires each field of a structure to have a name, except for a bit field associated with a basic type, e.g.:
     1426\begin{lstlisting}
     1427struct {
     1428        int f1;                 // named field
     1429        int f2 : 4;             // named field with bit field size
     1430        int : 3;                // unnamed field for basic type with bit field size
     1431        int ;                   // disallowed, unnamed field
     1432        int *;                  // disallowed, unnamed field
     1433        int (*)(int);   // disallowed, unnamed field
     1434};
     1435\end{lstlisting}
     1436This requirement is relaxed by making the field name optional for all field declarations; therefore, all the field declarations in the example are allowed.
     1437As for unnamed bit fields, an unnamed field is used for padding a structure to a particular size.
     1438A list of unnamed fields is also supported, e.g.:
     1439\begin{lstlisting}
     1440struct {
     1441        int , , ;               // 3 unnamed fields
     1442}
     1443\end{lstlisting}
    13371444
    13381445
     
    13551462        double f4;
    13561463} v;
    1357 v.[ f3, f1, f2 ] = ['x', 11, 17 ];      // equivalent to v.f3 = 'x', v.f1 = 11, v.f2 = 17
    1358 f( v.[ f3, f1, f2 ] );                          // equivalent to f( v.f3, v.f1, v.f2 )
     1464v.[ f3, f1, f2 ] = ['x', 11, 17 ];      §\C{// equivalent to v.f3 = 'x', v.f1 = 11, v.f2 = 17}§
     1465f( v.[ f3, f1, f2 ] );                          §\C{// equivalent to f( v.f3, v.f1, v.f2 )}§
    13591466\end{lstlisting}
    13601467Note, the fields appearing in a record-field tuple may be specified in any order;
     
    13761483
    13771484
    1378 \section{Labelled Break/Continue}
    1379 
    1380 While C provides ©break© and ©continue© statements for altering control flow, both are restricted to one level of nesting for a particular control structure.
    1381 Unfortunately, this restriction forces programmers to use ©goto© to achieve the equivalent for more than one level of nesting.
    1382 To prevent having to make this switch, the ©break© and ©continue© are extended with a target label to support static multi-level exit~\cite{Buhr85,Java}.
    1383 \VRef[Figure]{f:LabelledBreak} shows the labelled ©break©, and the target control structure of the exit.
    1384 The inner most loop has three exit points, which cause termination of one or more of the three nested loops, respectively.
    1385 \VRef[Figure]{f:LabelledContinue} shows the labelled ©continue©, and which control structure is the target of the next loop iteration.
    1386 The inner most loop has three restart points, which cause the next loop iteration to begin, respectively.
    1387 
    1388 \begin{figure}
    1389 \centering
     1485\section{Labelled Continue / Break}
     1486
     1487While C provides ©continue© and ©break© statements for altering control flow, both are restricted to one level of nesting for a particular control structure.
     1488Unfortunately, this restriction forces programmers to use ©goto© to achieve the equivalent control-flow for more than one level of nesting.
     1489To prevent having to switch to the ©goto©, \CFA extends the ©continue©\index{continue@©continue©}\index{continue@©continue©!labelled}\index{labelled!continue@©continue©} and ©break©\index{break@©break©}\index{break@©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,Java}.
     1490For both ©continue© and ©break©, the target label must be directly associated with a ©for©, ©while© or ©do© statement;
     1491for ©break©, the target label can also be associated with a ©switch©, ©if© or compound (©{}©) statement.
     1492
     1493The following example shows the labelled ©continue© specifying which control structure is the target for the next loop iteration:
     1494\begin{quote2}
    13901495\begin{tabular}{@{}l@{\hspace{3em}}l@{}}
    13911496\multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}}        & \multicolumn{1}{c}{\textbf{C}}        \\
    13921497\begin{lstlisting}
    1393 ®L1:® for ( ... ) {
    1394         ®L2:® for ( ... ) {
     1498®L1:® do {
     1499        ®L2:® while ( ... ) {
    13951500                ®L3:® for ( ... ) {
    1396                         ... break ®L1®; ...
    1397                         ... break ®L2®; ...
    1398                         ... break ®L3®; // or break
    1399                 }
    1400         }
    1401 }
     1501                        ... continue ®L1®; ...  // continue do
     1502                        ... continue ®L2®; ...  // continue while
     1503                        ... continue ®L3®; ...  // continue for
     1504                } // for
     1505        } // while
     1506} while ( ... );
    14021507\end{lstlisting}
    14031508&
    14041509\begin{lstlisting}
    1405 for ( ... ) {
    1406         for ( ... ) {
     1510do {
     1511        while ( ... ) {
    14071512                for ( ... ) {
    14081513                        ... goto L1; ...
    14091514                        ... goto L2; ...
    1410                         ... goto L3; // or break 
     1515                        ... goto L3; ...
     1516                L3: ; }
     1517        L2: ; }
     1518L1: ; } while ( ... );
     1519\end{lstlisting}
     1520\end{tabular}
     1521\end{quote2}
     1522The innermost loop has three restart points, which cause the next loop iteration to begin.
     1523
     1524The following example shows the labelled ©break© specifying which control structure is the target for exit:
     1525\begin{quote2}
     1526\begin{tabular}{@{}l@{\hspace{3em}}l@{}}
     1527\multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}}        & \multicolumn{1}{c}{\textbf{C}}        \\
     1528\begin{lstlisting}
     1529®L1:® {
     1530        ... §declarations§ ...
     1531        ®L2:® switch ( ... ) {
     1532          case 3:
     1533            ®L3:® if ( ... ) {
     1534                        ®L4:® for ( ... ) {
     1535                                ... break ®L1®; ...     // exit compound statement
     1536                                ... break ®L2®; ...     // exit switch
     1537                                ... break ®L3®; ...     // exit if
     1538                                ... break ®L4®; ...     // exit loop
     1539                        } // for
     1540                } else {
     1541                        ... break ®L3®; ...             // exit if
     1542                } // if
     1543        } // switch
     1544} // compound
     1545\end{lstlisting}
     1546&
     1547\begin{lstlisting}
     1548{
     1549        ... §declarations§ ...
     1550        switch ( ... ) {
     1551          case 3:
     1552            if ( ... ) {
     1553                        for ( ... ) {
     1554                                ... goto L1; ...
     1555                                ... goto L2; ...
     1556                                ... goto L3; ...
     1557                                ... goto L4; ...
     1558                        } L4: ;
     1559                } else {
     1560                        ... goto L3; ...
    14111561                } L3: ;
    14121562        } L2: ;
     
    14141564\end{lstlisting}
    14151565\end{tabular}
    1416 \caption{Labelled Break}
    1417 \label{f:LabelledBreak}
    1418 
    1419 \vspace*{0.25in}
    1420 
    1421 \begin{tabular}{@{}l@{\hspace{3em}}l@{}}
    1422 \multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}}        & \multicolumn{1}{c}{\textbf{C}}        \\
    1423 \begin{lstlisting}
    1424 ®L1®: for ( ... ) {
    1425         ®L2®: for ( ... ) {
    1426                 ®L3®: for ( ... ) {
    1427                         ... continue ®L1®; ...
    1428                         ... continue ®L2®; ...
    1429                         ... continue ®L3®; // or continue
    1430 
    1431                 }
    1432 
    1433         }
    1434 
    1435 }
    1436 \end{lstlisting}
    1437 &
    1438 \begin{lstlisting}
    1439 for ( ... ) {
    1440         for ( ... ) {
    1441                 for ( ... ) {
    1442                         ... goto L1; ...
    1443                         ... goto L2; ...
    1444                         ... goto L3; // or continue
    1445                   L3: ;
    1446                 }
    1447           L2: ;
    1448         }
    1449   L1: ;
    1450 }
    1451 \end{lstlisting}
    1452 \end{tabular}
    1453 \caption{Labelled Continue}
    1454 \label{f:LabelledContinue}
    1455 \end{figure}
    1456 
    1457 For both ©break© and ©continue©, the target label must be directly associated with a ©for©, ©while© or ©do© statement;
    1458 for ©break©, the target label can also be associated with a ©switch© statement.
    1459 Both ©break© and ©continue© with target labels are simply a ©goto© restricted in the following ways:
     1566\end{quote2}
     1567The innermost loop has four exit points, which cause termination of one or more of the four \Index{nested control structure}s.
     1568
     1569Both ©continue© and ©break© with target labels are simply a ©goto©\index{goto@©goto©!restricted} restricted in the following ways:
    14601570\begin{itemize}
    14611571\item
     
    14641574This restriction is important since all situations that can result in repeated execution of statements in a program are clearly delineated.
    14651575\item
    1466 Since they always transfers out of containing control structures, they cannot be used to branch into a control structure.
     1576Since they always transfer out of containing control structures, they cannot be used to branch into a control structure.
    14671577\end{itemize}
    1468 The advantage of the labelled ©break©/©continue© is that it allows static multi-level exits without having to use the ©goto© statement and ties control flow to the target control structure rather than an arbitrary point in a program.
    1469 Furthermore, the location of the label at the beginning of the target control structure informs the reader that complex control-flow is occurring in the body of the control structure.
    1470 With ©goto©, the label at the end of the control structure fails to convey this important clue early enough to the reader.
    1471 Finally, using an explicit target for the transfer instead of an implicit target allows new nested loop or switch constructs to be added or removed without affecting other constructs.
    1472 The implicit targets of the current ©break© and ©continue©, i.e., the closest enclosing loop or ©switch©, change as certain constructs are added or removed.
     1578The advantage of the labelled ©continue©/©break© is allowing static multi-level exits without having to use the ©goto© statement and tying control flow to the target control structure rather than an arbitrary point in a program.
     1579Furthermore, the location of the label at the \emph{beginning} of the target control structure informs the reader that complex control-flow is occurring in the body of the control structure.
     1580With ©goto©, the label is at the end of the control structure, which fails to convey this important clue early enough to the reader.
     1581Finally, using an explicit target for the transfer instead of an implicit target allows new constructs to be added or removed without affecting existing constructs.
     1582The implicit targets of the current ©continue© and ©break©, i.e., the closest enclosing loop or ©switch©, change as certain constructs are added or removed.
    14731583
    14741584
     
    14811591In this section, the term \emph{case clause} refers to either a ©case© or ©default© clause.}
    14821592\emph{falls through} to the next ©case© clause in the ©switch© statement;
    1483 to exit a ©switch© statement from a ©case© clause requires explicitly terminating the clause with a transfer statement, most commonly ©break©, as in:
     1593to exit a ©switch© statement from a ©case© clause requires explicitly terminating the clause with a transfer statement, most commonly ©break©:
    14841594\begin{lstlisting}
    14851595switch ( i ) {
     
    14921602}
    14931603\end{lstlisting}
    1494 The ability to fall-through to the next clause is a useful form of control flow, specifically when a sequence of case actions compound, as in:
     1604The ability to fall-through to the next clause \emph{is} a useful form of control flow, specifically when a sequence of case actions compound:
    14951605\begin{lstlisting}
    14961606switch ( argc ) {
     
    15071617In this example, case 2 is always done if case 3 is done.
    15081618This 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.
    1509 C also uses fall-through to handle multiple case-values resulting in the same action, as in:
     1619C also uses fall-through to handle multiple case-values resulting in the same action:
    15101620\begin{lstlisting}
    15111621switch ( i ) {
     
    15191629\end{lstlisting}
    15201630However, this situation is handled in other languages without fall-through by allowing a list of case values.
    1521 While fall-through itself is not a problem, the problem occurs when fall-through is the ©default©, as this semantics is not intuitive to most programmers and is different from virtually all other programming languages with a ©switch© statement.
    1522 Hence, ©default© fall-through semantics results in a large number of programming errors as programmers often forget the ©break© statement at the end of a ©case© clause, resulting in inadvertent fall-through.
    1523 
    1524 \item
    1525 It is possible to place ©case© clauses on statements nested \emph{within} the body of the ©switch© statement, as in:
     1631While fall-through itself is not a problem, the problem occurs when fall-through is the default, as this semantics is not intuitive to most programmers and is different from virtually all other programming languages with a ©switch© statement.
     1632Hence, default fall-through semantics results in a large number of programming errors as programmers often forget the ©break© statement at the end of a ©case© clause, resulting in inadvertent fall-through.
     1633
     1634\item
     1635It is possible to place ©case© clauses on statements nested \emph{within} the body of the ©switch© statement:
    15261636\begin{lstlisting}
    15271637switch ( i ) {
     
    15811691\begin{lstlisting}
    15821692switch ( x ) {
    1583         int y = 1;                      // unreachable initialization
    1584         x = 7;                          // unreachable code
     1693        int y = 1;                      §\C{// unreachable initialization}§
     1694        x = 7;                          §\C{// unreachable code}§
    15851695  case 3: ...
    15861696        y = 3;
     
    16041714and 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.
    16051715\end{itemize}
    1606 These observations should help to put the effects of suggested changes into perspective.
    1607 % Figure 1 shows the grammar change that attempts to minimize the effect on existing C programs.
     1716These observations help to put the effects of suggested changes into perspective.
    16081717\begin{enumerate}
    16091718\item
    1610 Eliminating the ©default© fall-through problem has the greatest potential for affecting existing code.
    1611 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, and the common placement of the ©default© clause at the end of the case list.
    1612 In addition, the above grammar provides for the most common use of fall-through, i.e., a list of ©case© clauses executing common code, e.g.:
     1719Eliminating default fall-through has the greatest potential for affecting existing code.
     1720However, 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, i.e., a list of ©case© clauses executing common code, e.g.:
    16131721\begin{lstlisting}
    16141722case 1:  case 2:  case 3: ...
    16151723\end{lstlisting}
     1724still work.
    16161725Nevertheless, reversing the default action would have a non-trivial effect on case actions that compound, such as the above example of processing shell arguments.
    16171726Therefore, to preserve backwards compatibility, it is necessary to introduce a new kind of ©switch© statement, called ©choose©, with no fall-through semantics.
    1618 The ©choose© statement is identical to the new ©switch© statement, except there is no implicit fall-through between case-clauses and the ©break© statement applies to the enclosing loop construct (as for the continue statement in a ©switch© statement).
    1619 It is still possible to fall-through if a case-clause ends with the new keyword fallthru, e.g.:
    1620 \begin{lstlisting}
    1621 choose ( i ) {
    1622         int i;
    1623   case 3, 4:
    1624         i = 3;
    1625         fallthru;
    1626   case 8, 10:
     1727The ©choose© statement is identical to the new ©switch© statement, except there is no implicit fall-through between case-clauses and the ©break© statement applies to the enclosing loop construct (as for the ©continue© statement in a ©switch© statement).
     1728It is still possible to fall-through if a case-clause ends with the new keyword ©fallthru©, e.g.:
     1729\begin{lstlisting}
     1730®choose® ( i ) {
     1731  case 3:
     1732        ...
     1733        ®fallthru®;             §\C{// explicit fall through}§
     1734  case 5:
     1735        ...                             §\C{// implicit end of switch}§
     1736  case 7:
     1737        ...
     1738        ®break®                 §\C{// transfer to end of enclosing loop / switch}§
    16271739  default:
    16281740        j = 3;
    16291741}
    16301742\end{lstlisting}
    1631 The ability to fall-through is retained because it is a sufficient C-idiom that most C programmers simply expect it, and its absence might discourage these programmers from using the choose statement.
     1743The ability to fall-through is retained because it is a sufficient C-idiom that most C programmers simply expect it, and its absence might discourage these programmers from using the ©choose© statement.
    16321744\item
    16331745Eliminating Duff's device is straightforward and only invalidates a small amount of very questionable code.
    16341746The solution is to allow ©case© clauses to only appear at the same nesting level as the ©switch© body, as is done in most other programming languages with ©switch© statements.
    16351747\item
    1636 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 may appear is locations other than at the end.
     1748The 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.
    16371749Therefore, no language change is made for this issue.
    16381750\item
    1639 Dealing with unreachable code at the start of a ©switch© statement is solved by defining the declaration-list, including any associated initialization, at the start of a ©switch© statement body to be executed before the transfer to the appropriate ©case© clause.
     1751Dealing with unreachable code at the start of a ©switch© statement is solved by defining the declaration-list, including any associated initialization, at the start of a ©switch© statement body to be executed \emph{before} the transfer to the appropriate ©case© clause.
    16401752This semantics is the same as for declarations at the start of a loop body, which are executed before each iteration of the loop body.
    1641 As well, this grammar does not allow statements to appear before the first ©case© clause.
     1753As well, statements cannot appear before the first ©case© clause.
    16421754The change is compatible for declarations with initialization in this context because existing code cannot assume the initialization has occurred.
    16431755The change is incompatible for statements, but any existing code using it is highly questionable, as in:
    16441756\begin{lstlisting}
    16451757switch ( i ) {
    1646         L: x = 5;               // questionable code
     1758        L: x = 5;               §\C{// questionable code}§
    16471759  case 0:
    16481760        ...
     
    16911803\end{tabular}
    16921804\end{quote2}
    1693 In addition, two forms of subranges are allowed to specify case values: the GNU C form and a new \CFA form.
     1805In addition, two forms of subranges are allowed to specify case values: a new \CFA form and an existing GNU C form.\footnote{
     1806The GNU C form \emph{requires} spaces around the ellipse.}
    16941807\begin{quote2}
    16951808\begin{tabular}{@{}l@{\hspace{3em}}l@{\hspace{2em}}l@{}}
     
    17231836\end{tabular}
    17241837\end{quote2}
    1725 
    1726 
    1727 \section{Unnamed Structure Fields}
    1728 
    1729 C requires each field of a structure to have a name, except for a bit field associated with a basic type, e.g.:
    1730 \begin{lstlisting}
    1731 struct {
    1732         int f1;                 // named field
    1733         int f2 : 4;             // named field with bit field size
    1734         int : 3;                // unnamed field for basic type with bit field size
    1735         int ;                   // disallowed, unnamed field
    1736         int *;                  // disallowed, unnamed field
    1737         int (*)(int);   // disallowed, unnamed field
    1738 };
    1739 \end{lstlisting}
    1740 This requirement is relaxed by making the field name optional for all field declarations; therefore, all the field declarations in the example are allowed.
    1741 As for unnamed bit fields, an unnamed field is used for padding a structure to a particular size.
    1742 A list of unnamed fields is also supported, e.g.:
    1743 \begin{lstlisting}
    1744 struct {
    1745         int , , ;               // 3 unnamed fields
    1746 }
     1838Lists of subranges are also allowed.
     1839\begin{lstlisting}
     1840case ®1~5, 12~21, 35~42®:
    17471841\end{lstlisting}
    17481842
     
    42174311\section{Incompatible}
    42184312
    4219 The following incompatibles exist between C and \CFA, and are similar to Annex C for \CC~\cite{ANSI14:C++}.
     4313The following incompatibles exist between \CFA and C, and are similar to Annex C for \CC~\cite{ANSI14:C++}.
    42204314
    42214315\begin{enumerate}
    42224316\item
    4223 Change type of character literal ©int© to ©char©.
    4224 This change allows overloading differentiation argument type matching, e.g.:
    4225 \begin{lstlisting}
    4226 int function( int i );
    4227 int function( char c );
    4228 function( 'x' );
    4229 \end{lstlisting}
    4230 It is preferable that this call match the second version of function rather than the first. \\
    4231 Effect on original feature: Change to semantics of well-defined feature. ISO C programs which depend on
    4232 \begin{lstlisting}
    4233 sizeof('x') == sizeof(int)
    4234 \end{lstlisting}
    4235 will not work the same as C++ programs. \\
    4236 Difficulty of converting: Simple. \\
    4237 How widely used: Programs which depend upon sizeof('x') are probably rare.
    4238 
    4239 \item
    4240 Change: String literals made ©const© \\
    4241 The type of a string literal is changed from ©array of char© to ©array of const char©.
    4242 The type of a wide string literal is changed from ©array of wchar_t© to ©array of const wchar_t©. \\
    4243 Rationale: This avoids calling an inappropriate overloaded function, which might expect to be able to modify its argument.
    4244 Effect on original feature: Change to semantics of well-defined feature. \\
    4245 Difficulty of converting: Simple syntactic transformation, because string literals can be converted to ©char*;© (4.2).
    4246 The most common cases are handled by a new but deprecated standard conversion:
    4247 \begin{lstlisting}
    4248 char* p = "abc"; // valid in C, deprecated in C++
    4249 char* q = expr ? "abc" : "de"; // valid in C, invalid in C++
    4250 \end{lstlisting}
    4251 How widely used: Programs that have a legitimate reason to treat string literals as pointers to potentially modifiable memory are probably rare.
    4252 
    4253 \item
    4254 Change: C++ does not have \emph{tentative definitions} as in C.
    4255 E.g., at file scope,
    4256 \begin{lstlisting}
    4257 int i;
    4258 int i;
    4259 \end{lstlisting}
    4260 is valid in C, invalid in C++.
    4261 This makes it impossible to define mutually referential file-local static
    4262 objects, if initializers are restricted to the syntactic forms of C. For example,
     4317\begin{description}
     4318\item[Change:] add new keywords \\
     4319New keywords are added to \CFA.
     4320\item[Rationale:] keywords added to implement new semantics of \CFA.
     4321\item[Effect on original feature:] change to semantics of well-defined feature. \\
     4322Any ISO C programs using these keywords as identifiers are invalid \CFA programs.
     4323\item[Difficulty of converting:] keyword clashes are accommodated by syntactic transformations using the \CFA backquote escape-mechanism:
     4324\begin{lstlisting}
     4325int `otype` = 3;                                // make keyword an indentifier
     4326double `choose` = 3.5;
     4327\end{lstlisting}
     4328Programs can be converted automatically by enclosing keyword identifiers in backquotes, and the backquotes can be remove later when the identifier name is changed.
     4329Clashes in C system libraries (include files) can be handled automatically using preprocessor, ©#include_next© and ©-Ifilename©:
     4330\begin{lstlisting}
     4331// include file uses the CFA keyword "otype".
     4332#if ! defined( otype )                  // nesting ?
     4333#define otype `otype`
     4334#define __CFA_BFD_H__
     4335#endif // ! otype
     4336
     4337#include_next <bfd.h>                   // must have internal check for multiple expansion
     4338
     4339#if defined( otype ) && defined( __CFA_BFD_H__ )        // reset only if set
     4340#undef otype
     4341#undef __CFA_BFD_H__
     4342#endif // otype && __CFA_BFD_H__
     4343\end{lstlisting}
     4344\item[How widely used:] clashes among new \CFA keywords and existing identifiers are rare.
     4345\end{description}
     4346
     4347\item
     4348\begin{description}
     4349\item[Change:] type of character literal ©int© to ©char© to allow more intuitive overloading:
     4350\begin{lstlisting}
     4351int rtn( int i );
     4352int rtn( char c );
     4353rtn( 'x' );                                             // programmer expects 2nd rtn to be called
     4354\end{lstlisting}
     4355\item[Rationale:] it is more intuitive for the call to ©rtn© to match the second version of definition of ©rtn© rather than the first.
     4356In particular, output of ©char© variable now print a character rather than the decimal ASCII value of the character.
     4357\begin{lstlisting}
     4358sout | 'x' | " " | (int)'x' | endl;
     4359x 120
     4360\end{lstlisting}
     4361Having to cast ©'x'© to ©char© is non-intuitive.
     4362\item[Effect on original feature:] change to semantics of well-defined feature that depend on:
     4363\begin{lstlisting}
     4364sizeof( 'x' ) == sizeof( int )
     4365\end{lstlisting}
     4366no long work the same in \CFA programs.
     4367\item[Difficulty of converting:] simple
     4368\item[How widely used:] programs that depend upon ©sizeof( 'x' )© are rare and can be changed to ©sizeof(char)©.
     4369\end{description}
     4370
     4371\item
     4372\begin{description}
     4373\item[Change:] make string literals ©const©:
     4374\begin{lstlisting}
     4375char * p = "abc";                               // valid in C, deprecated in §\CFA§
     4376char * q = expr ? "abc" : "de"; // valid in C, invalid in §\CFA§
     4377\end{lstlisting}
     4378The type of a string literal is changed from ©[] char© to ©const [] char©.
     4379Similarly, the type of a wide string literal is changed from ©[] wchar_t© to ©const [] wchar_t©.
     4380\item[Rationale:] This change is a safety issue:
     4381\begin{lstlisting}
     4382char * p = "abc";
     4383p[0] = 'w';                                             // segment fault or change constant literal
     4384\end{lstlisting}
     4385The same problem occurs when passing a string literal to a routine that changes its argument.
     4386\item[Effect on original feature:] change to semantics of well-defined feature.
     4387\item[Difficulty of converting:] simple syntactic transformation, because string literals can be converted to ©char *©.
     4388\item[How widely used:] programs that have a legitimate reason to treat string literals as pointers to potentially modifiable memory are rare.
     4389\end{description}
     4390
     4391\item
     4392\begin{description}
     4393\item[Change:] remove \newterm{tentative definitions}, which only occurs at file scope:
     4394\begin{lstlisting}
     4395int i;                                                  // forward definition
     4396int *j = ®&i®;                                  // forward reference, valid in C, invalid in §\CFA§
     4397int i = 0;                                              // definition
     4398\end{lstlisting}
     4399is valid in C, and invalid in \CFA because duplicate overloaded object definitions at the same scope level are disallowed.
     4400This change makes it impossible to define mutually referential file-local static objects, if initializers are restricted to the syntactic forms of C. For example,
    42634401\begin{lstlisting}
    42644402struct X { int i; struct X *next; };
    4265 static struct X a;
    4266 static struct X b = { 0, &a };
    4267 static struct X a = { 1, &b };
    4268 \end{lstlisting}
    4269 Rationale: This avoids having different initialization rules for builtin types and userdefined types.
    4270 Effect on original feature: Deletion of semantically welldefined feature. \\
    4271 Difficulty of converting: Semantic transformation.
    4272 In C++, the initializer for one of a set of mutuallyreferential filelocal static objects must invoke a function call to achieve the initialization.
    4273 How widely used: Seldom.
    4274 
    4275 \item
    4276 Change: A struct is a scope in C++, not in C \\
    4277 Rationale: Class scope is crucial to C++, and a struct is a class. \\
    4278 Effect on original feature: Change to semantics of well-defined feature. \\
    4279 Difficulty of converting: Semantic transformation. \\
    4280 How widely used: C programs use struct extremely frequently, but the change is only noticeable when struct, enumeration, or enumerator names are referred to outside the struct.
    4281 The latter is probably rare.
     4403static struct X a;                              // forward definition
     4404static struct X b = { 0, ®&a® };        // forward reference, valid in C, invalid in §\CFA§
     4405static struct X a = { 1, &b };  // definition
     4406\end{lstlisting}
     4407\item[Rationale:] avoids having different initialization rules for builtin types and userdefined types.
     4408\item[Effect on original feature:] change to semantics of well-defined feature.
     4409\item[Difficulty of converting:] the initializer for one of a set of mutually-referential file-local static objects must invoke a routine call to achieve the initialization.
     4410\item[How widely used:] seldom
     4411\end{description}
     4412
     4413\item
     4414\begin{description}
     4415\item[Change:] have ©struct© introduce a scope for nested types
     4416In C, the name of the nested types belongs to the same scope as the name of the outermost enclosing
     4417Example:
     4418\begin{lstlisting}
     4419enum ®Colour® { R, G, B, Y, C, M };
     4420struct Person {
     4421        enum ®Colour® { R, G, B };      // nested type
     4422        struct Face {                           // nested type
     4423                ®Colour® Eyes, Hair;            // type defined outside (1 level)
     4424        };
     4425        ß.ß®Colour® shirt;                              // type defined outside (top level)
     4426        ®Colour® pants;                         // type defined same level
     4427        Face looks[10];                         // type defined same level
     4428};
     4429®Colour® c = R;                                 // type/enum defined same level
     4430Personß.ß®Colour® pc = Personß.ßR;      // type/enum defined inside
     4431Personß.ßFace pretty;                           // type defined inside
     4432\end{lstlisting}
     4433\item[Rationale:] ©struct© scope is crucial to \CFA as an information structuring and hiding mechanism.
     4434\item[Effect on original feature:] change to semantics of well-defined feature.
     4435\item[Difficulty of converting:] Semantic transformation.
     4436\item[How widely used:] C programs rarely have nest types because they are equivalent to the hoisted version.
    42824437
    42834438\CFA is C \emph{incompatible} on this issue, and provides semantics similar to \CC.
    42844439Nested types are not hoisted and can be referenced using the field selection operator ``©.©'', unlike the \CC scope-resolution operator ``©::©''.
    42854440Given that nested types in C are equivalent to not using them, i.e., they are essentially useless, it is unlikely there are any realistic usages that break because of this incompatibility.
    4286 
    4287 \item
    4288 Change: In C++, the name of a nested class is local to its enclosing class.
    4289 In C the name of the nested class belongs to the same scope as the name of the outermost enclosing class
    4290 Example:
    4291 \begin{lstlisting}
    4292 struct X {
    4293 struct Y { /* ... */ } y;
    4294 };
    4295 struct Y yy; // valid C, invalid C++
    4296 \end{lstlisting}
    4297 Rationale: C++ classes have member functions which require that classes establish scopes.
    4298 The C rule would leave classes as an incomplete scope mechanism which would prevent C++ programmers from maintaining locality within a class. A coherent set of scope rules for C++ based on the C rule would be very complicated and C++ programmers would be unable to predict reliably the meanings of nontrivial examples involving nested or local functions.
    4299 Effect on original feature: Change of semantics of welldefined feature.
    4300 Difficulty of converting: Semantic transformation. To make the struct type name visible in the scope of the enclosing struct, the struct tag could be declared in the scope of the enclosing struct, before the enclosing struct is defined. Example:
     4441\end{description}
     4442
     4443\item
     4444\begin{description}
     4445\item[Change:] In C++, the name of a nested class is local to its enclosing class.
     4446\item[Rationale:] C++ classes have member functions which require that classes establish scopes.
     4447\item[Difficulty of converting:] Semantic transformation. To make the struct type name visible in the scope of the enclosing struct, the struct tag could be declared in the scope of the enclosing struct, before the enclosing struct is defined. Example:
    43014448\begin{lstlisting}
    43024449struct Y; // struct Y and struct X are at the same scope
     
    43074454All the definitions of C struct types enclosed in other struct definitions and accessed outside the scope of the enclosing struct could be exported to the scope of the enclosing struct.
    43084455Note: this is a consequence of the difference in scope rules, which is documented in 3.3.
    4309 How widely used: Seldom.
     4456\item[How widely used:] Seldom.
     4457\end{description}
     4458
     4459\item
     4460\begin{description}
     4461\item[Change:] comma expression is disallowed as subscript
     4462\item[Rationale:] safety issue to prevent subscripting error for multidimensional arrays: ©x[i,j]© instead of ©x[i][j]©, and this syntactic form then taken by \CFA for new styple arrays.
     4463\item[Effect on original feature:] change to semantics of well-defined feature.
     4464\item[Difficulty of converting:] semantic transformation of ©x[i,j]© to ©x[(i,j)]©
     4465\item[How widely used:] seldom.
     4466\end{description}
    43104467\end{enumerate}
    43114468
Note: See TracChangeset for help on using the changeset viewer.