Index: doc/LaTeXmacros/common.tex =================================================================== --- doc/LaTeXmacros/common.tex (revision 99f11dd9fe298c7ab585c6387048bc8797d4dde4) +++ doc/LaTeXmacros/common.tex (revision 4096de0dcc74726f866aecbc8a9e4ef084268699) @@ -11,6 +11,6 @@ %% Created On : Sat Apr 9 10:06:17 2016 %% Last Modified By : Peter A. Buhr -%% Last Modified On : Mon Jun 20 09:35:20 2016 -%% Update Count : 178 +%% Last Modified On : Sun Jul 3 08:36:24 2016 +%% Update Count : 200 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% @@ -27,5 +27,5 @@ \righthyphenmin=4 -\usepackage{pslatex} % reduce size of san serif font +%\usepackage{pslatex} % reduce size of san serif font \usepackage[ignoredisplayed]{enumitem} % do not affect trivlist @@ -36,5 +36,5 @@ \setlist[enumerate]{listparindent=\parindent}% global \setlist[enumerate,2]{leftmargin=\parindent,labelsep=*,align=parleft,label=\alph*.}% local -\setlist[description]{listparindent=\parindent,leftmargin=\parindent,labelsep=*} +\setlist[description]{itemsep=0pt,listparindent=\parindent,leftmargin=\parindent,labelsep=1.5ex} % Names used in the document. @@ -52,4 +52,11 @@ \newlength{\parindentlnth} \setlength{\parindentlnth}{\parindent} + +\newlength{\gcolumnposn} +\newlength{\columnposn} +\setlength{\gcolumnposn}{2.5in} +\setlength{\columnposn}{\gcolumnposn} +\newcommand{\C}[2][\@empty]{\ifx#1\@empty\else\global\setlength{\columnposn}{#1}\global\columnposn=\columnposn\fi\hfill\makebox[\textwidth-\columnposn][l]{\lst@commentstyle{#2}}} +\newcommand{\CRT}{\global\columnposn=\gcolumnposn} % allow escape sequence in lstinline @@ -123,4 +130,7 @@ \newcommand{\indexc}[1]{\index{#1@\lstinline$#1$}} +% Denote newterms in particular font and index them without particular font and in lowercase, e.g., \newterm{abc}. +% The option parameter provides an index term different from the new term, e.g., \newterm[\texttt{abc}]{abc} +% The star version does not lowercase the index information, e.g., \newterm*{IBM}. \newcommand{\newtermFontInline}{\emph} \newcommand{\newterm}{\@ifstar\@snewterm\@newterm} @@ -204,5 +214,5 @@ \lstset{ language=CFA, -columns=flexible, +columns=fullflexible, basicstyle=\linespread{0.9}\sf, stringstyle=\tt, Index: doc/refrat/refrat.tex =================================================================== --- doc/refrat/refrat.tex (revision 99f11dd9fe298c7ab585c6387048bc8797d4dde4) +++ doc/refrat/refrat.tex (revision 4096de0dcc74726f866aecbc8a9e4ef084268699) @@ -11,6 +11,6 @@ %% Created On : Wed Apr 6 14:52:25 2016 %% Last Modified By : Peter A. Buhr -%% Last Modified On : Sat Jun 18 19:21:30 2016 -%% Update Count : 74 +%% Last Modified On : Wed Jun 22 14:18:30 2016 +%% Update Count : 77 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% @@ -49,4 +49,7 @@ \renewcommand{\UrlFont}{\small\sf} +\setlength{\topmargin}{-0.45in} % move running title into header +\setlength{\headsep}{0.25in} + %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% @@ -69,27 +72,30 @@ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -\begin{document} -\pagestyle{headings} -\linenumbers % comment out to turn off line numbering - \title{\Huge \vspace*{1in} \CFA (\CFL) Reference Manual and Rationale }% title + \author{\huge Glen Ditchfield and Peter A. Buhr }% author + \date{ -DRAFT \\ -\today +DRAFT \\ \today }% date +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% + +\begin{document} +\pagestyle{headings} +% changed after setting pagestyle +\renewcommand{\chaptermark}[1]{\markboth{\thechapter\quad #1}{\thechapter\quad #1}} +\renewcommand{\sectionmark}[1]{\markboth{\thesection\quad #1}{\thesection\quad #1}} \pagenumbering{roman} -\pagestyle{plain} +\linenumbers % comment out to turn off line numbering \maketitle - +\thispagestyle{empty} \vspace*{\fill} -\thispagestyle{empty} \noindent \copyright\,2015 Glen Ditchfield \\ \\ Index: doc/user/Cdecl.fig =================================================================== --- doc/user/Cdecl.fig (revision 99f11dd9fe298c7ab585c6387048bc8797d4dde4) +++ doc/user/Cdecl.fig (revision 4096de0dcc74726f866aecbc8a9e4ef084268699) @@ -8,39 +8,4 @@ -2 1200 2 -6 1125 1200 2025 1650 -2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 - 1275 1200 2025 1200 2025 1350 1275 1350 1275 1200 -2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 - 1425 1200 1425 1350 -2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 - 1575 1200 1575 1350 -2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 - 1725 1200 1725 1350 -2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 - 1875 1200 1875 1350 -2 1 0 1 0 7 50 -1 -1 4.000 0 0 -1 1 0 2 - 1 1 1.00 45.00 90.00 - 1350 1275 1350 1500 -2 1 0 1 0 7 50 -1 -1 4.000 0 0 -1 1 0 2 - 1 1 1.00 45.00 90.00 - 1500 1275 1500 1500 -2 1 0 1 0 7 50 -1 -1 4.000 0 0 -1 1 0 2 - 1 1 1.00 45.00 90.00 - 1650 1275 1650 1500 -2 1 0 1 0 7 50 -1 -1 4.000 0 0 -1 1 0 2 - 1 1 1.00 45.00 90.00 - 1800 1275 1800 1500 -2 1 0 1 0 7 50 -1 -1 4.000 0 0 -1 1 0 2 - 1 1 1.00 45.00 90.00 - 1950 1275 1950 1500 -4 1 0 50 -1 4 10 0.0000 2 105 90 1350 1650 0\001 -4 1 0 50 -1 4 10 0.0000 2 105 90 1500 1650 1\001 -4 1 0 50 -1 4 10 0.0000 2 105 90 1650 1650 2\001 -4 1 0 50 -1 4 10 0.0000 2 105 90 1800 1650 3\001 -4 1 0 50 -1 4 10 0.0000 2 105 90 1950 1650 4\001 -4 1 0 50 -1 4 10 0.0000 2 75 75 1200 1325 x\001 --6 -6 2325 1200 3600 1350 -6 2475 1200 3600 1350 6 2850 1200 3600 1350 2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 @@ -54,16 +19,45 @@ 2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 2850 1200 3600 1200 3600 1350 2850 1350 2850 1200 -4 1 0 50 -1 4 10 0.0000 2 105 90 2925 1325 0\001 -4 1 0 50 -1 4 10 0.0000 2 105 90 3075 1325 1\001 -4 1 0 50 -1 4 10 0.0000 2 105 90 3225 1325 2\001 -4 1 0 50 -1 4 10 0.0000 2 105 90 3375 1325 3\001 -4 1 0 50 -1 4 10 0.0000 2 105 90 3525 1325 4\001 +4 1 0 50 -1 4 10 0.0000 2 120 90 2925 1325 0\001 +4 1 0 50 -1 4 10 0.0000 2 120 90 3075 1325 1\001 +4 1 0 50 -1 4 10 0.0000 2 120 90 3225 1325 2\001 +4 1 0 50 -1 4 10 0.0000 2 120 90 3375 1325 3\001 +4 1 0 50 -1 4 10 0.0000 2 120 90 3525 1325 4\001 -6 2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 1275 1200 2025 1200 2025 1350 1275 1350 1275 1200 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 + 1425 1200 1425 1350 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 + 1575 1200 1575 1350 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 + 1725 1200 1725 1350 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 + 1875 1200 1875 1350 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 60.00 + 1950 1275 1950 1500 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 60.00 + 1350 1275 1350 1500 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 60.00 + 1500 1275 1500 1500 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 60.00 + 1650 1275 1650 1500 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 60.00 + 1800 1275 1800 1500 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 2475 1200 2625 1200 2625 1350 2475 1350 2475 1200 -2 1 0 1 0 7 50 -1 -1 4.000 0 0 -1 1 0 2 - 1 1 1.00 45.00 90.00 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 60.00 2550 1275 2850 1275 --6 -4 1 0 50 -1 4 10 0.0000 2 75 75 2400 1325 x\001 --6 +4 1 0 50 -1 4 10 0.0000 2 120 90 1350 1650 0\001 +4 1 0 50 -1 4 10 0.0000 2 120 90 1500 1650 1\001 +4 1 0 50 -1 4 10 0.0000 2 120 90 1650 1650 2\001 +4 1 0 50 -1 4 10 0.0000 2 120 90 1800 1650 3\001 +4 1 0 50 -1 4 10 0.0000 2 120 90 1950 1650 4\001 +4 1 0 50 -1 4 10 0.0000 2 90 90 1200 1325 x\001 +4 1 0 50 -1 4 10 0.0000 2 90 90 2400 1325 x\001 Index: doc/user/Makefile =================================================================== --- doc/user/Makefile (revision 99f11dd9fe298c7ab585c6387048bc8797d4dde4) +++ doc/user/Makefile (revision 4096de0dcc74726f866aecbc8a9e4ef084268699) @@ -13,7 +13,9 @@ FIGURES = ${addsuffix .tex, \ Cdecl \ +pointer1 \ } PICTURES = ${addsuffix .pstex, \ +pointer2 \ } @@ -71,4 +73,8 @@ fig2dev -L ps $< > $@ +%.pstex : %.fig + fig2dev -L pstex $< > $@ + fig2dev -L pstex_t -p $@ $< > $@_t + # Local Variables: # # compile-command: "make" # Index: doc/user/pointer2.fig =================================================================== --- doc/user/pointer2.fig (revision 99f11dd9fe298c7ab585c6387048bc8797d4dde4) +++ doc/user/pointer2.fig (revision 4096de0dcc74726f866aecbc8a9e4ef084268699) @@ -8,28 +8,41 @@ -2 1200 2 -6 2775 1500 4425 2250 +2 1 0 1 4 7 100 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 2550 1800 1800 1950 +2 1 0 1 4 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 2550 1950 1800 1800 2 2 0 1 0 7 100 0 -1 0.000 0 0 -1 0 0 5 - 3150 1950 4050 1950 4050 2250 3150 2250 3150 1950 + 1500 1500 1800 1500 1800 1800 1500 1800 1500 1500 2 2 0 1 0 7 100 0 -1 0.000 0 0 -1 0 0 5 - 3150 1500 4050 1500 4050 1800 3150 1800 3150 1500 -4 2 0 100 0 4 10 0.0000 2 120 270 3075 2250 112\001 -4 2 0 100 0 4 10 0.0000 2 120 270 3075 1800 108\001 -4 2 0 100 0 4 10 0.0000 2 150 180 3075 2075 p2\001 -4 0 0 100 0 4 10 0.0000 2 120 270 4125 2150 int *\001 -4 0 0 100 0 4 10 0.0000 2 120 270 4125 1700 int *\001 -4 2 0 100 0 4 10 0.0000 2 150 180 3075 1625 p1\001 -4 1 0 100 0 4 10 0.0000 2 120 270 3600 2150 100\001 -4 1 0 100 0 4 10 0.0000 2 120 270 3600 1725 104\001 --6 + 1500 1950 1800 1950 1800 2250 1500 2250 1500 1950 2 2 0 1 0 7 100 0 -1 0.000 0 0 -1 0 0 5 - 1500 1950 2400 1950 2400 2250 1500 2250 1500 1950 + 2550 1500 2850 1500 2850 1800 2550 1800 2550 1500 2 2 0 1 0 7 100 0 -1 0.000 0 0 -1 0 0 5 - 1500 1500 2400 1500 2400 1800 1500 1800 1500 1500 -4 1 0 100 0 4 10 0.0000 2 120 90 1950 1700 3\001 -4 1 0 100 0 4 10 0.0000 2 120 90 1950 2150 3\001 + 2550 1950 2850 1950 2850 2250 2550 2250 2550 1950 +2 1 0 1 4 7 100 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 90.00 + 3600 1800 2850 1950 +2 2 0 1 0 7 100 0 -1 0.000 0 0 -1 0 0 5 + 3600 1500 3900 1500 3900 1800 3600 1800 3600 1500 4 2 0 100 0 4 10 0.0000 2 120 270 1425 2250 104\001 4 2 0 100 0 4 10 0.0000 2 120 270 1425 1800 100\001 4 2 0 100 0 4 10 0.0000 2 90 90 1425 1625 x\001 4 2 0 100 0 4 10 0.0000 2 120 90 1425 2075 y\001 -4 0 0 100 0 4 10 0.0000 2 120 165 2475 2150 int\001 -4 0 0 100 0 4 10 0.0000 2 120 165 2475 1700 int\001 +4 1 0 100 0 4 10 0.0000 2 120 90 1650 1700 3\001 +4 1 0 100 0 4 10 0.0000 2 120 90 1650 2150 3\001 +4 0 0 100 0 4 10 0.0000 2 120 165 1875 2150 int\001 +4 0 0 100 0 4 10 0.0000 2 120 165 1875 1700 int\001 +4 2 0 100 0 4 10 0.0000 2 120 270 2475 2250 112\001 +4 2 0 100 0 4 10 0.0000 2 150 180 2475 2075 p2\001 +4 2 0 100 0 4 10 0.0000 2 120 270 2475 1800 108\001 +4 2 0 100 0 4 10 0.0000 2 150 180 2475 1625 p1\001 +4 1 0 100 0 4 10 0.0000 2 120 270 2700 1700 104\001 +4 1 0 100 0 4 10 0.0000 2 120 270 2700 2150 100\001 +4 0 0 100 0 4 10 0.0000 2 120 270 2925 2150 int *\001 +4 0 0 100 0 4 10 0.0000 2 120 270 2925 1700 int *\001 +4 2 0 100 0 4 10 0.0000 2 120 270 3525 1800 116\001 +4 2 0 100 0 4 10 0.0000 2 150 180 3525 1625 p3\001 +4 1 0 100 0 4 10 0.0000 2 120 270 3750 1700 112\001 +4 0 0 100 0 4 10 0.0000 2 120 330 3975 1700 int **\001 Index: doc/user/user.tex =================================================================== --- doc/user/user.tex (revision 99f11dd9fe298c7ab585c6387048bc8797d4dde4) +++ doc/user/user.tex (revision 4096de0dcc74726f866aecbc8a9e4ef084268699) @@ -11,6 +11,6 @@ %% Created On : Wed Apr 6 14:53:29 2016 %% Last Modified By : Peter A. Buhr -%% Last Modified On : Mon Jun 20 10:47:22 2016 -%% Update Count : 575 +%% Last Modified On : Wed Jul 6 21:08:24 2016 +%% Update Count : 1070 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% @@ -36,5 +36,7 @@ \usepackage{epic,eepic} \usepackage{upquote} % switch curled `'" to straight +\usepackage{calc} \usepackage{xspace} +\usepackage{graphicx} \usepackage{varioref} % extended references \usepackage{listings} % format program code @@ -50,14 +52,6 @@ \renewcommand{\UrlFont}{\small\sf} -\makeatletter -\renewcommand{\pagestyle}[1]{ - \@ifundefined{ps@#1}% - \undefinedpagestyle - {\def\@tempa{#1}\def\@tempb{headings}\def\@tempc{myheadings}% - \ifx\@tempa\@tempb\setlength{\topmargin}{-0.25in}\setlength{\headsep}{0.25in}% - \else\ifx\@tempa\@tempc\setlength{\topmargin}{-0.25in}\setlength{\headsep}{0.25in}\fi\fi% - \@nameuse{ps@#1}}}% pagestyle -\makeatother - +\setlength{\topmargin}{-0.45in} % move running title into header +\setlength{\headsep}{0.25in} %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% @@ -105,11 +99,13 @@ \begin{document} \pagestyle{headings} +% changed after setting pagestyle +\renewcommand{\sectionmark}[1]{\markboth{\thesection\quad #1}{\thesection\quad #1}} +\renewcommand{\subsectionmark}[1]{\markboth{\thesubsection\quad #1}{\thesubsection\quad #1}} \pagenumbering{roman} \linenumbers % comment out to turn off line numbering \maketitle - +\thispagestyle{empty} \vspace*{\fill} -\thispagestyle{empty} \noindent \copyright\,2016 \CFA Project \\ \\ @@ -120,9 +116,10 @@ \clearpage +\thispagestyle{plain} \pdfbookmark[1]{Contents}{section} \tableofcontents \clearpage -\markright{\CFA User Manual} +\thispagestyle{plain} \pagenumbering{arabic} @@ -306,7 +303,7 @@ \begin{lstlisting} #ifndef __CFORALL__ -#include // C header file +#include §\C{// C header file}§ #else -#include // §\CFA{}§ header file +#include §\C{// \CFA header file}§ #endif \end{lstlisting} @@ -318,14 +315,14 @@ Numeric constants are extended to allow \Index{underscore}s within constants\index{constant!underscore}, e.g.: \begin{lstlisting} -2®_®147®_®483®_®648; // decimal constant -56_ul; // decimal unsigned long constant -0_377; // octal constant -0x_ff_ff; // hexadecimal constant -0x_ef3d_aa5c; // hexadecimal constant -3.141_592_654; // floating point constant -10_e_+1_00; // floating point constant -0x_ff_ff_p_3; // hexadecimal floating point -0x_1.ffff_ffff_p_128_l; // hexadecimal floating point long constant -L_"\x_ff_ee"; // wide character constant +2®_®147®_®483®_®648; §\C{// decimal constant}§ +56_ul; §\C{// decimal unsigned long constant}§ +0_377; §\C{// octal constant}§ +0x_ff_ff; §\C{// hexadecimal constant}§ +0x_ef3d_aa5c; §\C{// hexadecimal constant}§ +3.141_592_654; §\C{// floating point constant}§ +10_e_+1_00; §\C{// floating point constant}§ +0x_ff_ff_p_3; §\C{// hexadecimal floating point}§ +0x_1.ffff_ffff_p_128_l; §\C{// hexadecimal floating point long constant}§ +L_"\x_ff_ee"; §\C{// wide character constant}§ \end{lstlisting} The rules for placement of underscores is as follows: @@ -363,17 +360,18 @@ \end{quote2} Is this an array of 5 pointers to integers or a pointer to an array of 5 integers? +The fact this declaration is unclear to many C programmers means there are \Index{productivity} and \Index{safety} issues even for basic programs. 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. For example, a routine returning a pointer to an array of integers is defined and used in the following way: \begin{lstlisting} -int (*f())[5] {...}; // definition mimics usage +int (*f())[5] {...}; §\C{}§ ... (*f())[3] += 1; \end{lstlisting} Essentially, the return type is wrapped around the routine name in successive layers (like an onion). -While attempting to make the two contexts consistent was a laudable goal, it has not worked out in practice. +While attempting to make the two contexts consistent is a laudable goal, it has not worked out in practice. \CFA provides its own type, variable and routine declarations, using a different syntax. The new declarations place qualifiers to the left of the base type, while C declarations place qualifiers to the right of the base type. In the following example, \R{red} is for the base type and \B{blue} is for the qualifiers. -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. +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. \begin{quote2} \begin{tabular}{@{}l@{\hspace{3em}}l@{}} @@ -408,4 +406,20 @@ \end{tabular} \end{quote2} +The downside of this semantics is the need to separate regular and pointer declarations: +\begin{quote2} +\begin{tabular}{@{}l@{\hspace{3em}}l@{}} +\multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}} & \multicolumn{1}{c}{\textbf{C}} \\ +\begin{lstlisting} +®*® int x; +int y; +\end{lstlisting} +& +\begin{lstlisting} +int ®*®x, y; + +\end{lstlisting} +\end{tabular} +\end{quote2} +which is \Index{prescribing} a safety benefit. Other examples are: \begin{quote2} @@ -493,8 +507,8 @@ e.g.: \begin{lstlisting} -x; // int x -*y; // int *y -f( p1, p2 ); // int f( int p1, int p2 ); -f( p1, p2 ) {} // int f( int p1, int p2 ) {} +x; §\C{// int x}§ +*y; §\C{// int *y}§ +f( p1, p2 ); §\C{// int f( int p1, int p2 );}§ +f( p1, p2 ) {} §\C{// int f( int p1, int p2 ) {}}§ \end{lstlisting} @@ -504,154 +518,224 @@ -\section{Reference Pointers} +\section{Pointer / Reference} + +C provides a \newterm{pointer type}; +\CFA adds a \newterm{reference type}. +Both types contain an \newterm{address}, which is normally a location in memory. +Special addresses are used to denote certain states or access co-processor memory. +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. +Often dereferencing a special state causes a memory fault, so checking is necessary during execution. +If the programming language assigns addresses, a program's execution is \Index{sound}, i.e., all addresses are to valid memory locations. +C allows programmers to assign addresses, so there is the potential for incorrect addresses, both inside and outside of the computer address-space. Program variables are implicit pointers to memory locations generated by the compiler and automatically dereferenced, as in: \begin{quote2} -\begin{tabular}{@{}l|l@{}} -\multicolumn{1}{c|}{Variables} & \multicolumn{1}{c}{Compiler generated addresses (100, 104) and dereferencing} \\ -\hline -\begin{lstlisting} -int x, y; +\begin{tabular}{@{}lll@{}} +\begin{lstlisting} +int x; x = 3; +int y; y = x; \end{lstlisting} & -\begin{lstlisting} -int * const x = (int *)100, * const y = (int *)104; -*x = 3; // implicit dereference -*y = *x; +\raisebox{-0.45\totalheight}{\input{pointer1}} +& +\begin{lstlisting} +int * const x = (int *)100 +*x = 3; // implicit dereference +int * const y = (int *)104; +*y = *x; // implicit dereference \end{lstlisting} \end{tabular} \end{quote2} -A variable name only points to one location during its lifetime, i.e., it is a \Index{non-mutable} pointer. -For example, the variables ©x© and ©y© are constant pointers. -Variable addresses are usually not stored in memory and loaded before dereferencing; -instead, variable addresses are stored in instructions, so an instruction fetch implicitly gets the variable's address. +where the right example is how the compiler logically interpreters variables. +Since a variable name only points to one location during its lifetime, it is a \Index{immutable} pointer; +hence, variables ©x© and ©y© are constant pointers in the compiler interpretation. +In general, variable addresses are stored in instructions instead of loaded independently, so an instruction fetch implicitly loads a variable's address. \begin{quote2} \begin{tabular}{@{}l|l@{}} \begin{lstlisting} -x = x + 1 -&x = *(&x) + 1 -(100) = *(100) + 1 +lda r1,100 // load address of x +ld r2,(r1) // load value of x +lda r3,104 // load address of y +st r2,(r3) // store x into y \end{lstlisting} & \begin{lstlisting} -ld r1,(100) // address of x -add r1,1 -st r1,(100) // address of x + +ld r2,(100) // load value of x + +st r2,(104) // store x into y \end{lstlisting} \end{tabular} \end{quote2} -Finally, the non-mutable nature of variables and the fact that there is no storage for a variable address means pointer assignment is impossible. -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. - -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). +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. +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. + +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. +(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.) Hence, a pointer occupies memory to store its current address, and the pointer's value is loaded by dereferencing, e.g.: -\begin{lstlisting} -int x, y, z, ®*® p1, ®*® p2; -p1 = ®&®x; // p1 points to x -p2 = p1; // p2 also points to x -p1 = ®&®y; // p1 points to y -p2 = p1 + 1; // p2 points to z, pointer arithmetic -\end{lstlisting} -In many cases, a pointer name is anonymous (dynamically computed), so it cannot be stored directly in an instruction like a variable name. - -Pointers have a duality: an address in memory or the value at that address. -In many cases, the compiler can infer which of these operations are needed: -\begin{lstlisting} -p2 = p1 + x; // compiler infers *p2 = *p1 + x; -\end{lstlisting} -because adding the integer value of ©x© to the address of ©p1© and storing the resulting address into ©p2© is an unlikely operation. +\begin{quote2} +\begin{tabular}{@{}ll@{}} +\begin{lstlisting} +int x, y, ®*® p1, ®*® p2, ®**® p3; +p1 = ®&®x; // p1 points to x +p2 = p1; // p2 also points to x +p1 = ®&®y; // p1 points to y +p1 = p2 + 1; // p1 points to y, pointer arithmetic +p3 = &p2; // p3 points to p2 +\end{lstlisting} +& +\raisebox{-0.45\totalheight}{\input{pointer2.pstex_t}} +\end{tabular} +\end{quote2} + +Notice, an address has a duality\index{address!duality}: a location in memory or the value at that location. +In many cases, the compiler can infer the meaning: +\begin{lstlisting} +p2 = p1 + x; §\C{// compiler infers *p2 = *p1 + x;}§ +\end{lstlisting} +because adding the arbitrary integer value in ©x© to the address of ©p1© and storing the resulting address into ©p2© is an unlikely operation. Algol68~\cite{Algol68} inferences pointer dereferencing to select the best meaning for each pointer usage. -However, there are ambiguous cases, especially when pointer arithmetic is possible, as in C: -\begin{lstlisting} -p1 = p2; // p1 = p2 or *p1 = *p2 -p1 = p1 + 1; // p1 = p1 + 1 or *p1 = *p1 + 1 -\end{lstlisting} - -Most programming languages pick a default operation and supply an explicit operation to resolve the pointer-duality ambiguity. -In C, the default operation for pointers is manipulate the pointer value and the pointed-to value is explicitly accessed by dereferencing ©*©. -\begin{lstlisting} -p1 = p2; // pointer value assignment -*p1 = *p1 + 1; // pointed-to value assignment/operation -\end{lstlisting} -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. - -However, in the majority of pointer usages, the pointed-to value is required rather than the pointer address. -\begin{lstlisting} -*p2 = ((*p1 + *p2) * (*p2 - *p1)) / (*p1 - *p2); -\end{lstlisting} -And, it is tedious and error prone to explicitly write the dereferencing, especially when pointer arithmetic with integer values is allowed. -It is better to have the compiler generate the dereferencing: -\begin{lstlisting} -p2 = ((p1 + p2) * (p2 - p1)) / (p1 - p2); -\end{lstlisting} - -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. -\begin{lstlisting} -int x, y, z, ®&® r1, ®&® r2; // & denotes reference pointer -r1 ®:=® &x; // r1 points to x -r2 ®:=® &r1; // r2 also points to x -r1 ®:=® &y; // r1 points to y -r2 ®:=® &r1 + 1; // r2 points to z -r2 = ((r1 + r2) * (r2 - r1)) / (r1 - r2); // implicit dereferencing -\end{lstlisting} -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. -Notice, the explicit operator ©:=© to denote pointer assignment to a reference pointer to support both aspects of pointer duality. -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. - -Like pointers, it is possible to use ©const© qualifiers with a reference: -\begin{lstlisting} -const int cx = 5; // cannot change cx; -const int & r3 = &cx; // cannot change what r3 is pointing to -r3 ®:=® &cx; // can change r3 -r3 = 7; // error, cannot change cx -int & const r4 = &x; // must be initialized, §\CC§ reference -r4 ®:=® &x; // error, cannot change r4 -const int & const r5 = &cx; // must be initialized, §\CC§ reference -r5 = 7; // error, cannot change cx -r5 ®:=® &cx; // error, cannot change r5 -\end{lstlisting} -Note, for type ©& const©, there is no pointer assignment, so ©r4 := &x© is disallowed, and the pointer value cannot be ©0©. -Since there is only one meaning for ©r4 = x©, which is to change the value of the variable pointed to by ©r4©, therefore: -\begin{itemize} -\item -it in impossible to take the address of ©r4© as it always means the address of what ©r4© is pointing to. -\item -the dereference at initialization is optional because there can only be one -\begin{lrbox}{\LstBox}% -\footnotesize% -\begin{lstlisting}% +However, there are ambiguous cases, especially when \Index{pointer arithmetic} is possible, as in C: +\begin{lstlisting} +p1 = p2; §\C{// p1 = p2 or *p1 = *p2}§ +p1 = p1 + 1; §\C{// p1 = p1 + 1 or *p1 = *p1 + 1}§ +\end{lstlisting} + +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}. +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 ©*©. +\begin{lstlisting} +p1 = p2; §\C{// pointer address assignment}§ +*p1 = *p1 + 1; §\C{// pointed-to value assignment / operation}§ +\end{lstlisting} +which works well for situations where manipulation of addresses in the primary meaning and data is rarely accessed, such as storage management (©malloc©/©free©). + +However, in most other situations, the pointed-to value is requested more often than the pointer address. +\begin{lstlisting} +*p2 = ((*p1 + *p2) * (**p3 - *p1)) / (**p3 - 15); +\end{lstlisting} +In this case, it is tedious to explicitly write the dereferencing, and error prone when pointer arithmetic is allowed. +It is better to have the compiler generate the dereferencing and have no implicit pointer arithmetic: +\begin{lstlisting} +p2 = ((p1 + p2) * (p3 - p1)) / (p3 - 15); +\end{lstlisting} + +To switch the default meaning for an address requires a new kind of pointer, called a \newterm{reference} and denoted by ©&©. +\begin{lstlisting} +int x, y, ®&® r1, ®&® r2, ®&&® r3; +®&®r1 = &x; §\C{// r1 points to x}§ +®&®r2 = &r1; §\C{// r2 also points to x}§ +®&®r1 = &y; §\C{// r2 also points to x}§ +®&®r1 = &r2 + 1; §\C{// r1 points to y, pointer arithmetic}§ +®&®r3 = ®&®&r2; §\C{// r3 points to r2}§ +r2 = ((r1 + r2) * (r3 - r1)) / (r3 - 15); §\C{// implicit dereferencing}§ +\end{lstlisting} +Except for auto-dereferencing by the compiler, this reference example is the same as the pointer example. +Hence, a reference behaves like the variable name for the current variable it is pointing-to. +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.: +\begin{lstlisting} +r2 = ((r1 + r2) * (r3 - r1)) / (r3 - 15); +\end{lstlisting} +is rewritten as: +\begin{lstlisting} +®*®r2 = ((®*®r1 + ®*®r2) ®*® (®**®r3 - ®*®r1)) / (®**®r3 - 15); +\end{lstlisting} +When a reference appears beside a dereference, e.g., ©&*©, they cancel out.\footnote{ +The unary ©&© operator yields the address of its operand. +If the operand has type ``type'', the result has type ``pointer to type''. +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}} +Hence, assigning to a reference requires the address of the reference variable (\Index{lvalue}): +\begin{lstlisting} +(&®*®)r1 = &x; §\C{// (\&*) cancel out giving variable r1 not the variable pointed-to by r1}§ +\end{lstlisting} +Similarly, the address of a reference can be obtained for assignment or computation (\Index{rvalue}): +\begin{lstlisting} +(&®*®)r3 = &(&®*®)r2; §\C{// (\&*) cancel out giving the address of variable r2}§ +\end{lstlisting} +\Index{Cancellation}\index{pointer!cancellation rule} works to arbitrary depth, and pointer and reference values are interchangeable because both contain addresses. +\begin{lstlisting} +int x, *p1 = &x, **p2 = &p1, ***p3 = &p2, + &r1 = &x, &&r2 = &&r1, &&&r3 = &&r2; +***p3 = 3; §\C{// change x}§ +r3 = 3; §\C{// change x, ***r3}§ +**p3 = ...; §\C{// change p1}§ +&r3 = ...; §\C{// change r1, (\&*)**r3, 1 cancellation}§ +*p3 = ...; §\C{// change p2}§ +&&r3 = ...; §\C{// change r2, (\&(\&*)*)*r3, 2 cancellations}§ +&&&r3 = p3; §\C{// change r3 to p3, (\&(\&(\&*)*)*)r3, 3 cancellations}§ +\end{lstlisting} +Finally, implicit dereferencing and cancellation are a static (compilation) phenomenon not a dynamic one. +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. +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; +otherwise, everything else is equal. + +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. +Java deals with the address duality by making address assignment the default and providing a \Index{clone} mechanism to change the pointed-to value. + +As for pointers, references may have qualifiers: +\begin{lstlisting} +const int cx = 5; §\C{// cannot change cx;}§ +const int & r3 = &cx; §\C{// cannot change what r3 is pointing to}§ +®&®r3 = &cx; §\C{// can change r3}§ +r3 = 7; §\C{// error, cannot change cx}§ +int & const r4 = &x; §\C{// must be initialized, \CC reference}§ +®&®r4 = &x; §\C{// error, cannot change r4}§ +const int & const r5 = &cx; §\C{// must be initialized, \CC reference}§ +r5 = 7; §\C{// error, cannot change cx}§ +®&®r5 = &cx; §\C{// error, cannot change r5}§ +\end{lstlisting} +Hence, for type ©& const©, there is no pointer assignment, so ©&r4 = &x© is disallowed, and \emph{the address value cannot be ©0©}. +in effect, the compiler is managing the addresses not the programmer. + +\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. +There are three initialization contexts in \CFA: declaration initialization, argument/parameter binding, return/temporary binding. +For reference (like pointer) initialization, the initializing value must be an address (lvalue) not a value (rvalue). +\begin{lstlisting} +int * p = &x; §\C{// both \&x and x are possible interpretations}§ +int & r = x; §\C{// x unlikely interpretation, because of auto-dereferencing}§ +\end{lstlisting} +Hence, the compiler implicitly inserts a reference, ©&©, before the initialization expression: +Similarly, when a reference is used for a parameter/return type, the call-site argument does not require a reference. +\begin{lstlisting} +int & f( int & ri ); §\C{// reference parameter and return}§ +z = f( x ) + f( y ); §\C{// reference not required}§ +\end{lstlisting} +Within routine ©f©, it is possible to change the argument by changing the corresponding parameter, and parameter ©ri© can be locally reassigned within ©f©. +The return reference from ©f© is copied into a compiler generated temporary, which is logically treated as an initialization. + +When a pointer/reference parameter has a ©const© value (immutable), it is possible to pass literals and expressions. +\begin{lstlisting} +void f( const int & cri ); +void g( const int * cri ); +f( 3 ); g( &3 ); +f( x + y ); g( &(x + y) ); +\end{lstlisting} +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. +(The ©&© is necessary for the pointer parameter to make the types match, and is common for a C programmer.) +\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. +Essentially, there is an implicit rvalue to lvalue conversion in this case.\footnote{ +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.} +The implicit conversion allows seamless calls to any routine without having to explicit name/copy the literal/expression to allow the call. + +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). +\begin{lstlisting} void f( int p ) {...} -void (*fp)( int ) = &f; // equivalent initialization -void (*fp)( int ) = f; // missing dereference allowed -\end{lstlisting}% -\end{lrbox}% -meaning.\footnote{ -This case is similar to initializing a routine pointer, where the routine constant should be dereferenced. -\newline -\usebox{\LstBox} -}% footnote -\begin{lstlisting} -int & const r4 = &x; // equivalent initialization -int & const r4 = x; // missing dereference allowed -\end{lstlisting} -\end{itemize} -Similarly, when a ©const© reference is used for a parameters type, the call-site argument does not require a reference. -\begin{lstlisting} -void f( int & ri, int & const cri ); -f( &x, x ); // reference not required for second argument -\end{lstlisting} -Within routine ©f©, it is possible to change an argument by changing the corresponding parameter, and parameter ©ri© can be locally reassigned within ©f©. - -Finally, when a reference parameter has a ©const© value, it is possible to pass literals and expressions. -\begin{lstlisting} -void g( const int & ri, const int & const cri ); -f( &3, 3 ); -f( &(x + y), x + y ); -\end{lstlisting} -At the call site, the compiler implicitly creates the necessary temporary that is subsequently pointed to by the reference parameter. -Hence, changing the parameter only changes the temporary at the call site. -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. +void (*fp)( int ) = &f; §\C{// pointer initialization}§ +void (*fp)( int ) = f; §\C{// reference initialization}§ +(*fp)(3); §\C{// pointer invocation}§ +fp(3); §\C{// reference invocation}§ +\end{lstlisting} +A routine variable is best described by a ©const© reference: +\begin{lstlisting} +const void (&fp)( int ) = f; +fp( 3 ); +fp = ... §\C{// change code not allowed}§ +&fp = ...; §\C{// change routine refernce allowed}§ +\end{lstlisting} +because the value of the routine variable is a routine literal, i.e., the routine code is normally immutable during execution.\footnote{ +Dynamic code rewriting is possible but only in special circumstances.} +\CFA allows this additional use of references for routine variables in an attempt to give a more consistent meaning for routine variables. + \section{Type Operators} @@ -696,6 +780,6 @@ 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: \begin{lstlisting} -[§\,§] g(); // no input or output parameters -[ void ] g( void ); // no input or output parameters +[§\,§] g(); §\C{// no input or output parameters}§ +[ void ] g( void ); §\C{// no input or output parameters}§ \end{lstlisting} @@ -715,5 +799,5 @@ \begin{lstlisting} typedef int foo; -int f( int (* foo) ); // foo is redefined as a parameter name +int f( int (* foo) ); §\C{// foo is redefined as a parameter name}§ \end{lstlisting} 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,12 +807,12 @@ C-style declarations can be used to declare parameters for \CFA style routine definitions, e.g.: \begin{lstlisting} -[ int ] f( * int, int * ); // returns an integer, accepts 2 pointers to integers -[ * int, int * ] f( int ); // returns 2 pointers to integers, accepts an integer +[ int ] f( * int, int * ); §\C{// returns an integer, accepts 2 pointers to integers}§ +[ * int, int * ] f( int ); §\C{// returns 2 pointers to integers, accepts an integer}§ \end{lstlisting} 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: \begin{lstlisting} #define ptoa( n, d ) int (*n)[ d ] -int f( ptoa( p, 5 ) ) ... // expands to int f( int (*p)[ 5 ] ) -[ int ] f( ptoa( p, 5 ) ) ... // expands to [ int ] f( int (*p)[ 5 ] ) +int f( ptoa( p, 5 ) ) ... §\C{// expands to int f( int (*p)[ 5 ] )}§ +[ int ] f( ptoa( p, 5 ) ) ... §\C{// expands to [ int ] f( int (*p)[ 5 ] )}§ \end{lstlisting} Again, programmers are highly encouraged to use one declaration form or the other, rather than mixing the forms. @@ -752,5 +836,5 @@ int z; ... x = 0; ... y = z; ... - ®return;® // implicitly return x, y + ®return;® §\C{// implicitly return x, y}§ } \end{lstlisting} @@ -762,5 +846,5 @@ [ int x, int y ] f() { ... -} // implicitly return x, y +} §\C{// implicitly return x, y}§ \end{lstlisting} 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,8 +856,8 @@ as well, parameter names are optional, e.g.: \begin{lstlisting} -[ int x ] f (); // returning int with no parameters -[ * int ] g (int y); // returning pointer to int with int parameter -[ ] h (int,char); // returning no result with int and char parameters -[ * int,int ] j (int); // returning pointer to int and int, with int parameter +[ int x ] f (); §\C{// returning int with no parameters}§ +[ * int ] g (int y); §\C{// returning pointer to int with int parameter}§ +[ ] h (int,char); §\C{// returning no result with int and char parameters}§ +[ * int,int ] j (int); §\C{// returning pointer to int and int, with int parameter}§ \end{lstlisting} This syntax allows a prototype declaration to be created by cutting and pasting source text from the routine definition header (or vice versa). @@ -802,13 +886,13 @@ The syntax for pointers to \CFA routines specifies the pointer name on the right, e.g.: \begin{lstlisting} -* [ int x ] () fp; // pointer to routine returning int with no parameters -* [ * int ] (int y) gp; // pointer to routine returning pointer to int with int parameter -* [ ] (int,char) hp; // pointer to routine returning no result with int and char parameters -* [ * int,int ] (int) jp; // pointer to routine returning pointer to int and int, with int parameter +* [ int x ] () fp; §\C{// pointer to routine returning int with no parameters}§ +* [ * int ] (int y) gp; §\C{// pointer to routine returning pointer to int with int parameter}§ +* [ ] (int,char) hp; §\C{// pointer to routine returning no result with int and char parameters}§ +* [ * int,int ] (int) jp; §\C{// pointer to routine returning pointer to int and int, with int parameter}§ \end{lstlisting} While parameter names are optional, \emph{a routine name cannot be specified}; for example, the following is incorrect: \begin{lstlisting} -* [ int x ] f () fp; // routine name "f" is not allowed +* [ int x ] f () fp; §\C{// routine name "f" is not allowed}§ \end{lstlisting} @@ -833,5 +917,5 @@ whereas a named (keyword) call may be: \begin{lstlisting} -p( z : 3, x : 4, y : 7 ); // rewrite $\Rightarrow$ p( 4, 7, 3 ) +p( z : 3, x : 4, y : 7 ); §\C{// rewrite $\Rightarrow$ p( 4, 7, 3 )}§ \end{lstlisting} 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,9 +934,9 @@ For example, the following routine prototypes and definition are all valid. \begin{lstlisting} -void p( int, int, int ); // equivalent prototypes +void p( int, int, int ); §\C{// equivalent prototypes}§ void p( int x, int y, int z ); void p( int y, int x, int z ); void p( int z, int y, int x ); -void p( int q, int r, int s ) {} // match with this definition +void p( int q, int r, int s ) {} §\C{// match with this definition}§ \end{lstlisting} Forcing matching parameter names in routine prototypes with corresponding routine definitions is possible, but goes against a strong tradition in C programming. @@ -869,16 +953,16 @@ the allowable positional calls are: \begin{lstlisting} -p(); // rewrite $\Rightarrow$ p( 1, 2, 3 ) -p( 4 ); // rewrite $\Rightarrow$ p( 4, 2, 3 ) -p( 4, 4 ); // rewrite $\Rightarrow$ p( 4, 4, 3 ) -p( 4, 4, 4 ); // rewrite $\Rightarrow$ p( 4, 4, 4 ) +p(); §\C{// rewrite $\Rightarrow$ p( 1, 2, 3 )}§ +p( 4 ); §\C{// rewrite $\Rightarrow$ p( 4, 2, 3 )}§ +p( 4, 4 ); §\C{// rewrite $\Rightarrow$ p( 4, 4, 3 )}§ +p( 4, 4, 4 ); §\C{// rewrite $\Rightarrow$ p( 4, 4, 4 )}§ // empty arguments -p( , 4, 4 ); // rewrite $\Rightarrow$ p( 1, 4, 4 ) -p( 4, , 4 ); // rewrite $\Rightarrow$ p( 4, 2, 4 ) -p( 4, 4, ); // rewrite $\Rightarrow$ p( 4, 4, 3 ) -p( 4, , ); // rewrite $\Rightarrow$ p( 4, 2, 3 ) -p( , 4, ); // rewrite $\Rightarrow$ p( 1, 4, 3 ) -p( , , 4 ); // rewrite $\Rightarrow$ p( 1, 2, 4 ) -p( , , ); // rewrite $\Rightarrow$ p( 1, 2, 3 ) +p( , 4, 4 ); §\C{// rewrite $\Rightarrow$ p( 1, 4, 4 )}§ +p( 4, , 4 ); §\C{// rewrite $\Rightarrow$ p( 4, 2, 4 )}§ +p( 4, 4, ); §\C{// rewrite $\Rightarrow$ p( 4, 4, 3 )}§ +p( 4, , ); §\C{// rewrite $\Rightarrow$ p( 4, 2, 3 )}§ +p( , 4, ); §\C{// rewrite $\Rightarrow$ p( 1, 4, 3 )}§ +p( , , 4 ); §\C{// rewrite $\Rightarrow$ p( 1, 2, 4 )}§ +p( , , ); §\C{// rewrite $\Rightarrow$ p( 1, 2, 3 )}§ \end{lstlisting} Here the missing arguments are inserted from the default values in the parameter list. @@ -904,7 +988,7 @@ Default values may only appear in a prototype versus definition context: \begin{lstlisting} -void p( int x, int y = 2, int z = 3 ); // prototype: allowed -void p( int, int = 2, int = 3 ); // prototype: allowed -void p( int x, int y = 2, int z = 3 ) {} // definition: not allowed +void p( int x, int y = 2, int z = 3 ); §\C{// prototype: allowed}§ +void p( int, int = 2, int = 3 ); §\C{// prototype: allowed}§ +void p( int x, int y = 2, int z = 3 ) {} §\C{// definition: not allowed}§ \end{lstlisting} The reason for this restriction is to allow separate compilation. @@ -921,6 +1005,6 @@ \begin{lstlisting} p( int x, int y, int z, . . . ); -p( 1, 4, 5, 6, z : 3, y : 2 ); // assume p( /* positional */, . . ., /* named */ ); -p( 1, z : 3, y : 2, 4, 5, 6 ); // assume p( /* positional */, /* named */, . . . ); +p( 1, 4, 5, 6, z : 3, y : 2 ); §\C{// assume p( /* positional */, . . ., /* named */ );}§ +p( 1, z : 3, y : 2, 4, 5, 6 ); §\C{// assume p( /* positional */, /* named */, . . . );}§ \end{lstlisting} 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,6 +1015,6 @@ \begin{lstlisting} void p( int x, int y = 2, int z = 3. . . ); -p( 1, 4, 5, 6, z : 3 ); // assume p( /* positional */, . . ., /* named */ ); -p( 1, z : 3, 4, 5, 6 ); // assume p( /* positional */, /* named */, . . . ); +p( 1, 4, 5, 6, z : 3 ); §\C{// assume p( /* positional */, . . ., /* named */ );}§ +p( 1, z : 3, 4, 5, 6 ); §\C{// assume p( /* positional */, /* named */, . . . );}§ \end{lstlisting} The first call is an error because arguments 4 and 5 are actually positional not ellipse arguments; @@ -962,5 +1046,5 @@ Furthermore, overloading cannot handle accessing default arguments in the middle of a positional list, via a missing argument, such as: \begin{lstlisting} -p( 1, /* default */, 5 ); // rewrite $\Rightarrow$ p( 1, 2, 5 ) +p( 1, /* default */, 5 ); §\C{// rewrite $\Rightarrow$ p( 1, 2, 5 )}§ \end{lstlisting} @@ -1058,9 +1142,9 @@ const unsigned int size = 5; int ia[size]; -... // assign values to array ia -qsort( ia, size ); // sort ascending order using builtin ? y; }® // nested routine - qsort( ia, size ); // sort descending order by local redefinition + ®int ? y; }® §\C{// nested routine}§ + qsort( ia, size ); §\C{// sort descending order by local redefinition}§ } \end{lstlisting} @@ -1070,14 +1154,14 @@ The following program in undefined in \CFA (and ©gcc©\index{gcc}) \begin{lstlisting} -[* [int]( int )] foo() { // int (*foo())( int ) +[* [int]( int )] foo() { §\C{// int (*foo())( int )}§ int ®i® = 7; int bar( int p ) { - ®i® += 1; // dependent on local variable + ®i® += 1; §\C{// dependent on local variable}§ sout | ®i® | endl; } - return bar; // undefined because of local dependence + return bar; §\C{// undefined because of local dependence}§ } int main() { - * [int](int) fp = foo(); // int (*fp)(int) + * [int](int) fp = foo(); §\C{// int (*fp)(int)}§ sout | fp( 3 ) | endl; } @@ -1122,5 +1206,5 @@ [ unsigned int, char ] [ double, double, double ] -[ * int, int * ] // mix of CFA and ANSI +[ * int, int * ] §\C{// mix of CFA and ANSI}§ [ * [ 5 ] int, * * char, * [ [ int, int ] ] (int, int) ] \end{lstlisting} @@ -1129,6 +1213,6 @@ Examples of declarations using tuple types are: \begin{lstlisting} -[ int, int ] x; // 2 element tuple, each element of type int -* [ char, char ] y; // pointer to a 2 element tuple +[ int, int ] x; §\C{// 2 element tuple, each element of type int}§ +* [ char, char ] y; §\C{// pointer to a 2 element tuple}§ [ [ int, int ] ] z ([ int, int ]); \end{lstlisting} @@ -1228,5 +1312,5 @@ [ int, int, int, int ] w = [ 1, 2, 3, 4 ]; int x = 5; -[ x, w ] = [ w, x ]; // all four tuple coercions +[ x, w ] = [ w, x ]; §\C{// all four tuple coercions}§ \end{lstlisting} Starting on the right-hand tuple in the last assignment statement, w is opened, producing a tuple of four values; @@ -1314,6 +1398,6 @@ both these examples produce indeterminate results: \begin{lstlisting} -f( x++, x++ ); // C routine call with side effects in arguments -[ v1, v2 ] = [ x++, x++ ]; // side effects in righthand side of multiple assignment +f( x++, x++ ); §\C{// C routine call with side effects in arguments}§ +[ v1, v2 ] = [ x++, x++ ]; §\C{// side effects in righthand side of multiple assignment}§ \end{lstlisting} @@ -1335,4 +1419,27 @@ \end{lstlisting} As in C, the rightmost assignment is performed first, i.e., assignment parses right to left. + + +\section{Unnamed Structure Fields} + +C requires each field of a structure to have a name, except for a bit field associated with a basic type, e.g.: +\begin{lstlisting} +struct { + int f1; // named field + int f2 : 4; // named field with bit field size + int : 3; // unnamed field for basic type with bit field size + int ; // disallowed, unnamed field + int *; // disallowed, unnamed field + int (*)(int); // disallowed, unnamed field +}; +\end{lstlisting} +This requirement is relaxed by making the field name optional for all field declarations; therefore, all the field declarations in the example are allowed. +As for unnamed bit fields, an unnamed field is used for padding a structure to a particular size. +A list of unnamed fields is also supported, e.g.: +\begin{lstlisting} +struct { + int , , ; // 3 unnamed fields +} +\end{lstlisting} @@ -1355,6 +1462,6 @@ double f4; } v; -v.[ f3, f1, f2 ] = ['x', 11, 17 ]; // equivalent to v.f3 = 'x', v.f1 = 11, v.f2 = 17 -f( v.[ f3, f1, f2 ] ); // equivalent to f( v.f3, v.f1, v.f2 ) +v.[ f3, f1, f2 ] = ['x', 11, 17 ]; §\C{// equivalent to v.f3 = 'x', v.f1 = 11, v.f2 = 17}§ +f( v.[ f3, f1, f2 ] ); §\C{// equivalent to f( v.f3, v.f1, v.f2 )}§ \end{lstlisting} Note, the fields appearing in a record-field tuple may be specified in any order; @@ -1376,37 +1483,80 @@ -\section{Labelled Break/Continue} - -While C provides ©break© and ©continue© statements for altering control flow, both are restricted to one level of nesting for a particular control structure. -Unfortunately, this restriction forces programmers to use ©goto© to achieve the equivalent for more than one level of nesting. -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}. -\VRef[Figure]{f:LabelledBreak} shows the labelled ©break©, and the target control structure of the exit. -The inner most loop has three exit points, which cause termination of one or more of the three nested loops, respectively. -\VRef[Figure]{f:LabelledContinue} shows the labelled ©continue©, and which control structure is the target of the next loop iteration. -The inner most loop has three restart points, which cause the next loop iteration to begin, respectively. - -\begin{figure} -\centering +\section{Labelled Continue / Break} + +While C provides ©continue© and ©break© statements for altering control flow, both are restricted to one level of nesting for a particular control structure. +Unfortunately, this restriction forces programmers to use ©goto© to achieve the equivalent control-flow for more than one level of nesting. +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}. +For both ©continue© and ©break©, the target label must be directly associated with a ©for©, ©while© or ©do© statement; +for ©break©, the target label can also be associated with a ©switch©, ©if© or compound (©{}©) statement. + +The following example shows the labelled ©continue© specifying which control structure is the target for the next loop iteration: +\begin{quote2} \begin{tabular}{@{}l@{\hspace{3em}}l@{}} \multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}} & \multicolumn{1}{c}{\textbf{C}} \\ \begin{lstlisting} -®L1:® for ( ... ) { - ®L2:® for ( ... ) { +®L1:® do { + ®L2:® while ( ... ) { ®L3:® for ( ... ) { - ... break ®L1®; ... - ... break ®L2®; ... - ... break ®L3®; // or break - } - } -} + ... continue ®L1®; ... // continue do + ... continue ®L2®; ... // continue while + ... continue ®L3®; ... // continue for + } // for + } // while +} while ( ... ); \end{lstlisting} & \begin{lstlisting} -for ( ... ) { - for ( ... ) { +do { + while ( ... ) { for ( ... ) { ... goto L1; ... ... goto L2; ... - ... goto L3; // or break + ... goto L3; ... + L3: ; } + L2: ; } +L1: ; } while ( ... ); +\end{lstlisting} +\end{tabular} +\end{quote2} +The innermost loop has three restart points, which cause the next loop iteration to begin. + +The following example shows the labelled ©break© specifying which control structure is the target for exit: +\begin{quote2} +\begin{tabular}{@{}l@{\hspace{3em}}l@{}} +\multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}} & \multicolumn{1}{c}{\textbf{C}} \\ +\begin{lstlisting} +®L1:® { + ... §declarations§ ... + ®L2:® switch ( ... ) { + case 3: + ®L3:® if ( ... ) { + ®L4:® for ( ... ) { + ... break ®L1®; ... // exit compound statement + ... break ®L2®; ... // exit switch + ... break ®L3®; ... // exit if + ... break ®L4®; ... // exit loop + } // for + } else { + ... break ®L3®; ... // exit if + } // if + } // switch +} // compound +\end{lstlisting} +& +\begin{lstlisting} +{ + ... §declarations§ ... + switch ( ... ) { + case 3: + if ( ... ) { + for ( ... ) { + ... goto L1; ... + ... goto L2; ... + ... goto L3; ... + ... goto L4; ... + } L4: ; + } else { + ... goto L3; ... } L3: ; } L2: ; @@ -1414,48 +1564,8 @@ \end{lstlisting} \end{tabular} -\caption{Labelled Break} -\label{f:LabelledBreak} - -\vspace*{0.25in} - -\begin{tabular}{@{}l@{\hspace{3em}}l@{}} -\multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}} & \multicolumn{1}{c}{\textbf{C}} \\ -\begin{lstlisting} -®L1®: for ( ... ) { - ®L2®: for ( ... ) { - ®L3®: for ( ... ) { - ... continue ®L1®; ... - ... continue ®L2®; ... - ... continue ®L3®; // or continue - - } - - } - -} -\end{lstlisting} -& -\begin{lstlisting} -for ( ... ) { - for ( ... ) { - for ( ... ) { - ... goto L1; ... - ... goto L2; ... - ... goto L3; // or continue - L3: ; - } - L2: ; - } - L1: ; -} -\end{lstlisting} -\end{tabular} -\caption{Labelled Continue} -\label{f:LabelledContinue} -\end{figure} - -For both ©break© and ©continue©, the target label must be directly associated with a ©for©, ©while© or ©do© statement; -for ©break©, the target label can also be associated with a ©switch© statement. -Both ©break© and ©continue© with target labels are simply a ©goto© restricted in the following ways: +\end{quote2} +The innermost loop has four exit points, which cause termination of one or more of the four \Index{nested control structure}s. + +Both ©continue© and ©break© with target labels are simply a ©goto©\index{goto@©goto©!restricted} restricted in the following ways: \begin{itemize} \item @@ -1464,11 +1574,11 @@ This restriction is important since all situations that can result in repeated execution of statements in a program are clearly delineated. \item -Since they always transfers out of containing control structures, they cannot be used to branch into a control structure. +Since they always transfer out of containing control structures, they cannot be used to branch into a control structure. \end{itemize} -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. -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. -With ©goto©, the label at the end of the control structure fails to convey this important clue early enough to the reader. -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. -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. +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. +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. +With ©goto©, the label is at the end of the control structure, which fails to convey this important clue early enough to the reader. +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. +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. @@ -1481,5 +1591,5 @@ In this section, the term \emph{case clause} refers to either a ©case© or ©default© clause.} \emph{falls through} to the next ©case© clause in the ©switch© statement; -to exit a ©switch© statement from a ©case© clause requires explicitly terminating the clause with a transfer statement, most commonly ©break©, as in: +to exit a ©switch© statement from a ©case© clause requires explicitly terminating the clause with a transfer statement, most commonly ©break©: \begin{lstlisting} switch ( i ) { @@ -1492,5 +1602,5 @@ } \end{lstlisting} -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: +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: \begin{lstlisting} switch ( argc ) { @@ -1507,5 +1617,5 @@ In this example, case 2 is always done if case 3 is done. 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. -C also uses fall-through to handle multiple case-values resulting in the same action, as in: +C also uses fall-through to handle multiple case-values resulting in the same action: \begin{lstlisting} switch ( i ) { @@ -1519,9 +1629,9 @@ \end{lstlisting} However, this situation is handled in other languages without fall-through by allowing a list of case values. -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. -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. - -\item -It is possible to place ©case© clauses on statements nested \emph{within} the body of the ©switch© statement, as in: +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. +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. + +\item +It is possible to place ©case© clauses on statements nested \emph{within} the body of the ©switch© statement: \begin{lstlisting} switch ( i ) { @@ -1581,6 +1691,6 @@ \begin{lstlisting} switch ( x ) { - int y = 1; // unreachable initialization - x = 7; // unreachable code + int y = 1; §\C{// unreachable initialization}§ + x = 7; §\C{// unreachable code}§ case 3: ... y = 3; @@ -1604,45 +1714,47 @@ 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. \end{itemize} -These observations should help to put the effects of suggested changes into perspective. -% Figure 1 shows the grammar change that attempts to minimize the effect on existing C programs. +These observations help to put the effects of suggested changes into perspective. \begin{enumerate} \item -Eliminating the ©default© fall-through problem has the greatest potential for affecting existing code. -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. -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.: +Eliminating default fall-through has the greatest potential for affecting existing code. +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.: \begin{lstlisting} case 1: case 2: case 3: ... \end{lstlisting} +still work. 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. Therefore, to preserve backwards compatibility, it is necessary to introduce a new kind of ©switch© statement, called ©choose©, with no fall-through semantics. -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). -It is still possible to fall-through if a case-clause ends with the new keyword fallthru, e.g.: -\begin{lstlisting} -choose ( i ) { - int i; - case 3, 4: - i = 3; - fallthru; - case 8, 10: +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). +It is still possible to fall-through if a case-clause ends with the new keyword ©fallthru©, e.g.: +\begin{lstlisting} +®choose® ( i ) { + case 3: + ... + ®fallthru®; §\C{// explicit fall through}§ + case 5: + ... §\C{// implicit end of switch}§ + case 7: + ... + ®break® §\C{// transfer to end of enclosing loop / switch}§ default: j = 3; } \end{lstlisting} -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. +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. \item Eliminating Duff's device is straightforward and only invalidates a small amount of very questionable code. 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. \item -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. +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. Therefore, no language change is made for this issue. \item -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. +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. 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. -As well, this grammar does not allow statements to appear before the first ©case© clause. +As well, statements cannot appear before the first ©case© clause. The change is compatible for declarations with initialization in this context because existing code cannot assume the initialization has occurred. The change is incompatible for statements, but any existing code using it is highly questionable, as in: \begin{lstlisting} switch ( i ) { - L: x = 5; // questionable code + L: x = 5; §\C{// questionable code}§ case 0: ... @@ -1691,5 +1803,6 @@ \end{tabular} \end{quote2} -In addition, two forms of subranges are allowed to specify case values: the GNU C form and a new \CFA form. +In addition, two forms of subranges are allowed to specify case values: a new \CFA form and an existing GNU C form.\footnote{ +The GNU C form \emph{requires} spaces around the ellipse.} \begin{quote2} \begin{tabular}{@{}l@{\hspace{3em}}l@{\hspace{2em}}l@{}} @@ -1723,26 +1836,7 @@ \end{tabular} \end{quote2} - - -\section{Unnamed Structure Fields} - -C requires each field of a structure to have a name, except for a bit field associated with a basic type, e.g.: -\begin{lstlisting} -struct { - int f1; // named field - int f2 : 4; // named field with bit field size - int : 3; // unnamed field for basic type with bit field size - int ; // disallowed, unnamed field - int *; // disallowed, unnamed field - int (*)(int); // disallowed, unnamed field -}; -\end{lstlisting} -This requirement is relaxed by making the field name optional for all field declarations; therefore, all the field declarations in the example are allowed. -As for unnamed bit fields, an unnamed field is used for padding a structure to a particular size. -A list of unnamed fields is also supported, e.g.: -\begin{lstlisting} -struct { - int , , ; // 3 unnamed fields -} +Lists of subranges are also allowed. +\begin{lstlisting} +case ®1~5, 12~21, 35~42®: \end{lstlisting} @@ -4217,86 +4311,139 @@ \section{Incompatible} -The following incompatibles exist between C and \CFA, and are similar to Annex C for \CC~\cite{ANSI14:C++}. +The following incompatibles exist between \CFA and C, and are similar to Annex C for \CC~\cite{ANSI14:C++}. \begin{enumerate} \item -Change type of character literal ©int© to ©char©. -This change allows overloading differentiation argument type matching, e.g.: -\begin{lstlisting} -int function( int i ); -int function( char c ); -function( 'x' ); -\end{lstlisting} -It is preferable that this call match the second version of function rather than the first. \\ -Effect on original feature: Change to semantics of well-defined feature. ISO C programs which depend on -\begin{lstlisting} -sizeof('x') == sizeof(int) -\end{lstlisting} -will not work the same as C++ programs. \\ -Difficulty of converting: Simple. \\ -How widely used: Programs which depend upon sizeof('x') are probably rare. - -\item -Change: String literals made ©const© \\ -The type of a string literal is changed from ©array of char© to ©array of const char©. -The type of a wide string literal is changed from ©array of wchar_t© to ©array of const wchar_t©. \\ -Rationale: This avoids calling an inappropriate overloaded function, which might expect to be able to modify its argument. -Effect on original feature: Change to semantics of well-defined feature. \\ -Difficulty of converting: Simple syntactic transformation, because string literals can be converted to ©char*;© (4.2). -The most common cases are handled by a new but deprecated standard conversion: -\begin{lstlisting} -char* p = "abc"; // valid in C, deprecated in C++ -char* q = expr ? "abc" : "de"; // valid in C, invalid in C++ -\end{lstlisting} -How widely used: Programs that have a legitimate reason to treat string literals as pointers to potentially modifiable memory are probably rare. - -\item -Change: C++ does not have \emph{tentative definitions} as in C. -E.g., at file scope, -\begin{lstlisting} -int i; -int i; -\end{lstlisting} -is valid in C, invalid in C++. -This makes it impossible to define mutually referential file-local static -objects, if initializers are restricted to the syntactic forms of C. For example, +\begin{description} +\item[Change:] add new keywords \\ +New keywords are added to \CFA. +\item[Rationale:] keywords added to implement new semantics of \CFA. +\item[Effect on original feature:] change to semantics of well-defined feature. \\ +Any ISO C programs using these keywords as identifiers are invalid \CFA programs. +\item[Difficulty of converting:] keyword clashes are accommodated by syntactic transformations using the \CFA backquote escape-mechanism: +\begin{lstlisting} +int `otype` = 3; // make keyword an indentifier +double `choose` = 3.5; +\end{lstlisting} +Programs can be converted automatically by enclosing keyword identifiers in backquotes, and the backquotes can be remove later when the identifier name is changed. +Clashes in C system libraries (include files) can be handled automatically using preprocessor, ©#include_next© and ©-Ifilename©: +\begin{lstlisting} +// include file uses the CFA keyword "otype". +#if ! defined( otype ) // nesting ? +#define otype `otype` +#define __CFA_BFD_H__ +#endif // ! otype + +#include_next // must have internal check for multiple expansion + +#if defined( otype ) && defined( __CFA_BFD_H__ ) // reset only if set +#undef otype +#undef __CFA_BFD_H__ +#endif // otype && __CFA_BFD_H__ +\end{lstlisting} +\item[How widely used:] clashes among new \CFA keywords and existing identifiers are rare. +\end{description} + +\item +\begin{description} +\item[Change:] type of character literal ©int© to ©char© to allow more intuitive overloading: +\begin{lstlisting} +int rtn( int i ); +int rtn( char c ); +rtn( 'x' ); // programmer expects 2nd rtn to be called +\end{lstlisting} +\item[Rationale:] it is more intuitive for the call to ©rtn© to match the second version of definition of ©rtn© rather than the first. +In particular, output of ©char© variable now print a character rather than the decimal ASCII value of the character. +\begin{lstlisting} +sout | 'x' | " " | (int)'x' | endl; +x 120 +\end{lstlisting} +Having to cast ©'x'© to ©char© is non-intuitive. +\item[Effect on original feature:] change to semantics of well-defined feature that depend on: +\begin{lstlisting} +sizeof( 'x' ) == sizeof( int ) +\end{lstlisting} +no long work the same in \CFA programs. +\item[Difficulty of converting:] simple +\item[How widely used:] programs that depend upon ©sizeof( 'x' )© are rare and can be changed to ©sizeof(char)©. +\end{description} + +\item +\begin{description} +\item[Change:] make string literals ©const©: +\begin{lstlisting} +char * p = "abc"; // valid in C, deprecated in §\CFA§ +char * q = expr ? "abc" : "de"; // valid in C, invalid in §\CFA§ +\end{lstlisting} +The type of a string literal is changed from ©[] char© to ©const [] char©. +Similarly, the type of a wide string literal is changed from ©[] wchar_t© to ©const [] wchar_t©. +\item[Rationale:] This change is a safety issue: +\begin{lstlisting} +char * p = "abc"; +p[0] = 'w'; // segment fault or change constant literal +\end{lstlisting} +The same problem occurs when passing a string literal to a routine that changes its argument. +\item[Effect on original feature:] change to semantics of well-defined feature. +\item[Difficulty of converting:] simple syntactic transformation, because string literals can be converted to ©char *©. +\item[How widely used:] programs that have a legitimate reason to treat string literals as pointers to potentially modifiable memory are rare. +\end{description} + +\item +\begin{description} +\item[Change:] remove \newterm{tentative definitions}, which only occurs at file scope: +\begin{lstlisting} +int i; // forward definition +int *j = ®&i®; // forward reference, valid in C, invalid in §\CFA§ +int i = 0; // definition +\end{lstlisting} +is valid in C, and invalid in \CFA because duplicate overloaded object definitions at the same scope level are disallowed. +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, \begin{lstlisting} struct X { int i; struct X *next; }; -static struct X a; -static struct X b = { 0, &a }; -static struct X a = { 1, &b }; -\end{lstlisting} -Rationale: This avoids having different initialization rules for builtin types and userdefined types. -Effect on original feature: Deletion of semantically welldefined feature. \\ -Difficulty of converting: Semantic transformation. -In C++, the initializer for one of a set of mutuallyreferential filelocal static objects must invoke a function call to achieve the initialization. -How widely used: Seldom. - -\item -Change: A struct is a scope in C++, not in C \\ -Rationale: Class scope is crucial to C++, and a struct is a class. \\ -Effect on original feature: Change to semantics of well-defined feature. \\ -Difficulty of converting: Semantic transformation. \\ -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. -The latter is probably rare. +static struct X a; // forward definition +static struct X b = { 0, ®&a® }; // forward reference, valid in C, invalid in §\CFA§ +static struct X a = { 1, &b }; // definition +\end{lstlisting} +\item[Rationale:] avoids having different initialization rules for builtin types and userdefined types. +\item[Effect on original feature:] change to semantics of well-defined feature. +\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. +\item[How widely used:] seldom +\end{description} + +\item +\begin{description} +\item[Change:] have ©struct© introduce a scope for nested types +In C, the name of the nested types belongs to the same scope as the name of the outermost enclosing +Example: +\begin{lstlisting} +enum ®Colour® { R, G, B, Y, C, M }; +struct Person { + enum ®Colour® { R, G, B }; // nested type + struct Face { // nested type + ®Colour® Eyes, Hair; // type defined outside (1 level) + }; + ß.ß®Colour® shirt; // type defined outside (top level) + ®Colour® pants; // type defined same level + Face looks[10]; // type defined same level +}; +®Colour® c = R; // type/enum defined same level +Personß.ß®Colour® pc = Personß.ßR; // type/enum defined inside +Personß.ßFace pretty; // type defined inside +\end{lstlisting} +\item[Rationale:] ©struct© scope is crucial to \CFA as an information structuring and hiding mechanism. +\item[Effect on original feature:] change to semantics of well-defined feature. +\item[Difficulty of converting:] Semantic transformation. +\item[How widely used:] C programs rarely have nest types because they are equivalent to the hoisted version. \CFA is C \emph{incompatible} on this issue, and provides semantics similar to \CC. Nested types are not hoisted and can be referenced using the field selection operator ``©.©'', unlike the \CC scope-resolution operator ``©::©''. 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. - -\item -Change: In C++, the name of a nested class is local to its enclosing class. -In C the name of the nested class belongs to the same scope as the name of the outermost enclosing class -Example: -\begin{lstlisting} -struct X { -struct Y { /* ... */ } y; -}; -struct Y yy; // valid C, invalid C++ -\end{lstlisting} -Rationale: C++ classes have member functions which require that classes establish scopes. -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. -Effect on original feature: Change of semantics of welldefined feature. -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: +\end{description} + +\item +\begin{description} +\item[Change:] In C++, the name of a nested class is local to its enclosing class. +\item[Rationale:] C++ classes have member functions which require that classes establish scopes. +\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: \begin{lstlisting} struct Y; // struct Y and struct X are at the same scope @@ -4307,5 +4454,15 @@ 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. Note: this is a consequence of the difference in scope rules, which is documented in 3.3. -How widely used: Seldom. +\item[How widely used:] Seldom. +\end{description} + +\item +\begin{description} +\item[Change:] comma expression is disallowed as subscript +\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. +\item[Effect on original feature:] change to semantics of well-defined feature. +\item[Difficulty of converting:] semantic transformation of ©x[i,j]© to ©x[(i,j)]© +\item[How widely used:] seldom. +\end{description} \end{enumerate}