- Timestamp:
- Jul 6, 2016, 9:11:20 PM (9 years ago)
- 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
- Location:
- doc
- Files:
-
- 6 edited
-
LaTeXmacros/common.tex (modified) (6 diffs)
-
refrat/refrat.tex (modified) (3 diffs)
-
user/Cdecl.fig (modified) (2 diffs)
-
user/Makefile (modified) (2 diffs)
-
user/pointer2.fig (modified) (1 diff)
-
user/user.tex (modified) (46 diffs)
Legend:
- Unmodified
- Added
- Removed
-
doc/LaTeXmacros/common.tex
r99f11dd r4096de0 11 11 %% Created On : Sat Apr 9 10:06:17 2016 12 12 %% Last Modified By : Peter A. Buhr 13 %% Last Modified On : Mon Jun 20 09:35:20201614 %% Update Count : 17813 %% Last Modified On : Sun Jul 3 08:36:24 2016 14 %% Update Count : 200 15 15 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 16 16 … … 27 27 \righthyphenmin=4 28 28 29 \usepackage{pslatex} % reduce size of san serif font29 %\usepackage{pslatex} % reduce size of san serif font 30 30 31 31 \usepackage[ignoredisplayed]{enumitem} % do not affect trivlist … … 36 36 \setlist[enumerate]{listparindent=\parindent}% global 37 37 \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} 39 39 40 40 % Names used in the document. … … 52 52 \newlength{\parindentlnth} 53 53 \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} 54 61 55 62 % allow escape sequence in lstinline … … 123 130 \newcommand{\indexc}[1]{\index{#1@\lstinline$#1$}} 124 131 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}. 125 135 \newcommand{\newtermFontInline}{\emph} 126 136 \newcommand{\newterm}{\@ifstar\@snewterm\@newterm} … … 204 214 \lstset{ 205 215 language=CFA, 206 columns=f lexible,216 columns=fullflexible, 207 217 basicstyle=\linespread{0.9}\sf, 208 218 stringstyle=\tt, -
doc/refrat/refrat.tex
r99f11dd r4096de0 11 11 %% Created On : Wed Apr 6 14:52:25 2016 12 12 %% Last Modified By : Peter A. Buhr 13 %% Last Modified On : Sat Jun 18 19:21:30 201614 %% Update Count : 7 413 %% Last Modified On : Wed Jun 22 14:18:30 2016 14 %% Update Count : 77 15 15 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 16 16 … … 49 49 \renewcommand{\UrlFont}{\small\sf} 50 50 51 \setlength{\topmargin}{-0.45in} % move running title into header 52 \setlength{\headsep}{0.25in} 53 51 54 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 52 55 … … 69 72 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 70 73 71 \begin{document}72 \pagestyle{headings}73 \linenumbers % comment out to turn off line numbering74 75 74 \title{\Huge 76 75 \vspace*{1in} 77 76 \CFA (\CFL) Reference Manual and Rationale 78 77 }% title 78 79 79 \author{\huge 80 80 Glen Ditchfield and Peter A. Buhr 81 81 }% author 82 82 83 \date{ 83 DRAFT \\ 84 \today 84 DRAFT \\ \today 85 85 }% date 86 86 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}} 87 94 \pagenumbering{roman} 88 \ pagestyle{plain}95 \linenumbers % comment out to turn off line numbering 89 96 90 97 \maketitle 91 98 \thispagestyle{empty} 92 99 \vspace*{\fill} 93 \thispagestyle{empty}94 100 \noindent 95 101 \copyright\,2015 Glen Ditchfield \\ \\ -
doc/user/Cdecl.fig
r99f11dd r4096de0 8 8 -2 9 9 1200 2 10 6 1125 1200 2025 165011 2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 512 1275 1200 2025 1200 2025 1350 1275 1350 1275 120013 2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 214 1425 1200 1425 135015 2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 216 1575 1200 1575 135017 2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 218 1725 1200 1725 135019 2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 220 1875 1200 1875 135021 2 1 0 1 0 7 50 -1 -1 4.000 0 0 -1 1 0 222 1 1 1.00 45.00 90.0023 1350 1275 1350 150024 2 1 0 1 0 7 50 -1 -1 4.000 0 0 -1 1 0 225 1 1 1.00 45.00 90.0026 1500 1275 1500 150027 2 1 0 1 0 7 50 -1 -1 4.000 0 0 -1 1 0 228 1 1 1.00 45.00 90.0029 1650 1275 1650 150030 2 1 0 1 0 7 50 -1 -1 4.000 0 0 -1 1 0 231 1 1 1.00 45.00 90.0032 1800 1275 1800 150033 2 1 0 1 0 7 50 -1 -1 4.000 0 0 -1 1 0 234 1 1 1.00 45.00 90.0035 1950 1275 1950 150036 4 1 0 50 -1 4 10 0.0000 2 105 90 1350 1650 0\00137 4 1 0 50 -1 4 10 0.0000 2 105 90 1500 1650 1\00138 4 1 0 50 -1 4 10 0.0000 2 105 90 1650 1650 2\00139 4 1 0 50 -1 4 10 0.0000 2 105 90 1800 1650 3\00140 4 1 0 50 -1 4 10 0.0000 2 105 90 1950 1650 4\00141 4 1 0 50 -1 4 10 0.0000 2 75 75 1200 1325 x\00142 -643 6 2325 1200 3600 135044 6 2475 1200 3600 135045 10 6 2850 1200 3600 1350 46 11 2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 … … 54 19 2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 55 20 2850 1200 3600 1200 3600 1350 2850 1350 2850 1200 56 4 1 0 50 -1 4 10 0.0000 2 1 0590 2925 1325 0\00157 4 1 0 50 -1 4 10 0.0000 2 1 0590 3075 1325 1\00158 4 1 0 50 -1 4 10 0.0000 2 1 0590 3225 1325 2\00159 4 1 0 50 -1 4 10 0.0000 2 1 0590 3375 1325 3\00160 4 1 0 50 -1 4 10 0.0000 2 1 0590 3525 1325 4\00121 4 1 0 50 -1 4 10 0.0000 2 120 90 2925 1325 0\001 22 4 1 0 50 -1 4 10 0.0000 2 120 90 3075 1325 1\001 23 4 1 0 50 -1 4 10 0.0000 2 120 90 3225 1325 2\001 24 4 1 0 50 -1 4 10 0.0000 2 120 90 3375 1325 3\001 25 4 1 0 50 -1 4 10 0.0000 2 120 90 3525 1325 4\001 61 26 -6 62 27 2 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 29 2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 30 1425 1200 1425 1350 31 2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 32 1575 1200 1575 1350 33 2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 34 1725 1200 1725 1350 35 2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 36 1875 1200 1875 1350 37 2 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 40 2 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 43 2 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 46 2 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 49 2 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 52 2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 63 53 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 265 1 1 1.00 45.00 90.0054 2 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 66 56 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 57 4 1 0 50 -1 4 10 0.0000 2 120 90 1350 1650 0\001 58 4 1 0 50 -1 4 10 0.0000 2 120 90 1500 1650 1\001 59 4 1 0 50 -1 4 10 0.0000 2 120 90 1650 1650 2\001 60 4 1 0 50 -1 4 10 0.0000 2 120 90 1800 1650 3\001 61 4 1 0 50 -1 4 10 0.0000 2 120 90 1950 1650 4\001 62 4 1 0 50 -1 4 10 0.0000 2 90 90 1200 1325 x\001 63 4 1 0 50 -1 4 10 0.0000 2 90 90 2400 1325 x\001 -
doc/user/Makefile
r99f11dd r4096de0 13 13 FIGURES = ${addsuffix .tex, \ 14 14 Cdecl \ 15 pointer1 \ 15 16 } 16 17 17 18 PICTURES = ${addsuffix .pstex, \ 19 pointer2 \ 18 20 } 19 21 … … 71 73 fig2dev -L ps $< > $@ 72 74 75 %.pstex : %.fig 76 fig2dev -L pstex $< > $@ 77 fig2dev -L pstex_t -p $@ $< > $@_t 78 73 79 # Local Variables: # 74 80 # compile-command: "make" # -
doc/user/pointer2.fig
r99f11dd r4096de0 8 8 -2 9 9 1200 2 10 6 2775 1500 4425 2250 10 2 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 13 2 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 11 16 2 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 195017 1500 1500 1800 1500 1800 1800 1500 1800 1500 1500 13 18 2 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 24 20 2 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 195021 2550 1500 2850 1500 2850 1800 2550 1800 2550 1500 26 22 2 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 24 2 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 27 2 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 30 29 4 2 0 100 0 4 10 0.0000 2 120 270 1425 2250 104\001 31 30 4 2 0 100 0 4 10 0.0000 2 120 270 1425 1800 100\001 32 31 4 2 0 100 0 4 10 0.0000 2 90 90 1425 1625 x\001 33 32 4 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 33 4 1 0 100 0 4 10 0.0000 2 120 90 1650 1700 3\001 34 4 1 0 100 0 4 10 0.0000 2 120 90 1650 2150 3\001 35 4 0 0 100 0 4 10 0.0000 2 120 165 1875 2150 int\001 36 4 0 0 100 0 4 10 0.0000 2 120 165 1875 1700 int\001 37 4 2 0 100 0 4 10 0.0000 2 120 270 2475 2250 112\001 38 4 2 0 100 0 4 10 0.0000 2 150 180 2475 2075 p2\001 39 4 2 0 100 0 4 10 0.0000 2 120 270 2475 1800 108\001 40 4 2 0 100 0 4 10 0.0000 2 150 180 2475 1625 p1\001 41 4 1 0 100 0 4 10 0.0000 2 120 270 2700 1700 104\001 42 4 1 0 100 0 4 10 0.0000 2 120 270 2700 2150 100\001 43 4 0 0 100 0 4 10 0.0000 2 120 270 2925 2150 int *\001 44 4 0 0 100 0 4 10 0.0000 2 120 270 2925 1700 int *\001 45 4 2 0 100 0 4 10 0.0000 2 120 270 3525 1800 116\001 46 4 2 0 100 0 4 10 0.0000 2 150 180 3525 1625 p3\001 47 4 1 0 100 0 4 10 0.0000 2 120 270 3750 1700 112\001 48 4 0 0 100 0 4 10 0.0000 2 120 330 3975 1700 int **\001 -
doc/user/user.tex
r99f11dd r4096de0 11 11 %% Created On : Wed Apr 6 14:53:29 2016 12 12 %% Last Modified By : Peter A. Buhr 13 %% Last Modified On : Mon Jun 20 10:47:22201614 %% Update Count : 57513 %% Last Modified On : Wed Jul 6 21:08:24 2016 14 %% Update Count : 1070 15 15 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 16 16 … … 36 36 \usepackage{epic,eepic} 37 37 \usepackage{upquote} % switch curled `'" to straight 38 \usepackage{calc} 38 39 \usepackage{xspace} 40 \usepackage{graphicx} 39 41 \usepackage{varioref} % extended references 40 42 \usepackage{listings} % format program code … … 50 52 \renewcommand{\UrlFont}{\small\sf} 51 53 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} 62 56 63 57 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% … … 105 99 \begin{document} 106 100 \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}} 107 104 \pagenumbering{roman} 108 105 \linenumbers % comment out to turn off line numbering 109 106 110 107 \maketitle 111 108 \thispagestyle{empty} 112 109 \vspace*{\fill} 113 \thispagestyle{empty}114 110 \noindent 115 111 \copyright\,2016 \CFA Project \\ \\ … … 120 116 121 117 \clearpage 118 \thispagestyle{plain} 122 119 \pdfbookmark[1]{Contents}{section} 123 120 \tableofcontents 124 121 125 122 \clearpage 126 \ markright{\CFA User Manual}123 \thispagestyle{plain} 127 124 \pagenumbering{arabic} 128 125 … … 306 303 \begin{lstlisting} 307 304 #ifndef __CFORALL__ 308 #include <stdio.h> // C header file305 #include <stdio.h> §\C{// C header file}§ 309 306 #else 310 #include <fstream> // §\CFA{}§ header file307 #include <fstream> §\C{// \CFA header file}§ 311 308 #endif 312 309 \end{lstlisting} … … 318 315 Numeric constants are extended to allow \Index{underscore}s within constants\index{constant!underscore}, e.g.: 319 316 \begin{lstlisting} 320 2®_®147®_®483®_®648; // decimal constant321 56_ul; // decimal unsigned long constant322 0_377; // octal constant323 0x_ff_ff; // hexadecimal constant324 0x_ef3d_aa5c; // hexadecimal constant325 3.141_592_654; // floating point constant326 10_e_+1_00; // floating point constant327 0x_ff_ff_p_3; // hexadecimal floating point328 0x_1.ffff_ffff_p_128_l; // hexadecimal floating point long constant329 L_"\x_ff_ee"; // wide character constant317 2®_®147®_®483®_®648; §\C{// decimal constant}§ 318 56_ul; §\C{// decimal unsigned long constant}§ 319 0_377; §\C{// octal constant}§ 320 0x_ff_ff; §\C{// hexadecimal constant}§ 321 0x_ef3d_aa5c; §\C{// hexadecimal constant}§ 322 3.141_592_654; §\C{// floating point constant}§ 323 10_e_+1_00; §\C{// floating point constant}§ 324 0x_ff_ff_p_3; §\C{// hexadecimal floating point}§ 325 0x_1.ffff_ffff_p_128_l; §\C{// hexadecimal floating point long constant}§ 326 L_"\x_ff_ee"; §\C{// wide character constant}§ 330 327 \end{lstlisting} 331 328 The rules for placement of underscores is as follows: … … 363 360 \end{quote2} 364 361 Is this an array of 5 pointers to integers or a pointer to an array of 5 integers? 362 The fact this declaration is unclear to many C programmers means there are \Index{productivity} and \Index{safety} issues even for basic programs. 365 363 Another 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. 366 364 For example, a routine returning a pointer to an array of integers is defined and used in the following way: 367 365 \begin{lstlisting} 368 int (*f())[5] {...}; // definition mimics usage366 int (*f())[5] {...}; §\C{}§ 369 367 ... (*f())[3] += 1; 370 368 \end{lstlisting} 371 369 Essentially, 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.370 While attempting to make the two contexts consistent is a laudable goal, it has not worked out in practice. 373 371 374 372 \CFA provides its own type, variable and routine declarations, using a different syntax. 375 373 The new declarations place qualifiers to the left of the base type, while C declarations place qualifiers to the right of the base type. 376 374 In 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 thevariable's type.375 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 right to specify a variable's type. 378 376 \begin{quote2} 379 377 \begin{tabular}{@{}l@{\hspace{3em}}l@{}} … … 408 406 \end{tabular} 409 407 \end{quote2} 408 The 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; 414 int y; 415 \end{lstlisting} 416 & 417 \begin{lstlisting} 418 int ®*®x, y; 419 420 \end{lstlisting} 421 \end{tabular} 422 \end{quote2} 423 which is \Index{prescribing} a safety benefit. 410 424 Other examples are: 411 425 \begin{quote2} … … 493 507 e.g.: 494 508 \begin{lstlisting} 495 x; // int x496 *y; // int *y497 f( p1, p2 ); // int f( int p1, int p2 );498 f( p1, p2 ) {} // int f( int p1, int p2 ) {}509 x; §\C{// int x}§ 510 *y; §\C{// int *y}§ 511 f( p1, p2 ); §\C{// int f( int p1, int p2 );}§ 512 f( p1, p2 ) {} §\C{// int f( int p1, int p2 ) {}}§ 499 513 \end{lstlisting} 500 514 … … 504 518 505 519 506 \section{Reference Pointers} 520 \section{Pointer / Reference} 521 522 C provides a \newterm{pointer type}; 523 \CFA adds a \newterm{reference type}. 524 Both types contain an \newterm{address}, which is normally a location in memory. 525 Special addresses are used to denote certain states or access co-processor memory. 526 By 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. 527 Often dereferencing a special state causes a memory fault, so checking is necessary during execution. 528 If the programming language assigns addresses, a program's execution is \Index{sound}, i.e., all addresses are to valid memory locations. 529 C allows programmers to assign addresses, so there is the potential for incorrect addresses, both inside and outside of the computer address-space. 507 530 508 531 Program variables are implicit pointers to memory locations generated by the compiler and automatically dereferenced, as in: 509 532 \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} 535 int x; 515 536 x = 3; 537 int y; 516 538 y = x; 517 539 \end{lstlisting} 518 540 & 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} 544 int * const x = (int *)100 545 *x = 3; // implicit dereference 546 int * const y = (int *)104; 547 *y = *x; // implicit dereference 523 548 \end{lstlisting} 524 549 \end{tabular} 525 550 \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 thevariable's address.551 where the right example is how the compiler logically interpreters variables. 552 Since a variable name only points to one location during its lifetime, it is a \Index{immutable} pointer; 553 hence, variables ©x© and ©y© are constant pointers in the compiler interpretation. 554 In general, variable addresses are stored in instructions instead of loaded independently, so an instruction fetch implicitly loads a variable's address. 530 555 \begin{quote2} 531 556 \begin{tabular}{@{}l|l@{}} 532 557 \begin{lstlisting} 533 x = x + 1 534 &x = *(&x) + 1 535 (100) = *(100) + 1 558 lda r1,100 // load address of x 559 ld r2,(r1) // load value of x 560 lda r3,104 // load address of y 561 st r2,(r3) // store x into y 536 562 \end{lstlisting} 537 563 & 538 564 \begin{lstlisting} 539 ld r1,(100) // address of x 540 add r1,1 541 st r1,(100) // address of x 565 566 ld r2,(100) // load value of x 567 568 st r2,(104) // store x into y 542 569 \end{lstlisting} 543 570 \end{tabular} 544 571 \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). 572 Finally, 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. 573 Therefore, 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 575 A 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.) 549 577 Hence, 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} 581 int x, y, ®*® p1, ®*® p2, ®**® p3; 582 p1 = ®&®x; // p1 points to x 583 p2 = p1; // p2 also points to x 584 p1 = ®&®y; // p1 points to y 585 p1 = p2 + 1; // p1 points to y, pointer arithmetic 586 p3 = &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 593 Notice, an address has a duality\index{address!duality}: a location in memory or the value at that location. 594 In many cases, the compiler can infer the meaning: 595 \begin{lstlisting} 596 p2 = p1 + x; §\C{// compiler infers *p2 = *p1 + x;}§ 597 \end{lstlisting} 598 because adding the arbitrary integer value in ©x© to the address of ©p1© and storing the resulting address into ©p2© is an unlikely operation. 565 599 Algol68~\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}% 600 However, there are ambiguous cases, especially when \Index{pointer arithmetic} is possible, as in C: 601 \begin{lstlisting} 602 p1 = p2; §\C{// p1 = p2 or *p1 = *p2}§ 603 p1 = p1 + 1; §\C{// p1 = p1 + 1 or *p1 = *p1 + 1}§ 604 \end{lstlisting} 605 606 Most 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}. 607 In 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} 609 p1 = p2; §\C{// pointer address assignment}§ 610 *p1 = *p1 + 1; §\C{// pointed-to value assignment / operation}§ 611 \end{lstlisting} 612 which works well for situations where manipulation of addresses in the primary meaning and data is rarely accessed, such as storage management (©malloc©/©free©). 613 614 However, 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} 618 In this case, it is tedious to explicitly write the dereferencing, and error prone when pointer arithmetic is allowed. 619 It is better to have the compiler generate the dereferencing and have no implicit pointer arithmetic: 620 \begin{lstlisting} 621 p2 = ((p1 + p2) * (p3 - p1)) / (p3 - 15); 622 \end{lstlisting} 623 624 To switch the default meaning for an address requires a new kind of pointer, called a \newterm{reference} and denoted by ©&©. 625 \begin{lstlisting} 626 int 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}§ 632 r2 = ((r1 + r2) * (r3 - r1)) / (r3 - 15); §\C{// implicit dereferencing}§ 633 \end{lstlisting} 634 Except for auto-dereferencing by the compiler, this reference example is the same as the pointer example. 635 Hence, a reference behaves like the variable name for the current variable it is pointing-to. 636 The 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} 638 r2 = ((r1 + r2) * (r3 - r1)) / (r3 - 15); 639 \end{lstlisting} 640 is rewritten as: 641 \begin{lstlisting} 642 ®*®r2 = ((®*®r1 + ®*®r2) ®*® (®**®r3 - ®*®r1)) / (®**®r3 - 15); 643 \end{lstlisting} 644 When a reference appears beside a dereference, e.g., ©&*©, they cancel out.\footnote{ 645 The unary ©&© operator yields the address of its operand. 646 If the operand has type ``type'', the result has type ``pointer to type''. 647 If 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}} 648 Hence, 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} 652 Similarly, 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} 658 int x, *p1 = &x, **p2 = &p1, ***p3 = &p2, 659 &r1 = &x, &&r2 = &&r1, &&&r3 = &&r2; 660 ***p3 = 3; §\C{// change x}§ 661 r3 = 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} 668 Finally, implicit dereferencing and cancellation are a static (compilation) phenomenon not a dynamic one. 669 That 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. 670 A 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; 671 otherwise, everything else is equal. 672 673 Interestingly, \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. 674 Java deals with the address duality by making address assignment the default and providing a \Index{clone} mechanism to change the pointed-to value. 675 676 As for pointers, references may have qualifiers: 677 \begin{lstlisting} 678 const int cx = 5; §\C{// cannot change cx;}§ 679 const int & r3 = &cx; §\C{// cannot change what r3 is pointing to}§ 680 ®&®r3 = &cx; §\C{// can change r3}§ 681 r3 = 7; §\C{// error, cannot change cx}§ 682 int & const r4 = &x; §\C{// must be initialized, \CC reference}§ 683 ®&®r4 = &x; §\C{// error, cannot change r4}§ 684 const int & const r5 = &cx; §\C{// must be initialized, \CC reference}§ 685 r5 = 7; §\C{// error, cannot change cx}§ 686 ®&®r5 = &cx; §\C{// error, cannot change r5}§ 687 \end{lstlisting} 688 Hence, for type ©& const©, there is no pointer assignment, so ©&r4 = &x© is disallowed, and \emph{the address value cannot be ©0©}. 689 in 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. 692 There are three initialization contexts in \CFA: declaration initialization, argument/parameter binding, return/temporary binding. 693 For reference (like pointer) initialization, the initializing value must be an address (lvalue) not a value (rvalue). 694 \begin{lstlisting} 695 int * p = &x; §\C{// both \&x and x are possible interpretations}§ 696 int & r = x; §\C{// x unlikely interpretation, because of auto-dereferencing}§ 697 \end{lstlisting} 698 Hence, the compiler implicitly inserts a reference, ©&©, before the initialization expression: 699 Similarly, when a reference is used for a parameter/return type, the call-site argument does not require a reference. 700 \begin{lstlisting} 701 int & f( int & ri ); §\C{// reference parameter and return}§ 702 z = f( x ) + f( y ); §\C{// reference not required}§ 703 \end{lstlisting} 704 Within routine ©f©, it is possible to change the argument by changing the corresponding parameter, and parameter ©ri© can be locally reassigned within ©f©. 705 The return reference from ©f© is copied into a compiler generated temporary, which is logically treated as an initialization. 706 707 When a pointer/reference parameter has a ©const© value (immutable), it is possible to pass literals and expressions. 708 \begin{lstlisting} 709 void f( const int & cri ); 710 void g( const int * cri ); 711 f( 3 ); g( &3 ); 712 f( x + y ); g( &(x + y) ); 713 \end{lstlisting} 714 Here, 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. 717 Essentially, there is an implicit rvalue to lvalue conversion in this case.\footnote{ 718 This 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.} 719 The implicit conversion allows seamless calls to any routine without having to explicit name/copy the literal/expression to allow the call. 720 721 While \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} 625 723 void 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. 724 void (*fp)( int ) = &f; §\C{// pointer initialization}§ 725 void (*fp)( int ) = f; §\C{// reference initialization}§ 726 (*fp)(3); §\C{// pointer invocation}§ 727 fp(3); §\C{// reference invocation}§ 728 \end{lstlisting} 729 A routine variable is best described by a ©const© reference: 730 \begin{lstlisting} 731 const void (&fp)( int ) = f; 732 fp( 3 ); 733 fp = ... §\C{// change code not allowed}§ 734 &fp = ...; §\C{// change routine refernce allowed}§ 735 \end{lstlisting} 736 because the value of the routine variable is a routine literal, i.e., the routine code is normally immutable during execution.\footnote{ 737 Dynamic 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 656 740 657 741 \section{Type Operators} … … 696 780 in 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: 697 781 \begin{lstlisting} 698 [§\,§] g(); // no input or output parameters699 [ void ] g( void ); // no input or output parameters782 [§\,§] g(); §\C{// no input or output parameters}§ 783 [ void ] g( void ); §\C{// no input or output parameters}§ 700 784 \end{lstlisting} 701 785 … … 715 799 \begin{lstlisting} 716 800 typedef int foo; 717 int f( int (* foo) ); // foo is redefined as a parameter name801 int f( int (* foo) ); §\C{// foo is redefined as a parameter name}§ 718 802 \end{lstlisting} 719 803 The 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. … … 723 807 C-style declarations can be used to declare parameters for \CFA style routine definitions, e.g.: 724 808 \begin{lstlisting} 725 [ int ] f( * int, int * ); // returns an integer, accepts 2 pointers to integers726 [ * int, int * ] f( int ); // returns 2 pointers to integers, accepts an integer809 [ 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}§ 727 811 \end{lstlisting} 728 812 The 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: 729 813 \begin{lstlisting} 730 814 #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 ] )815 int 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 ] )}§ 733 817 \end{lstlisting} 734 818 Again, programmers are highly encouraged to use one declaration form or the other, rather than mixing the forms. … … 752 836 int z; 753 837 ... x = 0; ... y = z; ... 754 ®return;® // implicitly return x, y838 ®return;® §\C{// implicitly return x, y}§ 755 839 } 756 840 \end{lstlisting} … … 762 846 [ int x, int y ] f() { 763 847 ... 764 } // implicitly return x, y848 } §\C{// implicitly return x, y}§ 765 849 \end{lstlisting} 766 850 In this case, the current values of ©x© and ©y© are returned to the calling routine just as if a ©return© had been encountered. … … 772 856 as well, parameter names are optional, e.g.: 773 857 \begin{lstlisting} 774 [ int x ] f (); // returning int with no parameters775 [ * int ] g (int y); // returning pointer to int with int parameter776 [ ] h (int,char); // returning no result with int and char parameters777 [ * int,int ] j (int); // returning pointer to int and int, with int parameter858 [ 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}§ 778 862 \end{lstlisting} 779 863 This syntax allows a prototype declaration to be created by cutting and pasting source text from the routine definition header (or vice versa). … … 802 886 The syntax for pointers to \CFA routines specifies the pointer name on the right, e.g.: 803 887 \begin{lstlisting} 804 * [ int x ] () fp; // pointer to routine returning int with no parameters805 * [ * int ] (int y) gp; // pointer to routine returning pointer to int with int parameter806 * [ ] (int,char) hp; // pointer to routine returning no result with int and char parameters807 * [ * int,int ] (int) jp; // pointer to routine returning pointer to int and int, with int parameter888 * [ 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}§ 808 892 \end{lstlisting} 809 893 While parameter names are optional, \emph{a routine name cannot be specified}; 810 894 for example, the following is incorrect: 811 895 \begin{lstlisting} 812 * [ int x ] f () fp; // routine name "f" is not allowed896 * [ int x ] f () fp; §\C{// routine name "f" is not allowed}§ 813 897 \end{lstlisting} 814 898 … … 833 917 whereas a named (keyword) call may be: 834 918 \begin{lstlisting} 835 p( z : 3, x : 4, y : 7 ); // rewrite $\Rightarrow$ p( 4, 7, 3 )919 p( z : 3, x : 4, y : 7 ); §\C{// rewrite $\Rightarrow$ p( 4, 7, 3 )}§ 836 920 \end{lstlisting} 837 921 Here the order of the arguments is unimportant, and the names of the parameters are used to associate argument values with the corresponding parameters. … … 850 934 For example, the following routine prototypes and definition are all valid. 851 935 \begin{lstlisting} 852 void p( int, int, int ); // equivalent prototypes936 void p( int, int, int ); §\C{// equivalent prototypes}§ 853 937 void p( int x, int y, int z ); 854 938 void p( int y, int x, int z ); 855 939 void p( int z, int y, int x ); 856 void p( int q, int r, int s ) {} // match with this definition940 void p( int q, int r, int s ) {} §\C{// match with this definition}§ 857 941 \end{lstlisting} 858 942 Forcing matching parameter names in routine prototypes with corresponding routine definitions is possible, but goes against a strong tradition in C programming. … … 869 953 the allowable positional calls are: 870 954 \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 )955 p(); §\C{// rewrite $\Rightarrow$ p( 1, 2, 3 )}§ 956 p( 4 ); §\C{// rewrite $\Rightarrow$ p( 4, 2, 3 )}§ 957 p( 4, 4 ); §\C{// rewrite $\Rightarrow$ p( 4, 4, 3 )}§ 958 p( 4, 4, 4 ); §\C{// rewrite $\Rightarrow$ p( 4, 4, 4 )}§ 875 959 // 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 )960 p( , 4, 4 ); §\C{// rewrite $\Rightarrow$ p( 1, 4, 4 )}§ 961 p( 4, , 4 ); §\C{// rewrite $\Rightarrow$ p( 4, 2, 4 )}§ 962 p( 4, 4, ); §\C{// rewrite $\Rightarrow$ p( 4, 4, 3 )}§ 963 p( 4, , ); §\C{// rewrite $\Rightarrow$ p( 4, 2, 3 )}§ 964 p( , 4, ); §\C{// rewrite $\Rightarrow$ p( 1, 4, 3 )}§ 965 p( , , 4 ); §\C{// rewrite $\Rightarrow$ p( 1, 2, 4 )}§ 966 p( , , ); §\C{// rewrite $\Rightarrow$ p( 1, 2, 3 )}§ 883 967 \end{lstlisting} 884 968 Here the missing arguments are inserted from the default values in the parameter list. … … 904 988 Default values may only appear in a prototype versus definition context: 905 989 \begin{lstlisting} 906 void p( int x, int y = 2, int z = 3 ); // prototype: allowed907 void p( int, int = 2, int = 3 ); // prototype: allowed908 void p( int x, int y = 2, int z = 3 ) {} // definition: not allowed990 void p( int x, int y = 2, int z = 3 ); §\C{// prototype: allowed}§ 991 void p( int, int = 2, int = 3 ); §\C{// prototype: allowed}§ 992 void p( int x, int y = 2, int z = 3 ) {} §\C{// definition: not allowed}§ 909 993 \end{lstlisting} 910 994 The reason for this restriction is to allow separate compilation. … … 921 1005 \begin{lstlisting} 922 1006 p( 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 */, . . . );1007 p( 1, 4, 5, 6, z : 3, y : 2 ); §\C{// assume p( /* positional */, . . ., /* named */ );}§ 1008 p( 1, z : 3, y : 2, 4, 5, 6 ); §\C{// assume p( /* positional */, /* named */, . . . );}§ 925 1009 \end{lstlisting} 926 1010 In 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. … … 931 1015 \begin{lstlisting} 932 1016 void 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 */, . . . );1017 p( 1, 4, 5, 6, z : 3 ); §\C{// assume p( /* positional */, . . ., /* named */ );}§ 1018 p( 1, z : 3, 4, 5, 6 ); §\C{// assume p( /* positional */, /* named */, . . . );}§ 935 1019 \end{lstlisting} 936 1020 The first call is an error because arguments 4 and 5 are actually positional not ellipse arguments; … … 962 1046 Furthermore, overloading cannot handle accessing default arguments in the middle of a positional list, via a missing argument, such as: 963 1047 \begin{lstlisting} 964 p( 1, /* default */, 5 ); // rewrite $\Rightarrow$ p( 1, 2, 5 )1048 p( 1, /* default */, 5 ); §\C{// rewrite $\Rightarrow$ p( 1, 2, 5 )}§ 965 1049 \end{lstlisting} 966 1050 … … 1058 1142 const unsigned int size = 5; 1059 1143 int ia[size]; 1060 ... // assign values to array ia1061 qsort( ia, size ); // sort ascending order using builtin ?<?1144 ... §\C{// assign values to array ia}§ 1145 qsort( ia, size ); §\C{// sort ascending order using builtin ?<?}§ 1062 1146 { 1063 ®int ?<?( int x, int y ) { return x > y; }® // nested routine1064 qsort( ia, size ); // sort descending order by local redefinition1147 ®int ?<?( int x, int y ) { return x > y; }® §\C{// nested routine}§ 1148 qsort( ia, size ); §\C{// sort descending order by local redefinition}§ 1065 1149 } 1066 1150 \end{lstlisting} … … 1070 1154 The following program in undefined in \CFA (and ©gcc©\index{gcc}) 1071 1155 \begin{lstlisting} 1072 [* [int]( int )] foo() { // int (*foo())( int )1156 [* [int]( int )] foo() { §\C{// int (*foo())( int )}§ 1073 1157 int ®i® = 7; 1074 1158 int bar( int p ) { 1075 ®i® += 1; // dependent on local variable1159 ®i® += 1; §\C{// dependent on local variable}§ 1076 1160 sout | ®i® | endl; 1077 1161 } 1078 return bar; // undefined because of local dependence1162 return bar; §\C{// undefined because of local dependence}§ 1079 1163 } 1080 1164 int main() { 1081 * [int](int) fp = foo(); // int (*fp)(int)1165 * [int](int) fp = foo(); §\C{// int (*fp)(int)}§ 1082 1166 sout | fp( 3 ) | endl; 1083 1167 } … … 1122 1206 [ unsigned int, char ] 1123 1207 [ double, double, double ] 1124 [ * int, int * ] // mix of CFA and ANSI1208 [ * int, int * ] §\C{// mix of CFA and ANSI}§ 1125 1209 [ * [ 5 ] int, * * char, * [ [ int, int ] ] (int, int) ] 1126 1210 \end{lstlisting} … … 1129 1213 Examples of declarations using tuple types are: 1130 1214 \begin{lstlisting} 1131 [ int, int ] x; // 2 element tuple, each element of type int1132 * [ char, char ] y; // pointer to a 2 element tuple1215 [ int, int ] x; §\C{// 2 element tuple, each element of type int}§ 1216 * [ char, char ] y; §\C{// pointer to a 2 element tuple}§ 1133 1217 [ [ int, int ] ] z ([ int, int ]); 1134 1218 \end{lstlisting} … … 1228 1312 [ int, int, int, int ] w = [ 1, 2, 3, 4 ]; 1229 1313 int x = 5; 1230 [ x, w ] = [ w, x ]; // all four tuple coercions1314 [ x, w ] = [ w, x ]; §\C{// all four tuple coercions}§ 1231 1315 \end{lstlisting} 1232 1316 Starting on the right-hand tuple in the last assignment statement, w is opened, producing a tuple of four values; … … 1314 1398 both these examples produce indeterminate results: 1315 1399 \begin{lstlisting} 1316 f( x++, x++ ); // C routine call with side effects in arguments1317 [ v1, v2 ] = [ x++, x++ ]; // side effects in righthand side of multiple assignment1400 f( 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}§ 1318 1402 \end{lstlisting} 1319 1403 … … 1335 1419 \end{lstlisting} 1336 1420 As in C, the rightmost assignment is performed first, i.e., assignment parses right to left. 1421 1422 1423 \section{Unnamed Structure Fields} 1424 1425 C 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} 1427 struct { 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} 1436 This requirement is relaxed by making the field name optional for all field declarations; therefore, all the field declarations in the example are allowed. 1437 As for unnamed bit fields, an unnamed field is used for padding a structure to a particular size. 1438 A list of unnamed fields is also supported, e.g.: 1439 \begin{lstlisting} 1440 struct { 1441 int , , ; // 3 unnamed fields 1442 } 1443 \end{lstlisting} 1337 1444 1338 1445 … … 1355 1462 double f4; 1356 1463 } v; 1357 v.[ f3, f1, f2 ] = ['x', 11, 17 ]; // equivalent to v.f3 = 'x', v.f1 = 11, v.f2 = 171358 f( v.[ f3, f1, f2 ] ); // equivalent to f( v.f3, v.f1, v.f2 )1464 v.[ f3, f1, f2 ] = ['x', 11, 17 ]; §\C{// equivalent to v.f3 = 'x', v.f1 = 11, v.f2 = 17}§ 1465 f( v.[ f3, f1, f2 ] ); §\C{// equivalent to f( v.f3, v.f1, v.f2 )}§ 1359 1466 \end{lstlisting} 1360 1467 Note, the fields appearing in a record-field tuple may be specified in any order; … … 1376 1483 1377 1484 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 1487 While C provides ©continue© and ©break© statements for altering control flow, both are restricted to one level of nesting for a particular control structure. 1488 Unfortunately, this restriction forces programmers to use ©goto© to achieve the equivalent control-flow for more than one level of nesting. 1489 To 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}. 1490 For both ©continue© and ©break©, the target label must be directly associated with a ©for©, ©while© or ©do© statement; 1491 for ©break©, the target label can also be associated with a ©switch©, ©if© or compound (©{}©) statement. 1492 1493 The following example shows the labelled ©continue© specifying which control structure is the target for the next loop iteration: 1494 \begin{quote2} 1390 1495 \begin{tabular}{@{}l@{\hspace{3em}}l@{}} 1391 1496 \multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}} & \multicolumn{1}{c}{\textbf{C}} \\ 1392 1497 \begin{lstlisting} 1393 ®L1:® for ( ... ){1394 ®L2:® for( ... ) {1498 ®L1:® do { 1499 ®L2:® while ( ... ) { 1395 1500 ®L3:® for ( ... ) { 1396 ... break ®L1®; ...1397 ... break ®L2®; ...1398 ... break ®L3®; // or break1399 } 1400 } 1401 } 1501 ... continue ®L1®; ... // continue do 1502 ... continue ®L2®; ... // continue while 1503 ... continue ®L3®; ... // continue for 1504 } // for 1505 } // while 1506 } while ( ... ); 1402 1507 \end{lstlisting} 1403 1508 & 1404 1509 \begin{lstlisting} 1405 for ( ... ){1406 for( ... ) {1510 do { 1511 while ( ... ) { 1407 1512 for ( ... ) { 1408 1513 ... goto L1; ... 1409 1514 ... goto L2; ... 1410 ... goto L3; // or break 1515 ... goto L3; ... 1516 L3: ; } 1517 L2: ; } 1518 L1: ; } while ( ... ); 1519 \end{lstlisting} 1520 \end{tabular} 1521 \end{quote2} 1522 The innermost loop has three restart points, which cause the next loop iteration to begin. 1523 1524 The 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; ... 1411 1561 } L3: ; 1412 1562 } L2: ; … … 1414 1564 \end{lstlisting} 1415 1565 \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} 1567 The innermost loop has four exit points, which cause termination of one or more of the four \Index{nested control structure}s. 1568 1569 Both ©continue© and ©break© with target labels are simply a ©goto©\index{goto@©goto©!restricted} restricted in the following ways: 1460 1570 \begin{itemize} 1461 1571 \item … … 1464 1574 This restriction is important since all situations that can result in repeated execution of statements in a program are clearly delineated. 1465 1575 \item 1466 Since they always transfer sout of containing control structures, they cannot be used to branch into a control structure.1576 Since they always transfer out of containing control structures, they cannot be used to branch into a control structure. 1467 1577 \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 tiescontrol flow to the target control structure rather than an arbitrary point in a program.1469 Furthermore, the location of the label at the beginningof 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 structurefails 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 otherconstructs.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.1578 The 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. 1579 Furthermore, 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. 1580 With ©goto©, the label is at the end of the control structure, which fails to convey this important clue early enough to the reader. 1581 Finally, using an explicit target for the transfer instead of an implicit target allows new constructs to be added or removed without affecting existing constructs. 1582 The implicit targets of the current ©continue© and ©break©, i.e., the closest enclosing loop or ©switch©, change as certain constructs are added or removed. 1473 1583 1474 1584 … … 1481 1591 In this section, the term \emph{case clause} refers to either a ©case© or ©default© clause.} 1482 1592 \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:1593 to exit a ©switch© statement from a ©case© clause requires explicitly terminating the clause with a transfer statement, most commonly ©break©: 1484 1594 \begin{lstlisting} 1485 1595 switch ( i ) { … … 1492 1602 } 1493 1603 \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:1604 The ability to fall-through to the next clause \emph{is} a useful form of control flow, specifically when a sequence of case actions compound: 1495 1605 \begin{lstlisting} 1496 1606 switch ( argc ) { … … 1507 1617 In this example, case 2 is always done if case 3 is done. 1508 1618 This control flow is difficult to simulate with if statements or a ©switch© statement without fall-through as code must be duplicated or placed in a separate routine. 1509 C also uses fall-through to handle multiple case-values resulting in the same action , as in:1619 C also uses fall-through to handle multiple case-values resulting in the same action: 1510 1620 \begin{lstlisting} 1511 1621 switch ( i ) { … … 1519 1629 \end{lstlisting} 1520 1630 However, 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:1631 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. 1632 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. 1633 1634 \item 1635 It is possible to place ©case© clauses on statements nested \emph{within} the body of the ©switch© statement: 1526 1636 \begin{lstlisting} 1527 1637 switch ( i ) { … … 1581 1691 \begin{lstlisting} 1582 1692 switch ( x ) { 1583 int y = 1; // unreachable initialization1584 x = 7; // unreachable code1693 int y = 1; §\C{// unreachable initialization}§ 1694 x = 7; §\C{// unreachable code}§ 1585 1695 case 3: ... 1586 1696 y = 3; … … 1604 1714 and there is only a medium amount of fall-through from one ©case© clause to the next, and most of these result from a list of case values executing common code, rather than a sequence of case actions that compound. 1605 1715 \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. 1716 These observations help to put the effects of suggested changes into perspective. 1608 1717 \begin{enumerate} 1609 1718 \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.: 1719 Eliminating default fall-through has the greatest potential for affecting existing code. 1720 However, even if fall-through is removed, most ©switch© statements would continue to work because of the explicit transfers already present at the end of each ©case© clause, the common placement of the ©default© clause at the end of the case list, and the most common use of fall-through, i.e., a list of ©case© clauses executing common code, e.g.: 1613 1721 \begin{lstlisting} 1614 1722 case 1: case 2: case 3: ... 1615 1723 \end{lstlisting} 1724 still work. 1616 1725 Nevertheless, reversing the default action would have a non-trivial effect on case actions that compound, such as the above example of processing shell arguments. 1617 1726 Therefore, 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: 1727 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). 1728 It 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}§ 1627 1739 default: 1628 1740 j = 3; 1629 1741 } 1630 1742 \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 choosestatement.1743 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. 1632 1744 \item 1633 1745 Eliminating Duff's device is straightforward and only invalidates a small amount of very questionable code. 1634 1746 The 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. 1635 1747 \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 mayappear is locations other than at the end.1748 The issue of ©default© at locations other than at the end of the cause clause can be solved by using good programming style, and there are a few reasonable situations involving fall-through where the ©default© clause needs to appear is locations other than at the end. 1637 1749 Therefore, no language change is made for this issue. 1638 1750 \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 beforethe transfer to the appropriate ©case© clause.1751 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 \emph{before} the transfer to the appropriate ©case© clause. 1640 1752 This 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 toappear before the first ©case© clause.1753 As well, statements cannot appear before the first ©case© clause. 1642 1754 The change is compatible for declarations with initialization in this context because existing code cannot assume the initialization has occurred. 1643 1755 The change is incompatible for statements, but any existing code using it is highly questionable, as in: 1644 1756 \begin{lstlisting} 1645 1757 switch ( i ) { 1646 L: x = 5; // questionable code1758 L: x = 5; §\C{// questionable code}§ 1647 1759 case 0: 1648 1760 ... … … 1691 1803 \end{tabular} 1692 1804 \end{quote2} 1693 In addition, two forms of subranges are allowed to specify case values: the GNU C form and a new \CFA form. 1805 In addition, two forms of subranges are allowed to specify case values: a new \CFA form and an existing GNU C form.\footnote{ 1806 The GNU C form \emph{requires} spaces around the ellipse.} 1694 1807 \begin{quote2} 1695 1808 \begin{tabular}{@{}l@{\hspace{3em}}l@{\hspace{2em}}l@{}} … … 1723 1836 \end{tabular} 1724 1837 \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 } 1838 Lists of subranges are also allowed. 1839 \begin{lstlisting} 1840 case ®1~5, 12~21, 35~42®: 1747 1841 \end{lstlisting} 1748 1842 … … 4217 4311 \section{Incompatible} 4218 4312 4219 The following incompatibles exist between C and \CFA, and are similar to Annex C for \CC~\cite{ANSI14:C++}.4313 The following incompatibles exist between \CFA and C, and are similar to Annex C for \CC~\cite{ANSI14:C++}. 4220 4314 4221 4315 \begin{enumerate} 4222 4316 \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 \\ 4319 New 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. \\ 4322 Any 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} 4325 int `otype` = 3; // make keyword an indentifier 4326 double `choose` = 3.5; 4327 \end{lstlisting} 4328 Programs can be converted automatically by enclosing keyword identifiers in backquotes, and the backquotes can be remove later when the identifier name is changed. 4329 Clashes 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} 4351 int rtn( int i ); 4352 int rtn( char c ); 4353 rtn( '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. 4356 In particular, output of ©char© variable now print a character rather than the decimal ASCII value of the character. 4357 \begin{lstlisting} 4358 sout | 'x' | " " | (int)'x' | endl; 4359 x 120 4360 \end{lstlisting} 4361 Having 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} 4364 sizeof( 'x' ) == sizeof( int ) 4365 \end{lstlisting} 4366 no 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} 4375 char * p = "abc"; // valid in C, deprecated in §\CFA§ 4376 char * q = expr ? "abc" : "de"; // valid in C, invalid in §\CFA§ 4377 \end{lstlisting} 4378 The type of a string literal is changed from ©[] char© to ©const [] char©. 4379 Similarly, 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} 4382 char * p = "abc"; 4383 p[0] = 'w'; // segment fault or change constant literal 4384 \end{lstlisting} 4385 The 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} 4395 int i; // forward definition 4396 int *j = ®&i®; // forward reference, valid in C, invalid in §\CFA§ 4397 int i = 0; // definition 4398 \end{lstlisting} 4399 is valid in C, and invalid in \CFA because duplicate overloaded object definitions at the same scope level are disallowed. 4400 This change makes it impossible to define mutually referential file-local static objects, if initializers are restricted to the syntactic forms of C. For example, 4263 4401 \begin{lstlisting} 4264 4402 struct 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. 4403 static struct X a; // forward definition 4404 static struct X b = { 0, ®&a® }; // forward reference, valid in C, invalid in §\CFA§ 4405 static 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 4416 In C, the name of the nested types belongs to the same scope as the name of the outermost enclosing 4417 Example: 4418 \begin{lstlisting} 4419 enum ®Colour® { R, G, B, Y, C, M }; 4420 struct 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 4430 Personß.ß®Colour® pc = Personß.ßR; // type/enum defined inside 4431 Personß.ß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. 4282 4437 4283 4438 \CFA is C \emph{incompatible} on this issue, and provides semantics similar to \CC. 4284 4439 Nested types are not hoisted and can be referenced using the field selection operator ``©.©'', unlike the \CC scope-resolution operator ``©::©''. 4285 4440 Given 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: 4301 4448 \begin{lstlisting} 4302 4449 struct Y; // struct Y and struct X are at the same scope … … 4307 4454 All 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. 4308 4455 Note: 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} 4310 4467 \end{enumerate} 4311 4468
Note: See TracChangeset
for help on using the changeset viewer.
