Index: c/man/README =================================================================== --- doc/man/README (revision 09f800bd7b91671fcde02aa251d4cb0eecc48ae1) +++ (revision ) @@ -1,5 +1,0 @@ -There are two troff variables at the beginning of the source files that define -the home path to cfa and the version number. The version variable should be -set properly (we sometimes forget); change the path for the home variable to -the location where cfa is installed. There is a command at the beginning of the -source file to format the manual entry. Index: c/man/cfa.1 =================================================================== --- doc/man/cfa.1 (revision 09f800bd7b91671fcde02aa251d4cb0eecc48ae1) +++ (revision ) @@ -1,186 +1,0 @@ -.\" -*- Mode: Nroff -*- -.\" -.\" uC++ Version 6.1.0, Copyright (C) Peter A. Buhr 1994 -.\" -.\" u++.1 -- -.\" -.\" Author : Peter A. Buhr -.\" Created On : Sat Jul 2 21:47:05 1994 -.\" Last Modified By : Peter A. Buhr -.\" Last Modified On : Fri Apr 6 13:44:28 2012 -.\" Update Count : 52 -.\" -.\" nroff -man u++.1 -.\" -.ds Ho "/usr/local -.ds Vr "u++\-6.1.0 -.TH u++ 1 -.SH NAME -u++ \- uC++ Translator and Concurrency Runtime System -.SH SYNOPSIS -u++ [-option [...]] [filename [...]] -.SH DESCRIPTION -The u++ command compiles uC++ and C++ source files and links C++ object files -named on the command line. - -The u++ command introduces a translator pass over the specified source files -after the C preprocessor but before the actual C++ compilation. The translator -converts several new uC++ constructs into C++ statements. The u++ command also -provides the runtime concurrency library, which must be linked with each uC++ -application. - -The command line options depend on the particular C++ compiler used. As with -most C compilers, the output is sent to the file a.out(5) unless the -o option -is present on the command line. See the reference pages for g++(1) and CC(1) -for more information. -.SH OPTIONS -When multiple conflicting options appear on the command line, e.g., -.B -debug -followed by -.B -nodebug, -the last option takes precedence. -All of the options available to the C++ compiler are available to u++, plus the -following: -.IP -debug 3 -The program is linked with the debugging version of the unikernel or -multikernel. The debug version performs runtime checks to help during the -debugging phase of a uC++ program, but substantially slows the execution of the -program. This option is the default. -.IP -nodebug -The program is linked with the non-debugging version of the unikernel or -multikernel, so the execution of the program is faster. However, no runtime -checks or asserts are performed so errors usually result in abnormal program -termination. -.IP -yield -When a program is translated, a random number of context switches occur at the -beginning of each member routine so that during execution on a uniprocessor -there is a better simulation of parallelism. (This non-determinism in -execution is in addition to random context switching due to pre-emptive -scheduling. The extra yields of execution can help during the debugging phase -of a uC++ program, but substantially slows the execution of the program. -.IP -noyield -Additional context switches are not inserted in member routines. This option -is the default. -.IP -verify -When a program is translated, a check to verify that the stack has not -overflowed occurs at the beginning of each member routine. Verifying the -stack has not overflowed is important during the debugging phase of a uC++ -program, but slows the execution of the program. -.IP -noverify -Stack-overflow checking is not inserted in member routines. This option is the -default. -.IP -multi -The program is linked with the multikernel. See the uC++ RUNTIME KERNELS -section below. -.IP -nomulti -The program is linked with the unikernel. This option is the default. See the -uC++ RUNTIME KERNELS section below. -.IP -quiet -The uC++ compilation message is not printed at the beginning of a -compilation. -.IP -noquiet -The uC++ compilation message is printed at the beginning of a compilation. -This option is the default. -.IP -U++ -Only the C preprocessor and the uC++ translator steps are performed and the -transformed program is written to standard output, which makes it possible to -examine the code generated by the uC++ translator. -.IP "-compiler path-name" -The path-name of the compiler used to compile a uC++ program(s). The default -is the compiler used to compile the uC++ runtime library. It is unsafe to use -a different compiler unless the generated code is binary compatible. -.SH uC++ RUNTIME KERNELS -There are two versions of the uC++ kernel: the unikernel, which is designed to -use a single processor; and the multikernel, which is designed to use several -processors. Thus, the unikernel is sensibly used on systems with a single -hardware processor or when kernel threads are unavailable; the multikernel is -sensibly used on systems that have multiple hardware processors and when kernel -threads are available. The table below shows the situations where each kernel -can be used. The unikernel can be used in a system with multiple hardware -processors and kernel threads but does not take advantage of either of these -capabilities. The multikernel can be used on a system with a single hardware -processor and kernel threads but performs less efficiently than the unikernel -because it uses multiprocessor techniques unnecessarily. -.DS B - +-----------+-------------------------+ - | no kernel | kernel | - | threads | threads | - +----------+-----------+-------------------------+ - |single |uni: yes |uni: yes | - |processor |multi: no |multi: yes (inefficient) | - +----------+-----------+-------------------------+ - |multiple |uni: yes |uni: yes (no parallelism)| - |processors|multi: no |multi: yes | - +----------+-----------+-------------------------+ -.DE -.SH PREPROCESSOR VARIABLES -When programs are compiled using u++, the following preprocessor variables are -available. These variables allow conditional compilation of programs that must -work differently in these situations. -.IP __U_CPLUSPLUS__ 3 -is always available during preprocessing and its value is the current major -version number. -.IP __U_CPLUSPLUS_MINOR__ -is always available during preprocessing and its value is the current minor -version number. -.IP __U_CPLUSPLUS_PATCH__ -is always available during preprocessing and its value is the current patch -version number. -.IP __U_DEBUG__ -is available during preprocessing if the -debug compilation option is -specified. -.IP __U_YIELD__ -is available during preprocessing if the -yield compilation option is -specified. -.IP __U_VERIFY__ -is available during preprocessing if the -verify compilation option is -specified. -.IP __U_MULTI__ -is available during preprocessing if the -multi compilation option is specified. -.SH FILES -.DS B -file.{cc,C} - uC++ source file -.br -file.s - assembly language file -.br -file.o - object file -.br -\*(Ho/bin/u++ - translator -.br -\*(Ho/\*(Vr/doc - reference manual and license -.br -\*(Ho/\*(Vr/inc - header files -.br -\*(Ho/\*(Vr/lib - run time libraries -.br -\*(Ho/\*(Vr/man - command documentation -.br -\*(Ho/\*(Vr/src - source code (optional) -.DE -.SH SEE ALSO -CC(1), cpp(1), g++(1) -.br -.I "uC++ Annotated Reference Manual" -.br -.I "Understanding Control Flow with Concurrent Programming using uC++" -.SH REFERENCES -.HP 3 -.I "uC++: Concurrency in the Object-Oriented Language C++," -by P.A. Buhr, G. Ditchfield, R.A. Stroobosscher, B.M. Younger, C.R. Zarnke; -Software-Practise and Experience, 22(2):137--172, February 1992. This paper -describes uC++ v2.0, which has been significantly extended. -.HP -.I "Examining uC++," -by Peter A. Buhr and Richard C. Bilson; -Dr. Dobb's Journal : Software Tools for the Professional Programmer, -31(2):36--40, February 2006. -.HP -.I "uC++ Annotated Reference Manual" -most up-to-date features. -.SH BUGS -Bugs should be reported to usystem@plg.uwaterloo.ca. -.SH COPYRIGHT -This library is covered under the GNU Lesser General Public License. -.SH AUTHORS -Peter A. Buhr (pabuhr@plg.uwaterloo.ca) and many others, Programming Languages -Group, University of Waterloo, Ontario, Canada, N2L 3G1. Index: doc/refrat/Makefile =================================================================== --- doc/refrat/Makefile (revision f60d99733bc80247fe4b9e1478ee0d49a7c019e5) +++ doc/refrat/Makefile (revision f60d99733bc80247fe4b9e1478ee0d49a7c019e5) @@ -0,0 +1,70 @@ +## Define the appropriate configuration variables. + +TeXLIB = .:: +LaTeX = TEXINPUTS=${TeXLIB} && export TEXINPUTS && latex +BibTeX = BSTINPUTS=${TeXLIB} && export BSTINPUTS && bibtex + +## Define the text source files. + +SOURCE = ${addsuffix .tex, \ +refrat \ +} + +FIGURES = ${addsuffix .tex, \ +} + +PICTURES = ${addsuffix .pstex, \ +} + +PROGRAMS = ${addsuffix .tex, \ +} + +GRAPHS = ${addsuffix .tex, \ +} + +## Define the documents that need to be made. + +DOCUMENT = refrat.pdf + +# Directives # + +all : ${DOCUMENT} + +clean : + rm -f *.bbl *.aux *.dvi *.idx *.ilg *.ind *.brf *.out *.log *.toc *.blg *.pstex_t ${FIGURES} ${PICTURES} ${PROGRAMS} ${GRAPHS} ${basename ${DOCUMENT}}.ps ${DOCUMENT} + +# File Dependencies # + +${DOCUMENT} : ${basename ${DOCUMENT}}.ps + ps2pdf $< + +${basename ${DOCUMENT}}.ps : ${basename ${DOCUMENT}}.dvi + dvips $< -o $@ + +${basename ${DOCUMENT}}.dvi : Makefile ${GRAPHS} ${PROGRAMS} ${PICTURES} ${FIGURES} ${SOURCE} refrat.bbl ${basename ${DOCUMENT}}.tex ${basename ${DOCUMENT}}.idx ${basename ${DOCUMENT}}.bbl + ${LaTeX} ${basename $@}.tex + if fgrep -s "Label(s) may have changed" ${basename $@}.log ; then ${LaTeX} ${basename $@}.tex ; fi + makeindex -s indexstyle ${basename $@}.idx + ${LaTeX} ${basename $@}.tex + ${LaTeX} ${basename $@}.tex % to get index title in toc + +${basename ${DOCUMENT}}.idx : %.idx : %.tex + if [ ! -r ${basename $@}.ind ] ; then cp /dev/null ${basename $@}.ind ; fi + +${basename ${DOCUMENT}}.bbl : + if [ ! -r ${basename $@}.aux ] ; then ${LaTeX} ${basename $@}.tex ; fi + -${BibTeX} ${basename $@} + ${LaTeX} ${basename $@}.tex + -${BibTeX} ${basename $@} + +## Define the default recipes. + +%.tex : %.fig + fig2dev -L eepic $< > $@ + +%.ps : %.fig + fig2dev -L ps $< > $@ + +# Local Variables: # +# compile-command: "make" # +# End: # Index: doc/refrat/indexstyle =================================================================== --- doc/refrat/indexstyle (revision f60d99733bc80247fe4b9e1478ee0d49a7c019e5) +++ doc/refrat/indexstyle (revision f60d99733bc80247fe4b9e1478ee0d49a7c019e5) @@ -0,0 +1,2 @@ +preamble "" +postamble "" Index: doc/refrat/predefined.sed =================================================================== --- doc/refrat/predefined.sed (revision f60d99733bc80247fe4b9e1478ee0d49a7c019e5) +++ doc/refrat/predefined.sed (revision f60d99733bc80247fe4b9e1478ee0d49a7c019e5) @@ -0,0 +1,4 @@ +/\\begin{predefined}/,/\\end{predefined}/ !d +/\\begin{predefined}/,/\\end{predefined}/ s/\\use{.*}//g +/\\begin{predefined}/ d +/\\end{predefined}/ d Index: doc/refrat/refrat.bib =================================================================== --- doc/refrat/refrat.bib (revision f60d99733bc80247fe4b9e1478ee0d49a7c019e5) +++ doc/refrat/refrat.bib (revision f60d99733bc80247fe4b9e1478ee0d49a7c019e5) @@ -0,0 +1,119 @@ +@string{sigplan="SIGPLAN Notices"} + +@manual{ANS:C, + keywords = {ANSI C}, + contributer = {gjditchfield@msg}, + title = {American National Standard for Information Systems -- + Programming Language -- {C}}, + organization = {American National Standards Institute}, + address = {1430 Broadway, New York, New York 10018}, + month = dec, year = 1989, + note = {X3.159-1989} +} + +@manual{ANS:C11, + keywords = {ANS:C11}, + contributer = {gjditchfield@acm.org}, + title = {American National Standard Information Systems -- + Programming languages -- {C}}, + organization = {American National Standards Institute}, + address = {25 West 43rd Street, New York, New York 10036}, + month = may, year = 2012, + note = {INCITS/ISO/IEC 9899-2011[2012]} +} + +@book{c++, + keywords = {C++, ANSI}, + author = {Margaret A. Ellis and Bjarne Stroustrup}, + title = {The Annotated {C}{\tt ++} Reference Manual}, + publisher = {Addison Wesley}, + year = 1990, + edition = {first} +} + +@Unpublished{Ditchfield96:Overview, + author = "Glen Ditchfield", + title = "An Overview of Cforall", + note = "in preparation", + year = 1996 +} + +@article{Bak:overload, + keywords = {compilation}, + contributer = {gjditchfield@msg}, + author = {T. P. Baker}, + title = {A One-Pass Algorithm for Overload Resolution in {Ada}}, + journal = toplas, + year = 1982, + month = oct, volume = 4, number = 4, pages = {601--614}, + abstract = { + A simple method is presented for detecting ambiguities and finding + the correct interpretations of expressions in the programming + language Ada. Unlike previously reported solutions to this + problem, which require multiple passes over a tree structure, the + method described here operates in one bottom-up pass, during which + a directed acyclic graph is produced. The correctness of this + approach is demonstrated by a brief formal argument. + }, + comment = { + See also \cite{D:overload}. + } +} + +@article{Cormack90, + keywords = {polymorphism}, + contributer = {pabuhr@msg}, + author = {G. V. Cormack and A. K. Wright}, + title = {Type-dependent Parameter Inference}, + journal = sigplan, + volume = 25, + number = 6, + month = jun, + year = 1990, + pages = {127--136}, + note = {Proceedings of the ACM Sigplan'90 Conference on Programming Language Design and Implementation + June 20-22, 1990, White Plains, New York, U.S.A.}, +} + +@book{clu, + keywords = {CLU}, + contributer = {gjditchfield@msg}, + author = {Barbara Liskov and Russell Atkinson and Toby Bloom and Eliot + Moss and J. Craig Schaffert and Robert Scheifler and Alan Snyder}, + title = {CLU Reference Manual}, + publisher = {Springer-Verlag}, + year = 1981, + volume = 114, + series = {Lecture Notes in Computer Science} +} + +@manual{SIMULA87, + keywords = {Simula standard}, + contributer = {gjditchfield@msg}, + title = {Databehandling -- Programspr{\aa}k -- {SIMULA}}, + organization = {Standardiseringskommissionen i Sverige}, + note = {Svensk Standard SS 63 61 14}, + year = 1987, + abstract = { + Standard for the programming language SIMULA. Written in English. + } +} + +@manual{ada, + keywords = {Ada, packages, tasks, exceptions}, + contributer = {pabuhr@msg}, + title = {The Programming Language {Ada}: Reference Manual}, + organization= {United States Department of Defense}, + edition = {{ANSI/MIL-STD-1815A-1983}}, + month = feb, + year = 1983, + note = {Published by Springer-Verlag} +} + +@inproceedings{Thompson90new, + title = {A New C Compiler}, + author = {Ken Thompson}, + booktitle = {Proceedings of the Summer 1990 UKUUG Conference}, + year = 1990, + pages = {41--51} +} Index: doc/refrat/refrat.tex =================================================================== --- doc/refrat/refrat.tex (revision 09f800bd7b91671fcde02aa251d4cb0eecc48ae1) +++ doc/refrat/refrat.tex (revision f60d99733bc80247fe4b9e1478ee0d49a7c019e5) @@ -0,0 +1,4390 @@ +\documentclass[openright,twoside]{report} +\usepackage{fullpage,times} +\usepackage{xspace} +\usepackage{varioref} +\usepackage{listings} +\usepackage{latexsym} % \Box +\usepackage{mathptmx} % better math font with "times" +\usepackage[pagewise]{lineno} +\renewcommand{\linenumberfont}{\scriptsize\sffamily} +\usepackage[dvips,plainpages=false,pdfpagelabels,pdfpagemode=UseNone,colorlinks=true,pagebackref=true,linkcolor=blue,citecolor=blue,urlcolor=blue,pagebackref=true,breaklinks=true]{hyperref} +\usepackage{breakurl} +\urlstyle{sf} + +%\input code.sty +\input xref.tex + +\newcommand{\define}[1]{\emph{#1\/}\index{#1}} +\newenvironment{rationale}{% + \begin{quotation}\noindent$\Box$\enspace +}{% + \hfill\enspace$\Box$\end{quotation} +}% +\newcommand{\rewrite}{\(\Rightarrow\)} +\newcommand{\rewriterules}{\paragraph{Rewrite Rules}\hskip1em\par\noindent} +\newcommand{\examples}{\paragraph{Examples}\hskip1em\par\noindent} +\newcommand{\semantics}{\paragraph{Semantics}\hskip1em\par\noindent} +\newcommand{\constraints}{\paragraph{Constraints}\hskip1em\par\noindent} +\newenvironment{predefined}{% + \paragraph{Predefined Identifiers}% +% \begin{code}% +}{% +% \end{code} +}% + +\def\syntax{\paragraph{Syntax}\trivlist\parindent=.5in\item[\hskip.5in]} +\let\endsyntax=\endtrivlist +\newcommand{\lhs}[1]{\par{\it #1:}\index{#1@{\it #1}|italic}} +\newcommand{\rhs}{\hfil\break\hbox{\hskip1in}} +\newcommand{\oldlhs}[1]{{\it #1: \ldots}\index{#1@{\it #1}|italic}} +\newcommand{\nonterm}[1]{{\it #1\/}\index{#1@{\it #1}|italic}} +\newcommand{\opt}{$_{opt}$\ } + +\renewcommand{\reftextfaceafter}{\unskip} +\renewcommand{\reftextfacebefore}{\unskip} +\renewcommand{\reftextafter}{\unskip} +\renewcommand{\reftextbefore}{\unskip} +\renewcommand{\reftextfaraway}[1]{\unskip, p.~\pageref{#1}} +\renewcommand{\reftextpagerange}[2]{\unskip, pp.~\pageref{#1}--\pageref{#2}} +\newcommand{\VRef}[2][Section]{\ifx#1\@empty\else{#1}\nobreakspace\fi\vref{#2}} +\newcommand{\VPageref}[2][page]{\ifx#1\@empty\else{#1}\nobreakspace\fi\pageref{#2}} + +\newcommand{\CFA}{Cforall\xspace} +\newcommand{\CFAA}{C$\forall$\xspace} +\newcommand{\CC}{C\kern-.1em\hbox{+\kern-.25em+}\xspace} +\def\c11{ISO/IEC C}% cannot have numbers in latex command name + +\lstdefinelanguage{CFA}[ANSI]{C}% + {morekeywords={asm,_Atomic,catch,choose,_Complex,context,dtype,fallthru,forall,ftype,_Imaginary,lvalue,restrict,throw,try,type,}, +} + +\lstset{ +language=CFA, +columns=fullflexible, +basicstyle=\sf\small, +tabsize=4, +xleftmargin=\parindent, +escapechar=@, +%showtabs=true, +%tab=\rightarrowfill, +} + +\setcounter{secnumdepth}{3} % number subsubsections +\makeindex + +\begin{document} +\pagestyle{headings} +\linenumbers % comment out to turn off line numbering + +\title{\CFA (\CFAA) Reference Manual and Rationale} +\author{Glen Ditchfield} +\date{DRAFT\\\today} + +\pagenumbering{roman} +\pagestyle{plain} + +\maketitle + +\vspace*{\fill} +\thispagestyle{empty} +\noindent +\copyright\,2015 Glen Ditchfield \\ \\ +\noindent +This work is licensed under the Creative Commons Attribution 4.0 International License. To view a +copy of this license, visit {\small\url{http://creativecommons.org/licenses/by/4.0}}. +\vspace*{1in} + +\clearpage +\pdfbookmark[1]{Contents}{section} +\tableofcontents + +\clearpage +\pagenumbering{arabic} + + +\chapter*{Introduction}\addcontentsline{toc}{chapter}{Introduction} + +This document is a reference manual and rationale for \CFA, a polymorphic extension of the C +programming language. It makes frequent reference to the {\c11} standard \cite{ANS:C11}, and +occasionally compares \CFA to {\CC} \cite{c++}. + +The manual deliberately imitates the ordering of the {\c11} standard (although the section numbering +differs). Unfortunately, this means that the manual contains more ``forward references'' than +usual, and that it will be hard to follow if the reader does not have a copy of the {\c11} standard +near-by. For a gentle introduction to \CFA, see the companion document ``An Overview of +\CFA'' \cite{Ditchfield96:Overview}. + +\begin{rationale} +Commentary (like this) is quoted with quads. Commentary usually deals with subtle points, the +rationale behind a rule, and design decisions. +\end{rationale} + +% No ``Scope'' or ``Normative references'' chapters yet. +\setcounter{chapter}{2} +\chapter{Terms, definitions, and symbols} +Terms from the {\c11} standard used in this document have the same meaning as in the {\c11} +standard. + +% No ``Conformance'' or ``Environment'' chapters yet. +\setcounter{chapter}{5} +\chapter{Language} +\section{Notation} +The syntax notation used in this document is the same as is used in the {\c11} standard, with one +exception: ellipsis in the definition of a nonterminal, as in ``\emph{declaration:} \ldots'', +indicates that these rules extend a previous definition, which occurs in this document or in the +{\c11} standard. + + +\section{Concepts} + + +\subsection{Scopes of identifiers}\index{scopes} + +\CFA's scope rules differ from C's in one major respect: a declaration of an identifier may +overload\index{overloading} outer declarations of lexically identical identifiers in the same name +space\index{name spaces}, instead of hiding them. The outer declaration is hidden if the two +declarations have compatible type\index{compatible type}, or if one declares an array type and the +other declares a pointer type and the element type and pointed-at type are compatible, or if one has +function type and the other is a pointer to a compatible function type, or if one declaration is a +\lstinline$type$\use{type} or \lstinline$typedef$\use{typedef} declaration and the other is not. +The outer declaration becomes visible\index{visible} when the scope of the inner declaration +terminates. +\begin{rationale} +Hence, a \CFA program can declare an \lstinline$int v$ and a \lstinline$float v$ in the same +scope; a {\CC} program can not. +\end{rationale} + + +\subsection{Linkage of identifiers}\index{linkage} + +\CFA's linkage rules differ from C's in only one respect: instances of a particular identifier +with external or internal linkage do not necessarily denote the same object or function. Instead, +in the set of translation units and libraries that constitutes an entire program, any two instances +of a particular identifier with external linkage\index{external linkage} denote the same object or +function if they have compatible types\index{compatible type}, or if one declares an array type and +the other declares a pointer type and the element type and pointed-at type are compatible, or if one +has function type and the other is a pointer to a compatible function type. Within one translation +unit, each instance of an identifier with internal linkage\index{internal linkage} denotes the same +object or function in the same circumstances. Identifiers with no linkage\index{no linkage} always +denote unique entities. +\begin{rationale} +A \CFA program can declare an \lstinline$extern int v$ and an \lstinline$extern float v$; a C +program cannot. +\end{rationale} + +\section{Conversions} +\CFA defines situations where values of one type are automatically converted to another type. +These conversions are called \define{implicit conversions}. The programmer can request +\define{explicit conversions} using cast expressions. + + +\subsection{Arithmetic operands} +\setcounter{subsubsection}{7} + + +\subsubsection{Safe arithmetic conversions} +In C, a pattern of conversions known as the \define{usual arithmetic conversions} is used with most +binary arithmetic operators to convert the operands to a common type and determine the type of the +operator's result. In \CFA, these conversions play a role in overload resolution, and +collectively are called the \define{safe arithmetic conversions}. + +Let \(int_r\) and \(unsigned_r\) be the signed and unsigned integer types with integer conversion +rank\index{integer conversion rank} \index{rank|see{integer conversion rank}} $r$. Let +\(unsigned_{mr}\) be the unsigned integer type with maximal rank. + +The following conversions are \emph{direct} safe arithmetic conversions. +\begin{itemize} +\item +The integer promotions\index{integer promotions}. + +\item +For every rank $r$ greater than or equal to the rank of \lstinline$int$, conversion from \(int_r\) +to \(unsigned_r\). + +\item +For every rank $r$ greater than or equal to the rank of \lstinline$int$, where \(int_{r+1}\) exists +and can represent all values of \(unsigned_r\), conversion from \(unsigned_r\) to \(int_{r+1}\). + +\item +Conversion from \(unsigned_{mr}\) to \lstinline$float$. + +\item +Conversion from an enumerated type to its compatible integer type. + +\item +Conversion from \lstinline$float$ to \lstinline$double$, and from \lstinline$double$ to +\lstinline$long double$. + +\item +Conversion from \lstinline$float _Complex$ to \lstinline$double _Complex$, +and from \lstinline$double _Complex$ to \lstinline$long double _Complex$. + +\begin{sloppypar} +\item +Conversion from \lstinline$float _Imaginary$ to \lstinline$double _Imaginary$, and from +\lstinline$double _Imaginary$ to \lstinline$long double$ \lstinline$_Imaginary$, if the +implementation supports imaginary types. +\end{sloppypar} +\end{itemize} + +If type \lstinline$T$ can be converted to type \lstinline$U$ by a safe direct arithmetic conversion +and type \lstinline$U$ can be converted to type \lstinline$V$ by a safe arithmetic conversion, then +the conversion from \lstinline$T$ to type \lstinline$V$ is an \emph{indirect} safe arithmetic +conversion. + +\begin{rationale} +Note that {\c11} does not include conversion from real types\index{real type} to complex +types\index{complex type} in the usual arithmetic conversions, and \CFA does not include them as +safe conversions. +\end{rationale} + + +\subsection{Other operands} +\setcounter{subsubsection}{3} + + +\subsubsection{Anonymous structures and unions} +\label{anon-conv} + +If an expression's type is a pointer to a structure or union type that has a member that is an +anonymous structure\index{anonymous structure} or an anonymous union\index{anonymous union}, it can +be implicitly converted\index{implicit conversions} to a pointer to the anonymous structure's or +anonymous union's type. The result of the conversion is a pointer to the member. + +\examples +\begin{lstlisting} +struct point { + int x, y; +}; +void move_by(struct point * p1, struct point * p2) {@\impl{move_by}@ + p1->x += p2.x; + p1->y += p2.y; +} + +struct color_point { + enum { RED, BLUE, GREEN } color; + struct point; +} cp1, cp2; +move_to(&cp1, &cp2); +\end{lstlisting} +Thanks to implicit conversion, the two arguments that \lstinline$move_by()$ receives are pointers to +\lstinline$cp1$'s second member and \lstinline$cp2$'s second member. + + +\subsubsection{Specialization} +A function or value whose type is polymorphic may be implicitly converted to one whose type is less +polymorphic\index{less polymorphic} by binding values to one or more of its inferred +parameters\index{inferred parameter}. Any value that is legal for the inferred parameter may be +used, including other inferred parameters. + +If, after the inferred parameter binding, an assertion parameter\index{assertion parameters} has no +inferred parameters in its type, then an object or function must be visible at the point of the +specialization that has the same identifier as the assertion parameter and has a type that is +compatible\index{compatible type} with or can be specialized to the type of the assertion parameter. +The assertion parameter is bound to that object or function. + +The type of the specialization is the type of the original with the bound inferred parameters and +the bound assertion parameters replaced by their bound values. + +\examples +The type +\begin{lstlisting} +forall( type T, type U ) void (*)( T, U ); +\end{lstlisting} +can be specialized to (among other things) +\begin{lstlisting} +forall( type T ) void (*)( T, T ); // U bound to T +forall( type T ) void (*)( T, real ); // U bound to real +forall( type U ) void (*)( real, U ); // T bound to real +void f( real, real ); // both bound to real +\end{lstlisting} + +The type +\begin{lstlisting} +forall( type T | T ?+?( T, T )) T (*)( T ); +\end{lstlisting} +can be specialized to (among other things) +\begin{lstlisting} +int (*)( int ); // T bound to int, and T ?+?(T, T ) bound to int ?+?( int, int ) +\end{lstlisting} + + +\subsubsection{Safe conversions} + +A \define{direct safe conversion} is one of the following conversions: +\begin{itemize} +\item +a direct safe arithmetic conversion; +\item +from any object type or incomplete type to \lstinline$void$; +\item +from a pointer to any non-\lstinline$void$ type to a pointer to \lstinline$void$; +\item +from a pointer to any type to a pointer to a more qualified version of the type\index{qualified +type}; +\item +from a pointer to a structure or union type to a pointer to the type of a member of the structure or +union that is an anonymous structure\index{anonymous structure} or an anonymous +union\index{anonymous union}; +\item +within the scope of an initialized type declaration\index{type declaration}, conversions between a +type and its implementation or between a pointer to a type and a pointer to its implementation. +\end{itemize} + +Conversions that are not safe conversions are \define{unsafe conversions}. +\begin{rationale} +As in C, there is an implicit conversion from \lstinline$void *$ to any pointer type. This is +clearly dangerous, and {\CC} does not have this implicit conversion. +\CFA\index{deficiencies!void * conversion} keeps it, in the interest of remaining as pure a +superset of C as possible, but discourages it by making it unsafe. +\end{rationale} + + +\subsection{Conversion cost} + +The \define{conversion cost} of a safe\index{safe conversions} +conversion\footnote{Unsafe\index{unsafe conversions} conversions do not have defined conversion +costs.} is a measure of how desirable or undesirable it is. It is defined as follows. +\begin{itemize} +\item +The cost of a conversion from any type to itself is 0. + +\item +The cost of a direct safe conversion is 1. + +\item +The cost of an indirect safe arithmetic conversion is the smallest number of direct conversions +needed to make up the conversion. +\end{itemize} + +\examples +In the following, assume an implementation that does not provide any extended integer types. + +\begin{itemize} +\item +The cost of an implicit conversion from \lstinline$int$ to \lstinline$long$ is 1. The cost of an +implicit conversion from \lstinline$long$ to \lstinline$double$ is 3, because it is defined in terms +of conversions from \lstinline$long$ to \lstinline$unsigned long$, then to \lstinline$float$, and +then to \lstinline$double$. + +\item +If \lstinline$int$ can represent all the values of \lstinline$unsigned short$, then the cost of an +implicit conversion from \lstinline$unsigned short$ to \lstinline$unsigned$ is 2: +\lstinline$unsigned short$ to \lstinline$int$ to \lstinline$unsigned$. Otherwise, +\lstinline$unsigned short$ is converted directly to \lstinline$unsigned$, and the cost is 1. + +\item +If \lstinline$long$ can represent all the values of \lstinline$unsigned$, then the conversion cost +of \lstinline$unsigned$ to \lstinline$long$ is 1. Otherwise, the conversion is an unsafe +conversion, and its conversion cost is undefined. +\end{itemize} + +\section{Lexical elements} +\subsection{Keywords} +\begin{syntax} +\oldlhs{keyword} + \rhs \lstinline$forall$ + \rhs \lstinline$lvalue$ + \rhs \lstinline$context$ + \rhs \lstinline$dtype$ + \rhs \lstinline$ftype$ + \rhs \lstinline$type$ +\end{syntax} + + +\subsection{Identifiers} + +\CFA allows operator overloading\index{overloading} by associating operators with special +function identifiers. Furthermore, the constants ``\lstinline$0$'' and ``\lstinline$1$'' have +special status for many of C's data types (and for many programmer-defined data types as well), so +\CFA treats them as overloadable identifiers. Programmers can use these identifiers to declare +functions and objects that implement operators and constants for their own types. + + +\setcounter{subsubsection}{2} +\subsubsection{Constant identifiers} + +\begin{syntax} +\oldlhs{identifier} +\rhs \lstinline$0$ +\rhs \lstinline$1$ +\end{syntax} + +\index{constant identifiers}\index{identifiers!for constants} The tokens ``\lstinline$0$''\impl{0} +and ``\lstinline$1$''\impl{1} are identifiers. No other tokens defined by the rules for integer +constants are considered to be identifiers. +\begin{rationale} +Why ``\lstinline$0$'' and ``\lstinline$1$''? Those integers have special status in C. All scalar +types can be incremented and decremented, which is defined in terms of adding or subtracting 1. The +operations ``\lstinline$&&$'', ``\lstinline$||$'', and ``\lstinline$!$'' can be applied to any +scalar arguments, and are defined in terms of comparison against 0. A \nonterm{constant-expression} +that evaluates to 0 is effectively compatible with every pointer type. + +In C, the integer constants 0 and 1 suffice because the integer promotion rules can convert them to +any arithmetic type, and the rules for pointer expressions treat constant expressions evaluating to +0 as a special case. However, user-defined arithmetic types often need the equivalent of a 1 or 0 +for their functions or operators, polymorphic functions often need 0 and 1 constants of a type +matching their polymorphic parameters, and user-defined pointer-like types may need a null value. +Defining special constants for a user-defined type is more efficient than defining a conversion to +the type from \lstinline$_Bool$. + +Why \emph{just} ``\lstinline$0$'' and ``\lstinline$1$''? Why not other integers? No other integers +have special status in C. A facility that let programmers declare specific +constants---``\lstinline$const Rational 12$'', for instance---would not be much of an improvement. +Some facility for defining the creation of values of programmer-defined types from arbitrary integer +tokens would be needed. The complexity of such a feature doesn't seem worth the gain. +\end{rationale} + + +\subsubsection{Operator identifiers} + +\index{operator identifiers}\index{identifiers!for operators} Table \ref{opids} lists the +programmer-definable operator identifiers and the operations they are associated with. Functions +that are declared with (or pointed at by function pointers that are declared with) these identifiers +can be called by expressions that use the operator tokens and syntax, or the operator identifiers +and ``function call'' syntax. The relationships between operators and function calls are discussed +in descriptions of the operators. + +\begin{table}[hbt] +\hfil +\begin{tabular}[t]{ll} +%identifier & operation \\ \hline +\lstinline$?[?]$ & subscripting \impl{?[?]}\\ +\lstinline$?()$ & function call \impl{?()}\\ +\lstinline$?++$ & postfix increment \impl{?++}\\ +\lstinline$?--$ & postfix decrement \impl{?--}\\ +\lstinline$++?$ & prefix increment \impl{++?}\\ +\lstinline$--?$ & prefix decrement \impl{--?}\\ +\lstinline$*?$ & dereference \impl{*?}\\ +\lstinline$+?$ & unary plus \impl{+?}\\ +\lstinline$-?$ & arithmetic negation \impl{-?}\\ +\lstinline$~?$ & bitwise negation \impl{~?}\\ +\lstinline$!?$ & logical complement \impl{"!?}\\ +\lstinline$?*?$ & multiplication \impl{?*?}\\ +\lstinline$?/?$ & division \impl{?/?}\\ +\end{tabular}\hfil +\begin{tabular}[t]{ll} +%identifier & operation \\ \hline +\lstinline$?%?$ & remainder \impl{?%?}\\ +\lstinline$?+?$ & addition \impl{?+?}\\ +\lstinline$?-?$ & subtraction \impl{?-?}\\ +\lstinline$?<>?$ & right shift \impl{?>>?}\\ +\lstinline$?=?$ & greater than or equal \impl{?>=?}\\ +\lstinline$?>?$ & greater than \impl{?>?}\\ +\lstinline$?==?$ & equality \impl{?==?}\\ +\lstinline$?!=?$ & inequality \impl{?"!=?}\\ +\lstinline$?&?$ & bitwise AND \impl{?&?}\\ +\end{tabular}\hfil +\begin{tabular}[t]{ll} +%identifier & operation \\ \hline +\lstinline$?^?$ & exclusive OR \impl{?^?}\\ +\lstinline$?|?$ & inclusive OR \impl{?"|?}\\ +\lstinline$?=?$ & simple assignment \impl{?=?}\\ +\lstinline$?*=?$ & multiplication assignment \impl{?*=?}\\ +\lstinline$?/=?$ & division assignment \impl{?/=?}\\ +\lstinline$?%=?$ & remainder assignment \impl{?%=?}\\ +\lstinline$?+=?$ & addition assignment \impl{?+=?}\\ +\lstinline$?-=?$ & subtraction assignment \impl{?-=?}\\ +\lstinline$?<<=?$ & left-shift assignment \impl{?<<=?}\\ +\lstinline$?>>=?$ & right-shift assignment \impl{?>>=?}\\ +\lstinline$?&=?$ & bitwise AND assignment \impl{?&=?}\\ +\lstinline$?^=?$ & exclusive OR assignment \impl{?^=?}\\ +\lstinline$?|=?$ & inclusive OR assignment \impl{?"|=?}\\ +\end{tabular} +\hfil +\caption{Operator Identifiers} +\label{opids} +\end{table} + +\begin{rationale} +Operator identifiers are made up of the characters of the operator token, with question marks added +to mark the positions of the arguments of operators. The question marks serve as mnemonic devices; +programmers can not create new operators by arbitrarily mixing question marks and other +non-alphabetic characters. Note that prefix and postfix versions of the increment and decrement +operators are distinguished by the position of the question mark. +\end{rationale} + +\begin{rationale} +The use of ``\lstinline$?$'' in identifiers means that some C programs are not \CFA programs. +For instance, the sequence of characters ``\lstinline$(i < 0)?--i:i$'' is legal in a C program, but +a \CFA compiler will detect a syntax error because it will treat ``\lstinline$?--$'' as an +identifier, not as the two tokens ``\lstinline$?$'' and ``\lstinline$--$''. +\end{rationale} + +\begin{rationale} +Certain operators \emph{cannot} be defined by the programmer: +\begin{itemize} +\item +The logical operators ``\lstinline$&&$'' and ``\lstinline$||$'', and the conditional operator +``\lstinline$?:$''. These operators do not always evaluate their operands, and hence can not be +properly defined by functions unless some mechanism like call-by-name is added to the language. +Note that the definitions of ``\lstinline$&&$'' and ``\lstinline$||$'' say that they work by +checking that their arguments are unequal to 0, so defining ``\lstinline$!=$'' and ``\lstinline$0$'' +for user-defined types is enough to allow them to be used in logical expressions. + +\item +The comma operator\index{comma expression}. It is a control-flow operator like those above. +Changing its meaning seems pointless and confusing. + +\item +The ``address of'' operator. It would seem useful to define a unary ``\lstinline$&$'' operator that +returns values of some programmer-defined pointer-like type. The problem lies with the type of the +operator. Consider the expression ``\lstinline$p = &x$'', where \lstinline$x$ is of type +\lstinline$T$ and \lstinline$p$ has the programmer-defined type \lstinline$T_ptr$. The expression +might be treated as a call to the unary function ``\lstinline$&?$''. Now what is the type of the +function's parameter? It can not be \lstinline$T$, because then \lstinline$x$ would be passed by +value, and there is no way to create a useful pointer-like result from a value. Hence the parameter +must have type \lstinline$T *$. But then the expression must be rewritten as ``\lstinline$p = &?( &x )$'' +---which doesn't seem like progress! + +The rule for address-of expressions would have to be something like ``keep applying address-of +functions until you get one that takes a pointer argument, then use the built-in operator and +stop''. It seems simpler to define a conversion function from \lstinline$T *$ to \lstinline$T_ptr$. + +\item +The \lstinline$sizeof$ operator. It is already defined for every object type, and intimately tied +into the language's storage allocation model. Redefining it seems pointless. + +\item +The ``member of'' operators ``\lstinline$.$'' and ``\lstinline$->$''. These are not really infix +operators, since their right ``operand'' is not a value or object. + +\item +Cast operators\index{cast expression}. Anything that can be done with an explicit cast can be done +with a function call. The difference in syntax is small. +\end{itemize} +\end{rationale} + + +\section{Expressions} +\CFA allows operators and identifiers to be overloaded. Hence, each expression can have a number +of \define{interpretations}, each of which has a different type. The interpretations that are +potentially executable are called \define{valid interpretations}. The set of interpretations +depends on the kind of expression and on the interpretations of the subexpressions that it contains. +The rules for determining the valid interpretations of an expression are discussed below for each +kind of expression. Eventually the context of the outermost expression chooses one interpretation +of that expression. + +An \define{ambiguous interpretation} is an interpretation which does not specify the exact object or +function denoted by every identifier in the expression. An expression can have some interpretations +that are ambiguous and others that are unambiguous. An expression that is chosen to be executed +shall not be ambiguous. + +The \define{best valid interpretations} are the valid interpretations that use the fewest +unsafe\index{unsafe conversions} conversions. Of these, the best are those where the functions and +objects involved are the least polymorphic\index{less polymorphic}. Of these, the best have the +lowest total conversion cost\index{conversion cost}, including all implicit conversions in the +argument expressions. Of these, the best have the highest total conversion cost for the implicit +conversions (if any) applied to the argument expressions. If there is no single best valid +interpretation, or if the best valid interpretation is ambiguous, then the resulting interpretation +is ambiguous\index{ambiguous interpretation}. + +\begin{rationale} +\CFA's rules for selecting the best interpretation are designed to allow overload resolution to +mimic C's operator semantics. In C, the ``usual arithmetic conversions'' are applied to the +operands of binary operators if necessary to convert the operands to types with a common real type. +In \CFA, those conversions are ``safe''. The ``fewest unsafe conversions'' rule ensures that the +usual conversions are done, if possible. The ``lowest total expression cost'' rule chooses the +proper common type. The odd-looking ``highest argument conversion cost'' rule ensures that, when +unary expressions must be converted, conversions of function results are preferred to conversion of +function arguments: \lstinline$(double)-i$ will be preferred to \lstinline$-(double)i$. + +The ``least polymorphic'' rule reduces the number of polymorphic function calls, since such +functions are presumably more expensive than monomorphic functions and since the more specific +function is presumably more appropriate. It also gives preference to monomorphic values (such as +the \lstinline$int$ \lstinline$0$) over polymorphic values (such as the null pointer +\lstinline$0$)\use{0}\index{null pointer}. However, interpretations that call polymorphic functions +are preferred to interpretations that perform unsafe conversions, because those conversions +potentially lose accuracy or violate strong typing. + +There are two notable differences between \CFA's overload resolution rules and the rules for +{\CC} defined in \cite{c++}. First, the result type of a function plays a role. In {\CC}, a +function call must be completely resolved based on the arguments to the call in most circumstances. +In \CFA, a function call may have several interpretations, each with a different result type, and +the interpretations of the containing context choose among them. Second, safe conversions are used +to choose among interpretations of all sorts of functions; in {\CC}, the ``usual arithmetic +conversions'' are a separate set of rules that apply only to the built-in operators. +\end{rationale} + +Expressions involving certain operators\index{operator identifiers} are considered to be equivalent +to function calls. A transformation from ``operator'' syntax to ``function call'' syntax is defined +by \define{rewrite rules}. Each operator has a set of predefined functions that overload its +identifier. Overload resolution determines which member of the set is executed in a given +expression. The functions have internal linkage\index{internal linkage} and are implicitly declared +with file scope\index{file scope}. The predefined functions and rewrite rules are discussed below +for each of these operators. +\begin{rationale} +Predefined functions and constants have internal linkage because that simplifies optimization in +traditional compile-and-link environments. For instance, ``\lstinline$an_int + an_int$'' is +equivalent to ``\lstinline$?+?(an_int, an_int)$''. If integer addition has not been redefined in +the current scope, a compiler can generate code to perform the addition directly. If predefined +functions had external linkage, this optimization would be difficult. +\end{rationale} + +\begin{rationale} +Since each subsection describes the interpretations of an expression in terms of the interpretations +of its subexpressions, this chapter can be taken as describing an overload resolution algorithm that +uses one bottom-up pass over an expression tree. Such an algorithm was first described (for Ada) by +Baker \cite{Bak:overload}. It is extended here to handle polymorphic functions and arithmetic +conversions. The overload resolution rules and the predefined functions have been chosen so that, +in programs that do not introduce overloaded declarations, expressions will have the same meaning in +C and in \CFA. +\end{rationale} + +\begin{rationale} +Expression syntax is quoted from the {\c11} standard. The syntax itself defines the precedence and +associativity of operators. The sections are arranged in decreasing order of precedence, with all +operators in a section having the same precedence. +\end{rationale} + +\subsection{Primary expressions} +\begin{syntax} +\lhs{primary-expression} +\rhs \nonterm{identifier} +\rhs \nonterm{constant} +\rhs \nonterm{string-literal} +\rhs \lstinline$($ \nonterm{expression} \lstinline$)$ +\rhs \nonterm{generic-selection} +\end{syntax} + +\paragraph{Predefined Identifiers}% +\begin{lstlisting} +const int 1;@\use{1}@ +const int 0;@\use{0}@ +forall( dtype DT ) DT *const 0; +forall( ftype FT ) FT *const 0; +\end{lstlisting} + +\semantics +The valid interpretations\index{valid interpretations} of an \nonterm{identifier} are given by the +visible\index{visible} declarations of the identifier. + +A \nonterm{constant} or \nonterm{string-literal} has one valid interpretation, which has the type +and value defined by {\c11}. The predefined integer identifiers ``\lstinline$1$'' and +``\lstinline$0$'' have the integer values 1 and 0, respectively. The other two predefined +``\lstinline$0$'' identifiers are bound to polymorphic pointer values that, when +specialized\index{specialization} with a data type or function type respectively, produce a null +pointer of that type. + +A parenthesised expression has the same interpretations as the contained \nonterm{expression}. + +\examples +The expression \lstinline$(void *)0}$\use{0} specializes the (polymorphic) null pointer to a null +pointer to \lstinline$void$. \lstinline$(const void *)0$ does the same, and also uses a safe +conversion from \lstinline$void *$ to \lstinline$const void *$. In each case, the null pointer +conversion is better\index{best valid interpretations} than the unsafe conversion of the integer +\lstinline$0$ to a pointer. + +\begin{rationale} +Note that the predefined identifiers have addresses. + +\CFA does not have C's concept of ``null pointer constants'', which are not typed values but +special strings of tokens. The C token ``\lstinline$0$'' is an expression of type \lstinline$int$ +with the value ``zero'', and it \emph{also} is a null pointer constant. Similarly, +``\lstinline$(void *)0$ is an expression of type \lstinline$(void *)$ whose value is a null pointer, +and it also is a null pointer constant. However, in C, ``\lstinline$(void *)(void *)0$'' is +\emph{not} a null pointer constant, even though it is null-valued, a pointer, and constant! The +semantics of C expressions contain many special cases to deal with subexpressions that are null +pointer constants. + +\CFA handles these cases through overload resolution. The declaration +\begin{lstlisting} +forall( dtype DT ) DT *const 0; +\end{lstlisting} +means that \lstinline$0$ is a polymorphic object, and contains a value that can have \emph{any} +pointer-to-object type or pointer-to-incomplete type. The only such value is the null pointer. +Therefore the type \emph{alone} is enough to identify a null pointer. Where C defines an operator +with a special case for the null pointer constant, \CFA defines predefined functions with a +polymorphic object parameter. +\end{rationale} + +\subsubsection{Generic selection} +\constraints The best interpretation of the controlling expression shall be +unambiguous\index{ambiguous interpretation}, and shall have type compatible with at most one of the +types named in its generic association list. If a generic selection has no \lstinline$default$ +generic association, the best interpretation of its controlling expression shall have type +compatible with exactly one of the types named in its generic association list. + +\semantics +A generic selection has the same interpretations as its result expression. + + +\subsection{Postfix operators} + +\begin{syntax} +\lhs{postfix-expression} +\rhs \nonterm{primary-expression} +\rhs \nonterm{postfix-expression} \lstinline$[$ \nonterm{expression} \lstinline$]$ +\rhs \nonterm{postfix-expression} \lstinline$($ + \nonterm{argument-expression-list}\opt \lstinline$)$ +\rhs \nonterm{postfix-expression} \lstinline$.$ \nonterm{identifier} +\rhs \nonterm{postfix-expression} \lstinline$->$ \nonterm{identifier} +\rhs \nonterm{postfix-expression} \lstinline$++$ +\rhs \nonterm{postfix-expression} \lstinline$--$ +\rhs \lstinline$($ \nonterm{type-name} \lstinline$)$ \lstinline${$ \nonterm{initializer-list} \lstinline$}$ +\rhs \lstinline$($ \nonterm{type-name} \lstinline$)$ \lstinline${$ \nonterm{initializer-list} \lstinline$,$ \lstinline$}$ +\lhs{argument-expression-list} +\rhs \nonterm{assignment-expression} +\rhs \nonterm{argument-expression-list} \lstinline$,$ + \nonterm{assignment-expression} +\end{syntax} + +\rewriterules +\begin{lstlisting} +a[b] @\rewrite@ ?[?]( b, a ) // if a has integer type */@\use{?[?]}@ +a[b] @\rewrite@ ?[?]( a, b ) // otherwise +a( ${\em arguments }$ ) @\rewrite@ ?()( a, ${\em arguments} )$@\use{?()}@ +a++ @\rewrite@ ?++(&( a ))@\use{?++}@ +a-- @\rewrite@ ?--(&( a ))@\use{?--}@ +\end{lstlisting} + +\subsubsection{Array subscripting} +\begin{lstlisting} +forall( type T ) lvalue T ?[?]( T *, ptrdiff_t );@\use{ptrdiff_t}@ +forall( type T ) lvalue _Atomic T ?[?]( _Atomic T *, ptrdiff_t ); +forall( type T ) lvalue const T ?[?]( const T *, ptrdiff_t ); +forall( type T ) lvalue restrict T ?[?]( restrict T *, ptrdiff_t ); +forall( type T ) lvalue volatile T ?[?]( volatile T *, ptrdiff_t ); +forall( type T ) lvalue _Atomic const T ?[?]( _Atomic const T *, ptrdiff_t ); +forall( type T ) lvalue _Atomic restrict T ?[?]( _Atomic restrict T *, ptrdiff_t ); +forall( type T ) lvalue _Atomic volatile T ?[?]( _Atomic volatile T *, ptrdiff_t ); +forall( type T ) lvalue const restrict T ?[?]( const restrict T *, ptrdiff_t ); +forall( type T ) lvalue const volatile T ?[?]( const volatile T *, ptrdiff_t ); +forall( type T ) lvalue restrict volatile T ?[?]( restrict volatile T *, ptrdiff_t ); +forall( type T ) lvalue _Atomic const restrict T ?[?]( _Atomic const restrict T *, ptrdiff_t ); +forall( type T ) lvalue _Atomic const volatile T ?[?]( _Atomic const volatile T *, ptrdiff_t ); +forall( type T ) lvalue _Atomic restrict volatile T ?[?]( _Atomic restrict volatile T *, ptrdiff_t ); +forall( type T ) lvalue const restrict volatile T ?[?]( const restrict volatile T *, ptrdiff_t ); +forall( type T ) lvalue _Atomic const restrict volatile T ?[?]( _Atomic const restrict volatile T *, ptrdiff_t ); +\end{lstlisting} +\semantics +The interpretations of subscript expressions are the interpretations of the corresponding function +call expressions. +\begin{rationale} +C defines subscripting as pointer arithmetic in a way that makes \lstinline$a[i]$ and +\lstinline$i[a]$ equivalent. \CFA provides the equivalence through a rewrite rule to reduce the +number of overloadings of \lstinline$?[?]$. + +Subscript expressions are rewritten as function calls that pass the first parameter by value. This +is somewhat unfortunate, since array-like types tend to be large. The alternative is to use the +rewrite rule ``\lstinline$a[b]$ \rewrite \lstinline$?[?](&(a), b)$''. However, C semantics forbid +this approach: the \lstinline$a$ in ``\lstinline$a[b]$'' can be an arbitrary pointer value, which +does not have an address. + +The repetitive form of the predefined identifiers shows up a deficiency\index{deficiencies!pointers + to qualified types} of \CFA's type system. Type qualifiers are not included in type values, so +polymorphic functions that take pointers to arbitrary types often come in one flavor for each +possible qualification of the pointed-at type. +\end{rationale} + + +\subsubsection{Function calls} + +\semantics +A \define{function designator} is an interpretation of an expression that has function type. The +\nonterm{postfix-expression} in a function call may have some interpretations that are function +designators and some that are not. + +For those interpretations of the \nonterm{postfix-expression} that are not function designators, the +expression is rewritten and becomes a call of a function named ``\lstinline$?()$''. The valid +interpretations of the rewritten expression are determined in the manner described below. + +Each combination of function designators and argument interpretations is considered. For those +interpretations of the \nonterm{postfix-expression} that are monomorphic\index{monomorphic function} +function designators, the combination has a valid interpretation\index{valid interpretations} if the +function designator accepts the number of arguments given, and each argument interpretation matches +the corresponding explicit parameter: +\begin{itemize} +\item +if the argument corresponds to a parameter in the function designator's prototype, the argument +interpretation must have the same type as the corresponding parameter, or be implicitly convertible +to the parameter's type +\item +if the function designator's type does not include a prototype or if the argument corresponds to +``\lstinline$...$'' in a prototype, a default argument promotion\index{default argument promotions} +is applied to it. +\end{itemize} +The type of the valid interpretation is the return type of the function designator. + +For those combinations where the interpretation of the \nonterm{postfix-expression} is a +polymorphic\index{polymorphic function} function designator and the function designator accepts the +number of arguments given, there shall be at least one set of \define{implicit arguments} for the +implicit parameters such that +\begin{itemize} +\item +If the declaration of the implicit parameter uses type-class\index{type-class} +\lstinline$type$\use{type}, the implicit argument must be an object type; if it uses +\lstinline$dtype$, the implicit argument must be an object type or an incomplete type; and if it +uses \lstinline$ftype$, the implicit argument must be a function type. + +\item +if an explicit parameter's type uses any implicit parameters, then the corresponding explicit +argument must have a type that is (or can be safely converted\index{safe conversions} to) the type +produced by substituting the implicit arguments for the implicit parameters in the explicit +parameter type. + +\item +the remaining explicit arguments must match the remaining explicit parameters, as described for +monomorphic function designators. + +\item +for each assertion parameter\index{assertion parameters} in the function designator's type, there +must be an object or function with the same identifier that is visible at the call site and whose +type is compatible with or can be specialized to the type of the assertion declaration. +\end{itemize} +There is a valid interpretation for each such set of implicit parameters. The type of each valid +interpretation is the return type of the function designator with implicit parameter values +substituted for the implicit arguments. + +A valid interpretation is ambiguous\index{ambiguous interpretation} if the function designator or +any of the argument interpretations is ambiguous. + +Every valid interpretation whose return type is not compatible with any other valid interpretation's +return type is an interpretation of the function call expression. + +Every set of valid interpretations that have mutually compatible\index{compatible type} result types +also produces an interpretation of the function call expression. The type of the interpretation is +the composite\index{composite type} type of the types of the valid interpretations, and the value of +the interpretation is that of the best valid interpretation\index{best valid interpretations}. +\begin{rationale} +One desirable property of a polymorphic programming language is \define{generalizability}: the +ability to replace an abstraction with a more general but equivalent abstraction without requiring +changes in any of the uses of the original\cite{Cormack90}. For instance, it should be possible to +replace a function ``\lstinline$int f( int );$'' with ``\lstinline$forall( type T ) T f( T );$'' +without affecting any calls of \lstinline$f$. + +\CFA\index{deficiencies!generalizability} does not fully possess this property, because +unsafe\index{unsafe conversions} conversions are not done when arguments are passed to polymorphic +parameters. Consider +\begin{lstlisting} +float g( float, float ); +int i; +float f; +double d; +f = g( f, f ); // (1) +f = g( i, f ); // (2) (safe conversion to float) +f = g( d, f ); // (3) (unsafe conversion to float) +\end{lstlisting} +If \lstinline$g$ was replaced by ``\lstinline$forall( type T ) T g( T, T );$'', the first and second +calls would be unaffected, but the third would change: \lstinline$f$ would be converted to +\lstinline$double$, and the result would be a \lstinline$double$. + +Another example is the function ``\lstinline$void h( int *);$''. This function can be passed a +\lstinline$void *$ argument, but the generalization ``\lstinline$forall( type T ) void h( T *);$'' +can not. In this case, \lstinline$void$ is not a valid value for \lstinline$T$ because it is not an +object type. If unsafe conversions were allowed, \lstinline$T$ could be inferred to be \emph{any} +object type, which is undesirable. +\end{rationale} + +\examples +A function called ``\lstinline$?()$'' might be part of a numerical differentiation package. +\begin{lstlisting} +extern type Derivative; +extern double ?()( Derivative, double ); +extern Derivative derivative_of( double (*f)( double ) ); +extern double sin( double ); + +Derivative sin_dx = derivative_of( sin ); +double d; +d = sin_dx( 12.9 ); +\end{lstlisting} +Here, the only interpretation of \lstinline$sin_dx$ is as an object of type \lstinline$Derivative$. +For that interpretation, the function call is treated as ``\lstinline$?()( sin_dx, 12.9 )$''. +\begin{lstlisting} +int f( long ); // (1) +int f( int, int ); // (2) +int f( int *); // (3) + +int i = f( 5 ); // calls (1) +\end{lstlisting} +Function (1) provides a valid interpretation of ``\lstinline$f( 5 )$'', using an implicit +\lstinline$int$ to \lstinline$long$ conversion. The other functions do not, since the second +requires two arguments, and since there is no implicit conversion from \lstinline$int$ to +\lstinline$int *$ that could be used with the third function. + +\begin{lstlisting} +forall( type T ) T h( T ); +double d = h( 1.5 ); +\end{lstlisting} +``\lstinline$1.5$'' is a \lstinline$double$ constant, so \lstinline$T$ is inferred to be +\lstinline$double$, and the result of the function call is a \lstinline$double$. + +\begin{lstlisting} +forall( type T, type U ) void g( T, U ); // (4) +forall( type T ) void g( T, T ); // (5) +forall( type T ) void g( T, long ); // (6) +void g( long, long ); // (7) +double d; +int i; +int *p; + +g( d, d ); // calls (5) +g( d, i ); // calls (6) +g( i, i ); // calls (7) +g( i, p ); // calls (4) +\end{lstlisting} +The first call has valid interpretations for all four versions of \lstinline$g$. (6) and (7) are +discarded because they involve unsafe \lstinline$double$-to-\lstinline$long$ conversions. (5) is +chosen because it is less polymorphic than (4). + +For the second call, (7) is again discarded. Of the remaining interpretations for (4), (5), and (6) +(with \lstinline$i$ converted to \lstinline$long$), (6) is chosen because it is the least +polymorphic. + +The third call has valid interpretations for all of the functions; (7) is chosen since it is not +polymorphic at all. + +The fourth call has no interpretation for (5), because its arguments must have compatible type. (4) +is chosen because it does not involve unsafe conversions. +\begin{lstlisting} +forall( type T ) T min( T, T ); +double max( double, double ); +context min_max( T ) {@\impl{min_max}@ + T min( T, T ); + T max( T, T ); +} +forall( type U | min_max( U ) ) void shuffle( U, U ); +shuffle(9, 10); +\end{lstlisting} +The only possibility for \lstinline$U$ is \lstinline$double$, because that is the type used in the +only visible \lstinline$max$ function. 9 and 10 must be converted to \lstinline$double$, and +\lstinline$min$ must be specialized with \lstinline$T$ bound to \lstinline$double$. +\begin{lstlisting} +extern void q( int ); // (8) +extern void q( void * ); // (9) +extern void r(); +q( 0 ); +r( 0 ); +\end{lstlisting} +The \lstinline$int 0$ could be passed to (8), or the \lstinline$(void *)$ +specialization\index{specialization} of the null pointer\index{null pointer} \lstinline$0$\use{0} +could be passed to (9). The former is chosen because the \lstinline$int$ \lstinline$0$ is less +polymorphic\index{less polymorphic}. For the same reason, \lstinline$int$ \lstinline$0$ is passed +to \lstinline$r()$, even though it has \emph{no} declared parameter types. + + +\subsubsection{Structure and union members} + +\semantics In the member selection expression ``\lstinline$s$.\lstinline$m$'', there shall be at +least one interpretation of \lstinline$s$ whose type is a structure type or union type containing a +member named \lstinline$m$. If two or more interpretations of \lstinline$s$ have members named +\lstinline$m$ with mutually compatible types, then the expression has an ambiguous +interpretation\index{ambiguous interpretation} whose type is the composite type of the types of the +members. If an interpretation of \lstinline$s$ has a member \lstinline$m$ whose type is not +compatible with any other \lstinline$s$'s \lstinline$m$, then the expression has an interpretation +with the member's type. The expression has no other interpretations. + +The expression ``\lstinline$p->m$'' has the same interpretations as the expression +``\lstinline$(*p).m$''. + + +\subsubsection{Postfix increment and decrement operators} + +\begin{lstlisting} +_Bool ?++( volatile _Bool * ), + ?++( _Atomic volatile _Bool * ); +char ?++( volatile char * ), + ?++( _Atomic volatile char * ); +signed char ?++( volatile signed char * ), + ?++( _Atomic volatile signed char * ); +unsigned char ?++( volatile signed char * ), + ?++( _Atomic volatile signed char * ); +short int ?++( volatile short int * ), + ?++( _Atomic volatile short int * ); +unsigned short int ?++( volatile unsigned short int * ), + ?++( _Atomic volatile unsigned short int * ); +int ?++( volatile int * ), + ?++( _Atomic volatile int * ); +unsigned int ?++( volatile unsigned int * ), + ?++( _Atomic volatile unsigned int * ); +long int ?++( volatile long int * ), + ?++( _Atomic volatile long int * ); +long unsigned int ?++( volatile long unsigned int * ), + ?++( _Atomic volatile long unsigned int * ); +long long int ?++( volatile long long int * ), + ?++( _Atomic volatile long long int * ); +long long unsigned ?++( volatile long long unsigned int * ), + ?++( _Atomic volatile long long unsigned int * ); +float ?++( volatile float * ), + ?++( _Atomic volatile float * ); +double ?++( volatile double * ), + ?++( _Atomic volatile double * ); +long double ?++( volatile long double * ), + ?++( _Atomic volatile long double * ); + +forall( type T ) T * ?++( T * restrict volatile * ), + * ?++( T * _Atomic restrict volatile * ); + +forall( type T ) _Atomic T * ?++( _Atomic T * restrict volatile * ), + * ?++( _Atomic T * _Atomic restrict volatile * ); + +forall( type T ) const T * ?++( const T * restrict volatile * ), + * ?++( const T * _Atomic restrict volatile * ); + +forall( type T ) volatile T * ?++( volatile T * restrict volatile * ), + * ?++( volatile T * _Atomic restrict volatile * ); + +forall( type T ) restrict T * ?++( restrict T * restrict volatile * ), + * ?++( restrict T * _Atomic restrict volatile * ); + +forall( type T ) _Atomic const T * ?++( _Atomic const T * restrict volatile * ), + * ?++( _Atomic const T * _Atomic restrict volatile * ); + +forall( type T ) _Atomic restrict T * ?++( _Atomic restrict T * restrict volatile * ), + * ?++( _Atomic restrict T * _Atomic restrict volatile * ); + +forall( type T ) _Atomic volatile T * ?++( _Atomic volatile T * restrict volatile * ), + * ?++( _Atomic volatile T * _Atomic restrict volatile * ); + +forall( type T ) const restrict T * ?++( const restrict T * restrict volatile * ), + * ?++( const restrict T * _Atomic restrict volatile * ); + +forall( type T ) const volatile T * ?++( const volatile T * restrict volatile * ), + * ?++( const volatile T * _Atomic restrict volatile * ); + +forall( type T ) restrict volatile T * ?++( restrict volatile T * restrict volatile * ), + * ?++( restrict volatile T * _Atomic restrict volatile * ); + +forall( type T ) _Atomic const restrict T * ?++( _Atomic const restrict T * restrict volatile * ), + * ?++( _Atomic const restrict T * _Atomic restrict volatile * ); + +forall( type T ) _Atomic const volatile T * ?++( _Atomic const volatile T * restrict volatile * ), + * ?++( _Atomic const volatile T * _Atomic restrict volatile * ); + +forall( type T ) _Atomic restrict volatile T * ?++( _Atomic restrict volatile T * restrict volatile * ), + * ?++( _Atomic restrict volatile T * _Atomic restrict volatile * ); + +forall( type T ) const restrict volatile T * ?++( const restrict volatile T * restrict volatile * ), + * ?++( const restrict volatile T * _Atomic restrict volatile * ); + +forall( type T ) _Atomic const restrict volatile T * ?++( _Atomic const restrict volatile T * restrict volatile * ), + * ?++( _Atomic const restrict volatile T * _Atomic restrict volatile * ); + +_Bool ?--( volatile _Bool * ), + ?--( _Atomic volatile _Bool * ); +char ?--( volatile char * ), + ?--( _Atomic volatile char * ); +signed char ?--( volatile signed char * ), + ?--( _Atomic volatile signed char * ); +unsigned char ?--( volatile signed char * ), + ?--( _Atomic volatile signed char * ); +short int ?--( volatile short int * ), + ?--( _Atomic volatile short int * ); +unsigned short int ?--( volatile unsigned short int * ), + ?--( _Atomic volatile unsigned short int * ); +int ?--( volatile int * ), + ?--( _Atomic volatile int * ); +unsigned int ?--( volatile unsigned int * ), + ?--( _Atomic volatile unsigned int * ); +long int ?--( volatile long int * ), + ?--( _Atomic volatile long int * ); +long unsigned int ?--( volatile long unsigned int * ), + ?--( _Atomic volatile long unsigned int * ); +long long int ?--( volatile long long int * ), + ?--( _Atomic volatile long long int * ); +long long unsigned ?--( volatile long long unsigned int * ), + ?--( _Atomic volatile long long unsigned int * ); +float ?--( volatile float * ), + ?--( _Atomic volatile float * ); +double ?--( volatile double * ), + ?--( _Atomic volatile double * ); +long double ?--( volatile long double * ), + ?--( _Atomic volatile long double * ); + +forall( type T ) T * ?--( T * restrict volatile * ), + * ?--( T * _Atomic restrict volatile * ); + +forall( type T ) _Atomic T * ?--( _Atomic T * restrict volatile * ), + * ?--( _Atomic T * _Atomic restrict volatile * ); + +forall( type T ) const T * ?--( const T * restrict volatile * ), + * ?--( const T * _Atomic restrict volatile * ); + +forall( type T ) volatile T * ?--( volatile T * restrict volatile * ), + * ?--( volatile T * _Atomic restrict volatile * ); + +forall( type T ) restrict T * ?--( restrict T * restrict volatile * ), + * ?--( restrict T * _Atomic restrict volatile * ); + +forall( type T ) _Atomic const T * ?--( _Atomic const T * restrict volatile * ), + * ?--( _Atomic const T * _Atomic restrict volatile * ); + +forall( type T ) _Atomic restrict T * ?--( _Atomic restrict T * restrict volatile * ), + * ?--( _Atomic restrict T * _Atomic restrict volatile * ); + +forall( type T ) _Atomic volatile T * ?--( _Atomic volatile T * restrict volatile * ), + * ?--( _Atomic volatile T * _Atomic restrict volatile * ); + +forall( type T ) const restrict T * ?--( const restrict T * restrict volatile * ), + * ?--( const restrict T * _Atomic restrict volatile * ); + +forall( type T ) const volatile T * ?--( const volatile T * restrict volatile * ), + * ?--( const volatile T * _Atomic restrict volatile * ); + +forall( type T ) restrict volatile T * ?--( restrict volatile T * restrict volatile * ), + * ?--( restrict volatile T * _Atomic restrict volatile * ); + +forall( type T ) _Atomic const restrict T * ?--( _Atomic const restrict T * restrict volatile * ), + * ?--( _Atomic const restrict T * _Atomic restrict volatile * ); + +forall( type T ) _Atomic const volatile T * ?--( _Atomic const volatile T * restrict volatile * ), + * ?--( _Atomic const volatile T * _Atomic restrict volatile * ); + +forall( type T ) _Atomic restrict volatile T * ?--( _Atomic restrict volatile T * restrict volatile * ), + * ?--( _Atomic restrict volatile T * _Atomic restrict volatile * ); + +forall( type T ) const restrict volatile T * ?--( const restrict volatile T * restrict volatile * ), + * ?--( const restrict volatile T * _Atomic restrict volatile * ); + +forall( type T ) _Atomic const restrict volatile T * ?--( _Atomic const restrict volatile T * restrict volatile * ), + * ?--( _Atomic const restrict volatile T * _Atomic restrict volatile * ); +\end{lstlisting} +For every extended integer type \lstinline$X$ there exist +% Don't use predefined: keep this out of prelude.cf. +\begin{lstlisting} +X ?++( volatile X * ), ?++( _Atomic volatile X * ), + ?--( volatile X * ), ?--( _Atomic volatile X * ); +\end{lstlisting} +For every complete enumerated type \lstinline$E$ there exist +% Don't use predefined: keep this out of prelude.cf. +\begin{lstlisting} +E ?++( volatile E * ), ?++( _Atomic volatile E * ), + ?--( volatile E * ), ?--( _Atomic volatile E * ); +\end{lstlisting} + +\begin{rationale} +Note that ``\lstinline$++$'' and ``\lstinline$--$'' are rewritten as function calls that are given a +pointer to that operand. (This is true of all operators that modify an operand.) As Hamish Macdonald +has pointed out, this forces the modified operand of such expressions to be an lvalue. This +partially enforces the C semantic rule that such operands must be \emph{modifiable} lvalues. +\end{rationale} + +\begin{rationale} +In C, a semantic rule requires that pointer operands of increment and decrement be pointers to +object types. Hence, \lstinline$void *$ objects cannot be incremented. In \CFA, the restriction +follows from the use of a \lstinline$type$ parameter in the predefined function definitions, as +opposed to \lstinline$dtype$, since only object types can be inferred arguments corresponding to the +type parameter \lstinline$T$. +\end{rationale} + +\semantics +First, each interpretation of the operand of an increment or decrement expression is considered +separately. For each interpretation that is a bit-field or is declared with the +\lstinline$register$\index{register@{\lstinline$register$}} storage-class +specifier\index{storage-class specifier}, the expression has one valid interpretation, with the type +of the operand, and the expression is ambiguous if the operand is. + +For the remaining interpretations, the expression is rewritten, and the interpretations of the +expression are the interpretations of the corresponding function call. Finally, all interpretations +of the expression produced for the different interpretations of the operand are combined to produce +the interpretations of the expression as a whole; where interpretations have compatible result +types, the best interpretations are selected in the manner described for function call expressions. + +\examples +\begin{lstlisting} +volatile short int vs; vs++; // rewritten as ?++( &(vs) ) +short int s; s++; +const short int cs; cs++; +_Atomic short int as; as++; +\end{lstlisting} +\begin{sloppypar} +Since \lstinline$&(vs)$ has type \lstinline$volatile short int *$, the best valid interpretation of +\lstinline$vs++$ calls the \lstinline$?++$ function with the \lstinline$volatile short *$ parameter. +\lstinline$s++$ does the same, applying the safe conversion from \lstinline$short int *$ to +\lstinline$volatile short int *$. Note that there is no conversion that adds an \lstinline$_Atomic$ +qualifier, so the \lstinline$_Atomic volatile short int$ overloading does not provide a valid +interpretation. +\end{sloppypar} + +There is no safe conversion from \lstinline$const short int *$ to \lstinline$volatile short int *$, +and no \lstinline$?++$ function that accepts a \lstinline$const *$ parameter, so \lstinline$cs++$ +has no valid interpretations. + +The best valid interpretation of \lstinline$as++$ calls the \lstinline$short ?++$ function with the +\lstinline$_Atomic volatile short int *$ parameter, applying a safe conversion to add the +\lstinline$volatile$ qualifier. + +\begin{lstlisting} +char * const restrict volatile * restrict volatile pqpc; pqpc++ +char * * restrict volatile ppc; ppc++; +\end{lstlisting} +Since \lstinline$&(pqpc)$ has type \lstinline$char * const restrict volatile * restrict volatile *$, +the best valid interpretation of \lstinline$pqpc++$ calls the polymorphic \lstinline$?++$ function +with the \lstinline$const restrict volatile T * restrict volatile *$ parameter, inferring +\lstinline$T$ to be \lstinline$char *$. + +\begin{sloppypar} +\lstinline$ppc++$ calls the same function, again inferring \lstinline$T$ to be \lstinline$char *$, +and using the safe conversions from \lstinline$T$ to \lstinline$T const restrict volatile$. +\end{sloppypar} + +\begin{rationale} +Increment and decrement expressions show up a deficiency of \CFA's type system. There is no such +thing as a pointer to a register object or bit-field\index{deficiencies!pointers to bit-fields}. +Therefore, there is no way to define a function that alters them, and hence no way to define +increment and decrement functions for them. As a result, the semantics of increment and decrement +expressions must treat them specially. This holds true for all of the operators that may modify +such objects. +\end{rationale} + +\begin{rationale} +The polymorphic overloadings for pointer increment and decrement can be understood by considering +increasingly complex types. +\begin{enumerate} +\item +``\lstinline$char * p; p++;$''. The argument to \lstinline$?++$ has type \lstinline$char * *$, and +the result has type \lstinline$char *$. The expression would be valid if \lstinline$?++$ were +declared by +\begin{lstlisting} +forall( type T ) T * ?++( T * * ); +\end{lstlisting} +with \lstinline$T$ inferred to be \lstinline$char$. + +\item +``\lstinline$char *restrict volatile qp; qp++$''. The result again has type \lstinline$char *$, but +the argument now has type \lstinline$char *restrict volatile *$, so it cannot be passed to the +hypothetical function declared in point 1. Hence the actual predefined function is +\begin{lstlisting} +forall( type T ) T * ?++( T * restrict volatile * ); +\end{lstlisting} +which also accepts a \lstinline$char * *$ argument, because of the safe conversions that add +\lstinline$volatile$ and \lstinline$restrict$ qualifiers. (The parameter is not const-qualified, so +constant pointers cannot be incremented.) + +\item +``\lstinline$char *_Atomic ap; ap++$''. The result again has type \lstinline$char *$, but no safe +conversion adds an \lstinline$_Atomic$ qualifier, so the function in point 2 is not applicable. A +separate overloading of \lstinline$?++$ is required. + +\item +``\lstinline$char const volatile * pq; pq++$''. Here the result has type +\lstinline$char const volatile *$, so a new overloading is needed: +\begin{lstlisting} +forall( type T ) T const volatile * ?++( T const volatile *restrict volatile * ); +\end{lstlisting} +One overloading is needed for each combination of qualifiers in the pointed-at +type\index{deficiencies!pointers to qualified types}. + +\item +``\lstinline$float *restrict * prp; prp++$''. The \lstinline$restrict$ qualifier is handled just +like \lstinline$const$ and \lstinline$volatile$ in the previous case: +\begin{lstlisting} +forall( type T ) T restrict * ?++( T restrict *restrict volatile * ); +\end{lstlisting} +with \lstinline$T$ inferred to be \lstinline$float *$. This looks odd, because {\c11} contains a +constraint that requires restrict-qualified types to be pointer-to-object types, and \lstinline$T$ +is not syntactically a pointer type. \CFA loosens the constraint. +\end{enumerate} +\end{rationale} + + +\subsubsection{Compound literals} + +\semantics +A compound literal has one interpretation, with the type given by the \nonterm{type-name} of the +compound literal. + + +\subsection{Unary operators} + +\begin{syntax} +\lhs{unary-expression} +\rhs \nonterm{postfix-expression} +\rhs \lstinline$++$ \nonterm{unary-expression} +\rhs \lstinline$--$ \nonterm{unary-expression} +\rhs \nonterm{unary-operator} \nonterm{cast-expression} +\rhs \lstinline$sizeof$ \nonterm{unary-expression} +\rhs \lstinline$sizeof$ \lstinline$($ \nonterm{type-name} \lstinline$)$ +\lhs{unary-operator} one of \rhs \lstinline$&$ \lstinline$*$ \lstinline$+$ \lstinline$-$ \lstinline$~$ \lstinline$!$ +\end{syntax} + +\rewriterules +\begin{lstlisting} +*a @\rewrite@ *?(a) @\use{*?}@ ++a @\rewrite@ +?(a) @\use{+?}@ +-a @\rewrite@ -?(a) @\use{-?}@ +~a @\rewrite@ ~?(a) @\use{~?}@ +!a @\rewrite@ !?(a) @\use{"!?}@ +++a @\rewrite@ ++?(&(a)) @\use{++?}@ +--a @\rewrite@ --?(&(a)) @\use{--?}@ +\end{lstlisting} + + +\subsubsection{Prefix increment and decrement operators} + +\begin{lstlisting} +_Bool ++?( volatile _Bool * ), + ++?( _Atomic volatile _Bool * ); +char ++?( volatile char * ), + ++?( _Atomic volatile char * ); +signed char ++?( volatile signed char * ), + ++?( _Atomic volatile signed char * ); +unsigned char ++?( volatile signed char * ), + ++?( _Atomic volatile signed char * ); +short int ++?( volatile short int * ), + ++?( _Atomic volatile short int * ); +unsigned short int ++?( volatile unsigned short int * ), + ++?( _Atomic volatile unsigned short int * ); +int ++?( volatile int * ), + ++?( _Atomic volatile int * ); +unsigned int ++?( volatile unsigned int * ), + ++?( _Atomic volatile unsigned int * ); +long int ++?( volatile long int * ), + ++?( _Atomic volatile long int * ); +long unsigned int ++?( volatile long unsigned int * ), + ++?( _Atomic volatile long unsigned int * ); +long long int ++?( volatile long long int * ), + ++?( _Atomic volatile long long int * ); +long long unsigned ++?( volatile long long unsigned int * ), + ++?( _Atomic volatile long long unsigned int * ); +float ++?( volatile float * ), + ++?( _Atomic volatile float * ); +double ++?( volatile double * ), + ++?( _Atomic volatile double * ); +long double ++?( volatile long double * ), + ++?( _Atomic volatile long double * ); + +forall( type T ) T * ++?( T * restrict volatile * ), + * ++?( T * _Atomic restrict volatile * ); + +forall( type T ) _Atomic T * ++?( _Atomic T * restrict volatile * ), + * ++?( _Atomic T * _Atomic restrict volatile * ); + +forall( type T ) const T * ++?( const T * restrict volatile * ), + * ++?( const T * _Atomic restrict volatile * ); + +forall( type T ) volatile T * ++?( volatile T * restrict volatile * ), + * ++?( volatile T * _Atomic restrict volatile * ); + +forall( type T ) restrict T * ++?( restrict T * restrict volatile * ), + * ++?( restrict T * _Atomic restrict volatile * ); + +forall( type T ) _Atomic const T * ++?( _Atomic const T * restrict volatile * ), + * ++?( _Atomic const T * _Atomic restrict volatile * ); + +forall( type T ) _Atomic volatile T * ++?( _Atomic volatile T * restrict volatile * ), + * ++?( _Atomic volatile T * _Atomic restrict volatile * ); + +forall( type T ) _Atomic restrict T * ++?( _Atomic restrict T * restrict volatile * ), + * ++?( _Atomic restrict T * _Atomic restrict volatile * ); + +forall( type T ) const volatile T * ++?( const volatile T * restrict volatile * ), + * ++?( const volatile T * _Atomic restrict volatile * ); + +forall( type T ) const restrict T * ++?( const restrict T * restrict volatile * ), + * ++?( const restrict T * _Atomic restrict volatile * ); + +forall( type T ) restrict volatile T * ++?( restrict volatile T * restrict volatile * ), + * ++?( restrict volatile T * _Atomic restrict volatile * ); + +forall( type T ) _Atomic const volatile T * ++?( _Atomic const volatile T * restrict volatile * ), + * ++?( _Atomic const volatile T * _Atomic restrict volatile * ); + +forall( type T ) _Atomic const restrict T * ++?( _Atomic const restrict T * restrict volatile * ), + * ++?( _Atomic const restrict T * _Atomic restrict volatile * ); + +forall( type T ) _Atomic restrict volatile T * ++?( _Atomic restrict volatile T * restrict volatile * ), + * ++?( _Atomic restrict volatile T * _Atomic restrict volatile * ); + +forall( type T ) const restrict volatile T * ++?( const restrict volatile T * restrict volatile * ), + * ++?( const restrict volatile T * _Atomic restrict volatile * ); + +forall( type T ) _Atomic const restrict volatile T * ++?( _Atomic const restrict volatile T * restrict volatile * ), + * ++?( _Atomic const restrict volatile T * _Atomic restrict volatile * ); + +_Bool --?( volatile _Bool * ), + --?( _Atomic volatile _Bool * ); +char --?( volatile char * ), + --?( _Atomic volatile char * ); +signed char --?( volatile signed char * ), + --?( _Atomic volatile signed char * ); +unsigned char --?( volatile signed char * ), + --?( _Atomic volatile signed char * ); +short int --?( volatile short int * ), + --?( _Atomic volatile short int * ); +unsigned short int --?( volatile unsigned short int * ), + --?( _Atomic volatile unsigned short int * ); +int --?( volatile int * ), + --?( _Atomic volatile int * ); +unsigned int --?( volatile unsigned int * ), + --?( _Atomic volatile unsigned int * ); +long int --?( volatile long int * ), + --?( _Atomic volatile long int * ); +long unsigned int --?( volatile long unsigned int * ), + --?( _Atomic volatile long unsigned int * ); +long long int --?( volatile long long int * ), + --?( _Atomic volatile long long int * ); +long long unsigned --?( volatile long long unsigned int * ), + --?( _Atomic volatile long long unsigned int * ); +float --?( volatile float * ), + --?( _Atomic volatile float * ); +double --?( volatile double * ), + --?( _Atomic volatile double * ); +long double --?( volatile long double * ), + --?( _Atomic volatile long double * ); + +forall( type T ) T * --?( T * restrict volatile * ), + * --?( T * _Atomic restrict volatile * ); + +forall( type T ) _Atomic T * --?( _Atomic T * restrict volatile * ), + * --?( _Atomic T * _Atomic restrict volatile * ); + +forall( type T ) const T * --?( const T * restrict volatile * ), + * --?( const T * _Atomic restrict volatile * ); + +forall( type T ) volatile T * --?( volatile T * restrict volatile * ), + * --?( volatile T * _Atomic restrict volatile * ); + +forall( type T ) restrict T * --?( restrict T * restrict volatile * ), + * --?( restrict T * _Atomic restrict volatile * ); + +forall( type T ) _Atomic const T * --?( _Atomic const T * restrict volatile * ), + * --?( _Atomic const T * _Atomic restrict volatile * ); + +forall( type T ) _Atomic volatile T * --?( _Atomic volatile T * restrict volatile * ), + * --?( _Atomic volatile T * _Atomic restrict volatile * ); + +forall( type T ) _Atomic restrict T * --?( _Atomic restrict T * restrict volatile * ), + * --?( _Atomic restrict T * _Atomic restrict volatile * ); + +forall( type T ) const volatile T * --?( const volatile T * restrict volatile * ), + * --?( const volatile T * _Atomic restrict volatile * ); + +forall( type T ) const restrict T * --?( const restrict T * restrict volatile * ), + * --?( const restrict T * _Atomic restrict volatile * ); + +forall( type T ) restrict volatile T * --?( restrict volatile T * restrict volatile * ), + * --?( restrict volatile T * _Atomic restrict volatile * ); + +forall( type T ) _Atomic const volatile T * --?( _Atomic const volatile T * restrict volatile * ), + * --?( _Atomic const volatile T * _Atomic restrict volatile * ); + +forall( type T ) _Atomic const restrict T * --?( _Atomic const restrict T * restrict volatile * ), + * --?( _Atomic const restrict T * _Atomic restrict volatile * ); + +forall( type T ) _Atomic restrict volatile T * --?( _Atomic restrict volatile T * restrict volatile * ), + * --?( _Atomic restrict volatile T * _Atomic restrict volatile * ); + +forall( type T ) const restrict volatile T * --?( const restrict volatile T * restrict volatile * ), + * --?( const restrict volatile T * _Atomic restrict volatile * ); + +forall( type T ) _Atomic const restrict volatile T * --?( _Atomic const restrict volatile T * restrict volatile * ), + * --?( _Atomic const restrict volatile T * _Atomic restrict volatile * ); +\end{lstlisting} +For every extended integer type \lstinline$X$ there exist +% Don't use predefined: keep this out of prelude.cf. +\begin{lstlisting} +X ++?( volatile X * ), + ++?( _Atomic volatile X * ), + --?( volatile X * ), + --?( _Atomic volatile X * ); +\end{lstlisting} +For every complete enumerated type \lstinline$E$ there exist +% Don't use predefined: keep this out of prelude.cf. +\begin{lstlisting} +E ++?( volatile E * ), + ++?( _Atomic volatile E * ), + ?--( volatile E * ), + ?--( _Atomic volatile E * ); +\end{lstlisting} + +\semantics +The interpretations of prefix increment and decrement expressions are +determined in the same way as the interpretations of postfix increment and +decrement expressions. + + +\subsubsection{Address and indirection operators} + +\begin{lstlisting} +forall( type T ) lvalue T *?( T * ); +forall( type T ) _Atomic lvalue T *?( _Atomic T * ); +forall( type T ) const lvalue T *?( const T * ); +forall( type T ) volatile lvalue T *?( volatile T * ); +forall( type T ) restrict lvalue T *?( restrict T * ); +forall( type T ) _Atomic const lvalue T *?( _Atomic const T * ); +forall( type T ) _Atomic volatile lvalue T *?( _Atomic volatile T * ); +forall( type T ) _Atomic restrict lvalue T *?( _Atomic restrict T * ); +forall( type T ) const volatile lvalue T *?( const volatile T * ); +forall( type T ) const restrict lvalue T *?( const restrict T * ); +forall( type T ) restrict volatile lvalue T *?( restrict volatile T * ); +forall( type T ) _Atomic const volatile lvalue T *?( _Atomic const volatile T * ); +forall( type T ) _Atomic const restrict lvalue T *?( _Atomic const restrict T * ); +forall( type T ) _Atomic restrict volatile lvalue T *?( _Atomic restrict volatile T * ); +forall( type T ) const restrict volatile lvalue T *?( const restrict volatile T * ); +forall( type T ) _Atomic const restrict volatile lvalue T *?( _Atomic const restrict volatile T * ); + +forall( ftype FT ) FT *?( FT * ); +\end{lstlisting} + +\constraints +The operand of the unary ``\lstinline$&$'' operator shall have exactly one +interpretation\index{ambiguous interpretation}\index{interpretations}, which shall be unambiguous. + +\semantics +The ``\lstinline$&$'' expression has one interpretation which is of type \lstinline$T *$, where +\lstinline$T$ is the type of the operand. + +The interpretations of an indirection expression are the interpretations of the corresponding +function call. + + +\subsubsection{Unary arithmetic operators} + +\begin{lstlisting} +int + +?( int ), + -?( int ), + ~?( int ); +unsigned int + +?( unsigned int ), + -?( unsigned int ), + ~?( unsigned int ); +long int + +?( long int ), + -?( long int ), + ~?( long int ); +long unsigned int + +?( long unsigned int ), + -?( long unsigned int ), + ~?( long unsigned int ); +long long int + +?( long long int ), + -?( long long int ), + ~?( long long int ); +long long unsigned int + +?( long long unsigned int ), + -?( long long unsigned int ), + ~?( long long unsigned int ); +float + +?( float ), + -?( float ); +double + +?( double ), + -?( double ); +long double + +?( long double ), + -?( long double ); +_Complex float + +?( _Complex float ), + -?( _Complex float ); +_Complex double + +?( _Complex double ), + -?( _Complex double ); +_Complex long double + +?( _Complex long double ), + -?( _Complex long double ); + +int !?( int ), + !?( unsigned int ), + !?( long ), + !?( long unsigned int ), + !?( long long int ), + !?( long long unsigned int ), + !?( float ), + !?( double ), + !?( long double ), + !?( _Complex float ), + !?( _Complex double ), + !?( _Complex long double ); + +forall( dtype DT ) int !?( const restrict volatile DT * ); +forall( dtype DT ) int !?( _Atomic const restrict volatile DT * ); +forall( ftype FT ) int !?( FT * ); +\end{lstlisting} +For every extended integer type \lstinline$X$ with integer conversion rank \index{integer conversion +rank}greater than the rank of \lstinline$int$ there exist +% Don't use predefined: keep this out of prelude.cf. +\begin{lstlisting} +X +?( X ), -?( X ), ~?( X ); +int !?( X ); +\end{lstlisting} + +\semantics +The interpretations of a unary arithmetic expression are the interpretations of the corresponding +function call. + +\examples +\begin{lstlisting} +long int li; +void eat_double( double );@\use{eat_double}@ + +eat_double(-li ); // @\rewrite@ eat_double( -?( li ) ); +\end{lstlisting} +The valid interpretations of ``\lstinline$-li$'' (assuming no extended integer types exist) are +\begin{center} +\begin{tabular}{llc} +interpretation & result type & expression conversion cost \\ +\hline +\lstinline$-?( (int)li )$ & \lstinline$int$ & (unsafe) \\ +\lstinline$-?( (unsigned)li)$ & \lstinline$unsigned int$ & (unsafe) \\ +\lstinline$-?( (long)li)$ & \lstinline$long$ & 0 \\ +\lstinline$-?( (long unsigned int)li)$ & \lstinline$long unsigned int$ & 1 \\ +\lstinline$-?( (long long int)li)$ & \lstinline$long long int$ & 2 \\ +\lstinline$-?( (long long unsigned int)li)$ & \lstinline$long long unsigned int$& 3 \\ +\lstinline$-?( (float)li)$ & \lstinline$float$ & 4 \\ +\lstinline$-?( (double)li)$ & \lstinline$double$ & 5 \\ +\lstinline$-?( (long double)li)$ & \lstinline$long double$ & 6 \\ +\lstinline$-?( (_Complex float)li)$ & \lstinline$float$ & (unsafe) \\ +\lstinline$-?( (_Complex double)li)$ & \lstinline$double$ & (unsafe) \\ +\lstinline$-?( (_Complex long double)li)$ & \lstinline$long double$ & (unsafe) \\ +\end{tabular} +\end{center} +The valid interpretations of the \lstinline$eat_double$ call, with the cost of the argument +conversion and the cost of the entire expression, are +\begin{center} +\begin{tabular}{lcc} +interpretation & argument cost & expression cost \\ +\hline +\lstinline$eat_double( (double)-?( (int)li) )$ & 7 & (unsafe) \\ +\lstinline$eat_double( (double)-?( (unsigned)li) )$ & 6 & (unsafe) \\ +\lstinline$eat_double( (double)-?(li) )$ & 5 & \(0+5=5\) \\ +\lstinline$eat_double( (double)-?( (long unsigned int)li) )$ & 4 & \(1+4=5\) \\ +\lstinline$eat_double( (double)-?( (long long int)li) )$ & 3 & \(2+3=5\) \\ +\lstinline$eat_double( (double)-?( (long long unsigned int)li) )$& 2 & \(3+2=5\) \\ +\lstinline$eat_double( (double)-?( (float)li) )$ & 1 & \(4+1=5\) \\ +\lstinline$eat_double( (double)-?( (double)li) )$ & 0 & \(5+0=5\) \\ +\lstinline$eat_double( (double)-?( (long double)li) )$ & (unsafe) & (unsafe) \\ +\lstinline$eat_double( (double)-?( (_Complex float)li) )$ & (unsafe) & (unsafe) \\ +\lstinline$eat_double( (double)-?( (_Complex double)li) )$ & (unsafe) & (unsafe) \\ +\lstinline$eat_double( (double)-?( (_Complex long double)li) )$ & (unsafe) & (unsafe) \\ +\end{tabular} +\end{center} +Each has result type \lstinline$void$, so the best must be selected. The interpretations involving +unsafe conversions are discarded. The remainder have equal expression conversion costs, so the +``highest argument conversion cost'' rule is invoked, and the chosen interpretation is +\lstinline$eat_double( (double)-?(li) )$. + + +\subsubsection{The {\tt sizeof} and {\tt \_Alignof} operators} + +\constraints +The operand of \lstinline$sizeof$ or \lstinline$_Alignof$ shall not be \lstinline$type$, +\lstinline$dtype$, or \lstinline$ftype$. + +When the \lstinline$sizeof$\use{sizeof} operator is applied to an expression, the expression shall +have exactly one interpretation\index{ambiguous interpretation}\index{interpretations}, which shall +be unambiguous. \semantics A \lstinline$sizeof$ or \lstinline$_Alignof$ expression has one +interpretation, of type \lstinline$size_t$. + +When \lstinline$sizeof$ is applied to an identifier declared by a \nonterm{type-declaration} or a +\nonterm{type-parameter}, it yields the size in bytes of the type that implements the operand. When +the operand is an opaque type or an inferred type parameter\index{inferred parameter}, the +expression is not a constant expression. + +When \lstinline$_Alignof$ is applied to an identifier declared by a \nonterm{type-declaration} or a +\nonterm{type-parameter}, it yields the alignment requirement of the type that implements the +operand. When the operand is an opaque type or an inferred type parameter\index{inferred +parameter}, the expression is not a constant expression. +\begin{rationale} +\begin{lstlisting} +type Pair = struct { int first, second; }; +size_t p_size = sizeof(Pair); // constant expression + +extern type Rational;@\use{Rational}@ +size_t c_size = sizeof(Rational); // non-constant expression + +forall(type T) T f(T p1, T p2) { + size_t t_size = sizeof(T); // non-constant expression + ... +} +\end{lstlisting} +``\lstinline$sizeof Rational$'', although not statically known, is fixed. Within \lstinline$f()$, +``\lstinline$sizeof(T)$'' is fixed for each call of \lstinline$f()$, but may vary from call to call. +\end{rationale} + +\subsection{Cast operators} +\begin{syntax} +\lhs{cast-expression} +\rhs \nonterm{unary-expression} +\rhs \lstinline$($ \nonterm{type-name} \lstinline$)$ \nonterm{cast-expression} +\end{syntax} + +\constraints +The \nonterm{type-name} in a \nonterm{cast-expression} shall not be \lstinline$type$, +\lstinline$dtype$, or \lstinline$ftype$. + +\semantics + +In a cast expression\index{cast expression} ``\lstinline$($\nonterm{type-name}\lstinline$)e$'', if +\nonterm{type-name} is the type of an interpretation of \lstinline$e$, then that interpretation is the +only interpretation of the cast expression; otherwise, \lstinline$e$ shall have some interpretation that +can be converted to \nonterm{type-name}, and the interpretation of the cast expression is the cast +of the interpretation that can be converted at the lowest cost. The cast expression's interpretation +is ambiguous\index{ambiguous interpretation} if more than one interpretation can be converted at the +lowest cost or if the selected interpretation is ambiguous. + +\begin{rationale} +Casts can be used to eliminate ambiguity in expressions by selecting interpretations of +subexpressions, and to specialize polymorphic functions and values. +\end{rationale} + +\subsection{Multiplicative operators} +\begin{syntax} +\lhs{multiplicative-expression} +\rhs \nonterm{cast-expression} +\rhs \nonterm{multiplicative-expression} \lstinline$*$ \nonterm{cast-expression} +\rhs \nonterm{multiplicative-expression} \lstinline$/$ \nonterm{cast-expression} +\rhs \nonterm{multiplicative-expression} \lstinline$%$ \nonterm{cast-expression} +\end{syntax} + +\rewriterules +\begin{lstlisting} +a * b @\rewrite@ ?*?( a, b )@\use{?*?}@ +a / b @\rewrite@ ?/?( a, b )@\use{?/?}@ +a % b @\rewrite@ ?%?( a, b )@\use{?%?}@ +\end{lstlisting} + +\begin{lstlisting} +int?*?( int, int ), + ?/?( int, int ), + ?%?( int, int ); +unsigned int?*?( unsigned int, unsigned int ), + ?/?( unsigned int, unsigned int ), + ?%?( unsigned int, unsigned int ); +long int?*?( long int, long int ), + ?/?( long, long ), + ?%?( long, long ); +long unsigned int?*?( long unsigned int, long unsigned int ), + ?/?( long unsigned int, long unsigned int ), + ?%?( long unsigned int, long unsigned int ); +long long int?*?( long long int, long long int ), + ?/?( long long int, long long int ), + ?%?( long long int, long long int ); +long long unsigned int ?*?( long long unsigned int, long long unsigned int ), + ?/?( long long unsigned int, long long unsigned int ), + ?%?( long long unsigned int, long long unsigned int ); +float?*?( float, float ), + ?/?( float, float ); +double?*?( double, double ), + ?/?( double, double ); +long double?*?( long double, long double ), + ?/?( long double, long double ); +_Complex float?*?( float, _Complex float ), + ?/?( float, _Complex float ), + ?*?( _Complex float, float ), + ?/?( _Complex float, float ), + ?*?( _Complex float, _Complex float ), + ?/?( _Complex float, _Complex float ); +_Complex double?*?( double, _Complex double ), + ?/?( double, _Complex double ), + ?*?( _Complex double, double ), + ?/?( _Complex double, double ), + ?*?( _Complex double, _Complex double ), + ?/?( _Complex double, _Complex double ); +_Complex long double?*?( long double, _Complex long double ), + ?/?( long double, _Complex long double ), + ?*?( _Complex long double, long double ), + ?/?( _Complex long double, long double ), + ?*?( _Complex long double, _Complex long double ), + ?/?( _Complex long double, _Complex long double ); +\end{lstlisting} +For every extended integer type \lstinline$X$ with integer conversion rank \index{integer conversion +rank}greater than the rank of \lstinline$int$ there exist +% Don't use predefined: keep this out of prelude.cf. +\begin{lstlisting} +X ?*?( X ), ?/?( X ), ?%?( X ); +\end{lstlisting} + +\begin{rationale} +{\c11} does not include conversions from the real types\index{real type} to complex +types\index{complex type} in the usual arithmetic conversions\index{usual arithmetic conversions}. +Instead it specifies conversion of the result of binary operations on arguments from mixed type +domains. \CFA's predefined operators match that pattern. +\end{rationale} + +\semantics +The interpretations of multiplicative expressions are the interpretations of the corresponding +function call. + +\examples +\begin{lstlisting} +int i; +long li; +void eat_double( double );@\use{eat_double}@ +eat_double( li % i ); +\end{lstlisting} +``\lstinline$li % i$'' is rewritten as ``\lstinline$?%?(li, i )$''. The valid interpretations +of \lstinline$?%?(li, i )$, the cost\index{conversion cost} of converting their arguments, and +the cost of converting the result to \lstinline$double$ (assuming no extended integer types are +present ) are +\begin{center} +\begin{tabular}{lcc} +interpretation & argument cost & result cost \\ +\hline +\lstinline$ ?%?( (int)li, i )$ & (unsafe) & 6 \\ +\lstinline$ ?%?( (unsigned)li,(unsigned)i )$ & (unsafe) & 5 \\ +\lstinline$ ?%?(li,(long)i )$ & 1 & 4 \\ +\lstinline$ ?%?( (long unsigned)li,(long unsigned)i )$ & 3 & 3 \\ +\lstinline$ ?%?( (long long)li,(long long)i )$ & 5 & 2 \\ +\lstinline$ ?%?( (long long unsigned)li, (long long unsigned)i )$ & 7 & 1 \\ +\end{tabular} +\end{center} +The best interpretation of \lstinline$eat_double( li, i )$ is +\lstinline$eat_double( (double)?%?(li, (long)i ))$, which has no unsafe conversions and the +lowest total cost. + +\begin{rationale} +{\c11} defines most arithmetic operations to apply an integer promotion\index{integer promotions} to +any argument that belongs to a type that has an integer conversion rank\index{integer conversion + rank} less than that of \lstinline$int$.If \lstinline$s$ is a \lstinline$short int$, +``\lstinline$s *s$'' does not have type \lstinline$short int$; it is treated as +``\lstinline$( (int)s ) * ( (int)s )$'', and has type \lstinline$int$. \CFA matches that pattern; +it does not predefine ``\lstinline$short ?*?( short, short )$''. + +These ``missing'' operators limit polymorphism. Consider +\begin{lstlisting} +forall( type T | T ?*?( T, T ) ) T square( T ); +short s; +square( s ); +\end{lstlisting} +Since \CFA does not define a multiplication operator for \lstinline$short int$, +\lstinline$square( s )$ is treated as \lstinline$square( (int)s )$, and the result has type +\lstinline$int$. This is mildly surprising, but it follows the {\c11} operator pattern. + +A more troubling example is +\begin{lstlisting} +forall( type T | ?*?( T, T ) ) T product( T[], int n ); +short sa[5]; +product( sa, 5); +\end{lstlisting} +This has no valid interpretations, because \CFA has no conversion from ``array of +\lstinline$short int$'' to ``array of \lstinline$int$''. The alternatives in such situations +include +\begin{itemize} +\item +Defining monomorphic overloadings of \lstinline$product$ for \lstinline$short$ and the other +``small'' types. +\item +Defining ``\lstinline$short ?*?( short, short )$'' within the scope containing the call to +\lstinline$product$. +\item +Defining \lstinline$product$ to take as an argument a conversion function from the ``small'' type to +the operator's argument type. +\end{itemize} +\end{rationale} + + +\subsection{Additive operators} + +\begin{syntax} +\lhs{additive-expression} +\rhs \nonterm{multiplicative-expression} +\rhs \nonterm{additive-expression} \lstinline$+$ \nonterm{multiplicative-expression} +\rhs \nonterm{additive-expression} \lstinline$-$ \nonterm{multiplicative-expression} +\end{syntax} + +\rewriterules +\begin{lstlisting} +a + b @\rewrite@ ?+?( a, b )@\use{?+?}@ +a - b @\rewrite@ ?-?( a, b )@\use{?-?}@ +\end{lstlisting} + +\begin{lstlisting} +int?+?( int, int ), + ?-?( int, int ); +unsigned int?+?( unsigned int, unsigned int ), + ?-?( unsigned int, unsigned int ); +long int?+?( long int, long int ), + ?-?( long int, long int ); +long unsigned int?+?( long unsigned int, long unsigned int ), + ?-?( long unsigned int, long unsigned int ); +long long int?+?( long long int, long long int ), + ?-?( long long int, long long int ); +long long unsigned int ?+?( long long unsigned int, long long unsigned int ), + ?-?( long long unsigned int, long long unsigned int ); +float?+?( float, float ), + ?-?( float, float ); +double?+?( double, double ), + ?-?( double, double ); +long double?+?( long double, long double ), + ?-?( long double, long double ); +_Complex float?+?( _Complex float, float ), + ?-?( _Complex float, float ), + ?+?( float, _Complex float ), + ?-?( float, _Complex float ), + ?+?( _Complex float, _Complex float ), + ?-?( _Complex float, _Complex float ); +_Complex double?+?( _Complex double, double ), + ?-?( _Complex double, double ), + ?+?( double, _Complex double ), + ?-?( double, _Complex double ), + ?+?( _Complex double, _Complex double ), + ?-?( _Complex double, _Complex double ); +_Complex long double?+?( _Complex long double, long double ), + ?-?( _Complex long double, long double ), + ?+?( long double, _Complex long double ), + ?-?( long double, _Complex long double ), + ?+?( _Complex long double, _Complex long double ), + ?-?( _Complex long double, _Complex long double ); + +forall( type T ) T + * ?+?( T *, ptrdiff_t ), + * ?+?( ptrdiff_t, T * ), + * ?-?( T *, ptrdiff_t ); + +forall( type T ) _Atomic T + * ?+?( _Atomic T *, ptrdiff_t ), + * ?+?( ptrdiff_t, _Atomic T * ), + * ?-?( _Atomic T *, ptrdiff_t ); + +forall( type T ) const T + * ?+?( const T *, ptrdiff_t ), + * ?+?( ptrdiff_t, const T * ), + * ?-?( const T *, ptrdiff_t ); + +forall( type T ) restrict T + * ?+?( restrict T *, ptrdiff_t ), + * ?+?( ptrdiff_t, restrict T * ), + * ?-?( restrict T *, ptrdiff_t ); + +forall( type T ) volatile T + * ?+?( volatile T *, ptrdiff_t ), + * ?+?( ptrdiff_t, volatile T * ), + * ?-?( volatile T *, ptrdiff_t ); + +forall( type T ) _Atomic const T + * ?+?( _Atomic const T *, ptrdiff_t ), + * ?+?( ptrdiff_t, _Atomic const T * ), + * ?-?( _Atomic const T *, ptrdiff_t ); + +forall( type T ) _Atomic restrict T + * ?+?( _Atomic restrict T *, ptrdiff_t ), + * ?+?( ptrdiff_t, _Atomic restrict T * ), + * ?-?( _Atomic restrict T *, ptrdiff_t ); + +forall( type T ) _Atomic volatile T + * ?+?( _Atomic volatile T *, ptrdiff_t ), + * ?+?( ptrdiff_t, _Atomic volatile T * ), + * ?-?( _Atomic volatile T *, ptrdiff_t ); + +forall( type T ) const restrict T + * ?+?( const restrict T *, ptrdiff_t ), + * ?+?( ptrdiff_t, const restrict T * ), + * ?-?( const restrict T *, ptrdiff_t ); + +forall( type T ) const volatile T + * ?+?( const volatile T *, ptrdiff_t ), + * ?+?( ptrdiff_t, const volatile T * ), + * ?-?( const volatile T *, ptrdiff_t ); + +forall( type T ) restrict volatile T + * ?+?( restrict volatile T *, ptrdiff_t ), + * ?+?( ptrdiff_t, restrict volatile T * ), + * ?-?( restrict volatile T *, ptrdiff_t ); + +forall( type T ) _Atomic const restrict T + * ?+?( _Atomic const restrict T *, ptrdiff_t ), + * ?+?( ptrdiff_t, _Atomic const restrict T * ), + * ?-?( _Atomic const restrict T *, ptrdiff_t ); + +forall( type T ) ptrdiff_t + * ?-?( const restrict volatile T *, const restrict volatile T * ), + * ?-?( _Atomic const restrict volatile T *, _Atomic const restrict volatile T * ); +\end{lstlisting} +For every extended integer type \lstinline$X$ with integer conversion rank +\index{integer conversion rank}greater than the rank of \lstinline$int$ there +exist +% Don't use predefined: keep this out of prelude.cf. +\begin{lstlisting} +X ?+?( X ), ?-?( X ); +\end{lstlisting} + +\semantics +The interpretations of additive expressions are the interpretations of the corresponding function +calls. + +\begin{rationale} +\lstinline$ptrdiff_t$ is an implementation-defined identifier defined in \lstinline$$ that +is synonymous with a signed integral type that is large enough to hold the difference between two +pointers. It seems reasonable to use it for pointer addition as well. (This is technically a +difference between \CFA and C, which only specifies that pointer addition uses an \emph{integral} +argument.) Hence it is also used for subscripting, which is defined in terms of pointer addition. +The {\c11} standard uses \lstinline$size_t$ in several cases where a library function takes an +argument that is used as a subscript, but \lstinline$size_t$ is unsuitable here because it is an +unsigned type. +\end{rationale} + + +\subsection{Bitwise shift operators} + +\begin{syntax} +\lhs{shift-expression} +\rhs \nonterm{additive-expression} +\rhs \nonterm{shift-expression} \lstinline$<<$ \nonterm{additive-expression} +\rhs \nonterm{shift-expression} \lstinline$>>$ \nonterm{additive-expression} +\end{syntax} + +\rewriterules \use{?>>?}%use{?<> b @\rewrite@ ?>>?( a, b ) +\end{lstlisting} + +\begin{lstlisting} +int ?<>?( int, int ); +unsigned int ?<>?( unsigned int, int ); +long int ?<>?( long int, int ); +long unsigned int ?<>?( long unsigned int, int ); +long long int ?<>?( long long int, int ); +long long unsigned int ?<>?( long long unsigned int, int); +\end{lstlisting} +For every extended integer type \lstinline$X$ with integer conversion rank \index{integer conversion + rank}greater than the rank of \lstinline$int$ there exist +% Don't use predefined: keep this out of prelude.cf. +\begin{lstlisting} +X ?<>?( X, int ); +\end{lstlisting} + +\begin{rationale} +The bitwise shift operators break the usual pattern: they do not convert both operands to a common +type. The right operand only undergoes integer promotion\index{integer promotion}. +\end{rationale} + +\semantics +The interpretations of a bitwise shift expression are the interpretations of the corresponding +function calls. + + +\subsection{Relational operators} + +\begin{syntax} +\lhs{relational-expression} +\rhs \nonterm{shift-expression} +\rhs \nonterm{relational-expression} \lstinline$< $ \nonterm{shift-expression} +\rhs \nonterm{relational-expression} \lstinline$> $ \nonterm{shift-expression} +\rhs \nonterm{relational-expression} \lstinline$<=$ \nonterm{shift-expression} +\rhs \nonterm{relational-expression} \lstinline$>=$ \nonterm{shift-expression} +\end{syntax} + +\rewriterules\use{?>?}\use{?>=?}%use{? b @\rewrite@ ?>?( a, b ) +a <= b @\rewrite@ ?<=?( a, b ) +a >= b @\rewrite@ ?>=?( a, b ) +\end{lstlisting} + +\begin{lstlisting} +int ??( int, int ), + ?>=?( int, int ); +int ??( unsigned int, unsigned int ), + ?>=?( unsigned int, unsigned int ); +int ??( long int, long int ), + ?>=?( long int, long int ); +int ??( long unsigned int, long unsigned ), + ?>=?( long unsigned int, long unsigned ); +int ??( long long int, long long int ), + ?>=?( long long int, long long int ); +int ??( long long unsigned int, long long unsigned ), + ?>=?( long long unsigned int, long long unsigned ); +int ??( float, float ), + ?>=?( float, float ); +int ??( double, double ), + ?>=?( double, double ); +int ??( long double, long double ), + ?>=?( long double, long double ); + +forall( dtype DT ) int + ??( const restrict volatile DT *, const restrict volatile DT * ), + ?>?( _Atomic const restrict volatile DT *, _Atomic const restrict volatile DT * ), + ?>=?( const restrict volatile DT *, const restrict volatile DT * ), + ?>=?( _Atomic const restrict volatile DT *, _Atomic const restrict volatile DT * ); +\end{lstlisting} +For every extended integer type \lstinline$X$ with integer conversion rank \index{integer conversion + rank}greater than the rank of \lstinline$int$ there exist +% Don't use predefined: keep this out of prelude.cf. +\begin{lstlisting} +int ?=?( X, X ); +\end{lstlisting} + +\semantics +The interpretations of a relational expression are the interpretations of the corresponding function +call. + + +\subsection{Equality operators} + +\begin{syntax} +\lhs{equality-expression} +\rhs \nonterm{relational-expression} +\rhs \nonterm{equality-expression} \lstinline$==$ \nonterm{relational-expression} +\rhs \nonterm{equality-expression} \lstinline$!=$ \nonterm{relational-expression} +\end{syntax} + +\rewriterules +\begin{lstlisting} +a == b @\rewrite@ ?==?( a, b )@\use{?==?}@ +a != b @\rewrite@ ?!=?( a, b )@\use{?"!=?}@ +\end{lstlisting} + +\begin{lstlisting} +int ?==?( int, int ), + ?!=?( int, int ), + ?==?( unsigned int, unsigned int ), + ?!=?( unsigned int, unsigned int ), + ?==?( long int, long int ), + ?!=?( long int, long int ), + ?==?( long unsigned int, long unsigned int ), + ?!=?( long unsigned int, long unsigned int ), + ?==?( long long int, long long int ), + ?!=?( long long int, long long int ), + ?==?( long long unsigned int, long long unsigned int ), + ?!=?( long long unsigned int, long long unsigned int ), + ?==?( float, float ), + ?!=?( float, float ), + ?==?( _Complex float, float ), + ?!=?( _Complex float, float ), + ?==?( float, _Complex float ), + ?!=?( float, _Complex float ), + ?==?( _Complex float, _Complex float ), + ?!=?( _Complex float, _Complex float ), + ?==?( double, double ), + ?!=?( double, double ), + ?==?( _Complex double, double ), + ?!=?( _Complex double, double ), + ?==?( double, _Complex double ), + ?!=?( double, _Complex double ), + ?==?( _Complex double, _Complex double ), + ?!=?( _Complex double, _Complex double ), + ?==?( long double, long double ), + ?!=?( long double, long double ), + ?==?( _Complex long double, long double ), + ?!=?( _Complex long double, long double ), + ?==?( long double, _Complex long double ), + ?!=?( long double, _Complex long double ), + ?==?( _Complex long double, _Complex long double ), + ?!=?( _Complex long double, _Complex long double ); + +forall( dtype DT ) int + ?==?( const restrict volatile DT *, const restrict volatile DT * ), + ?!=?( const restrict volatile DT *, const restrict volatile DT * ), + ?==?( const restrict volatile DT *, const restrict volatile void * ), + ?!=?( const restrict volatile DT *, const restrict volatile void * ), + ?==?( const restrict volatile void *, const restrict volatile DT * ), + ?!=?( const restrict volatile void *, const restrict volatile DT * ), + ?==?( const restrict volatile DT *, forall( dtype DT2) const DT2 * ), + ?!=?( const restrict volatile DT *, forall( dtype DT2) const DT2 * ), + ?==?( forall( dtype DT2) const DT2*, const restrict volatile DT * ), + ?!=?( forall( dtype DT2) const DT2*, const restrict volatile DT * ), + ?==?( forall( dtype DT2) const DT2*, forall( dtype DT3) const DT3 * ), + ?!=?( forall( dtype DT2) const DT2*, forall( dtype DT3) const DT3 * ), + + ?==?( _Atomic const restrict volatile DT *, _Atomic const restrict volatile DT * ), + ?!=?( _Atomic const restrict volatile DT *, _Atomic const restrict volatile DT * ), + ?==?( _Atomic const restrict volatile DT *, const restrict volatile void * ), + ?!=?( _Atomic const restrict volatile DT *, const restrict volatile void * ), + ?==?( const restrict volatile void *, _Atomic const restrict volatile DT * ), + ?!=?( const restrict volatile void *, _Atomic const restrict volatile DT * ), + ?==?( _Atomic const restrict volatile DT *, forall( dtype DT2) const DT2 * ), + ?!=?( _Atomic const restrict volatile DT *, forall( dtype DT2) const DT2 * ), + ?==?( forall( dtype DT2) const DT2*, _Atomic const restrict volatile DT * ), + ?!=?( forall( dtype DT2) const DT2*, _Atomic const restrict volatile DT * ); + +forall( ftype FT ) int + ?==?( FT *, FT * ), + ?!=?( FT *, FT * ), + ?==?( FT *, forall( ftype FT2) FT2 * ), + ?!=?( FT *, forall( ftype FT2) FT2 * ), + ?==?( forall( ftype FT2) FT2*, FT * ), + ?!=?( forall( ftype FT2) FT2*, FT * ), + ?==?( forall( ftype FT2) FT2*, forall( ftype FT3) FT3 * ), + ?!=?( forall( ftype FT2) FT2*, forall( ftype FT3) FT3 * ); +\end{lstlisting} +For every extended integer type \lstinline$X$ with integer conversion rank \index{integer conversion + rank}greater than the rank of \lstinline$int$ there exist +% Don't use predefined: keep this out of prelude.cf. +\begin{lstlisting} +int ?==?( X, X ), + ?!=?( X, X ); +\end{lstlisting} + +\begin{rationale} +The polymorphic equality operations come in three styles: comparisons between pointers of compatible +types, between pointers to \lstinline$void$ and pointers to object types or incomplete types, and +between the null pointer constant\index{null pointer} and pointers to any type. In the last case, a +special constraint rule for null pointer constant operands has been replaced by a consequence of the +\CFA type system. +\end{rationale} + +\semantics +The interpretations of an equality expression are the interpretations of the corresponding function +call. + +\begin{sloppypar} +The result of an equality comparison between two pointers to predefined functions or predefined +values is implementation-defined. +\end{sloppypar} +\begin{rationale} +The implementation-defined status of equality comparisons allows implementations to use one library +routine to implement many predefined functions. These optimization are particularly important when +the predefined functions are polymorphic, as is the case for most pointer operations +\end{rationale} + + +\subsection{Bitwise AND operator} + +\begin{syntax} +\lhs{AND-expression} +\rhs \nonterm{equality-expression} +\rhs \nonterm{AND-expression} \lstinline$&$ \nonterm{equality-expression} +\end{syntax} + +\rewriterules +\begin{lstlisting} +a & b @\rewrite@ ?&?( a, b )@\use{?&?}@ +\end{lstlisting} + +\begin{lstlisting} +int ?&?( int, int ); +unsigned int ?&?( unsigned int, unsigned int ); +long int ?&?( long int, long int ); +long unsigned int ?&?( long unsigned int, long unsigned int ); +long long int ?&?( long long int, long long int ); +long long unsigned int ?&?( long long unsigned int, long long unsigned int ); +\end{lstlisting} +For every extended integer type \lstinline$X$ with integer conversion rank \index{integer conversion +rank}greater than the rank of \lstinline$int$ there exist +% Don't use predefined: keep this out of prelude.cf. +\begin{lstlisting} +int ?&?( X, X ); +\end{lstlisting} + +\semantics +The interpretations of a bitwise AND expression are the interpretations of the corresponding +function call. + + +\subsection{Bitwise exclusive OR operator} + +\begin{syntax} +\lhs{exclusive-OR-expression} +\rhs \nonterm{AND-expression} +\rhs \nonterm{exclusive-OR-expression} \lstinline$^$ \nonterm{AND-expression} +\end{syntax} + +\rewriterules +\begin{lstlisting} +a ^ b @\rewrite@ ?^?( a, b )@\use{?^?}@ +\end{lstlisting} + +\begin{lstlisting} +int ?^?( int, int ); +unsigned int ?^?( unsigned int, unsigned int ); +long int ?^?( long int, long int ); +long unsigned int ?^?( long unsigned int, long unsigned int ); +long long int ?^?( long long int, long long int ); +long long unsigned int ?^?( long long unsigned int, long long unsigned int ); +\end{lstlisting} +For every extended integer type \lstinline$X$ with integer conversion rank \index{integer conversion + rank}greater than the rank of \lstinline$int$ there exist +% Don't use predefined: keep this out of prelude.cf. +\begin{lstlisting} +int ?^?( X, X ); +\end{lstlisting} + +\semantics +The interpretations of a bitwise exclusive OR expression are the interpretations of the +corresponding function call. + + +\subsection{Bitwise inclusive OR operator} + +\begin{syntax} +\lhs{inclusive-OR-expression} +\rhs \nonterm{exclusive-OR-expression} +\rhs \nonterm{inclusive-OR-expression} \lstinline$|$ \nonterm{exclusive-OR-expression} +\end{syntax} + +\rewriterules\use{?"|?} +\begin{lstlisting} +a | b @\rewrite@ ?|?( a, b ) +\end{lstlisting} + +\begin{lstlisting} +int ?|?( int, int ); +unsigned int ?|?( unsigned int, unsigned int ); +long int ?|?( long int, long int ); +long unsigned int ?|?( long unsigned int, long unsigned int ); +long long int ?|?( long long int, long long int ); +long long unsigned int ?|?( long long unsigned int, long long unsigned int ); +\end{lstlisting} +For every extended integer type \lstinline$X$ with integer conversion rank \index{integer conversion +rank}greater than the rank of \lstinline$int$ there exist +% Don't use predefined: keep this out of prelude.cf. +\begin{lstlisting} +int ?|?( X, X ); +\end{lstlisting} + +\semantics +The interpretations of a bitwise inclusive OR expression are the interpretations of the +corresponding function call. + + +\subsection{Logical AND operator} + +\begin{syntax} +\lhs{logical-AND-expression} +\rhs \nonterm{inclusive-OR-expression} +\rhs \nonterm{logical-AND-expression} \lstinline$&&$ \nonterm{inclusive-OR-expression} +\end{syntax} + +\semantics The operands of the expression ``\lstinline$a && b$'' are treated as +``\lstinline$(int)((a)!=0)$'' and ``\lstinline$(int)((b)!=0)$'', which shall both be +unambiguous. The expression has only one interpretation, which is of type \lstinline$int$. +\begin{rationale} +When the operands of a logical expression are values of built-in types, and ``\lstinline$!=$'' has +not been redefined for those types, the compiler can optimize away the function calls. + +A common C idiom omits comparisons to \lstinline$0$ in the controlling expressions of loops and +\lstinline$if$ statements. For instance, the loop below iterates as long as \lstinline$rp$ points +at a \lstinline$Rational$ value that is non-zero. + +\begin{lstlisting} +extern type Rational;@\use{Rational}@ +extern const Rational 0;@\use{0}@ +extern int ?!=?( Rational, Rational ); +Rational *rp; + +while ( rp && *rp ) { ... } +\end{lstlisting} +The logical expression calls the \lstinline$Rational$ inequality operator, passing +it \lstinline$*rp$ and the \lstinline$Rational 0$, and getting a 1 or 0 as a result. In +contrast, {\CC} would apply a programmer-defined \lstinline$Rational$-to-\lstinline$int$ +conversion to \lstinline$*rp$ in the equivalent situation. The conversion to \lstinline$int$ would +produce a general integer value, which is unfortunate, and possibly dangerous if the conversion was +not written with this situation in mind. +\end{rationale} + + +\subsection{Logical OR operator} + +\begin{syntax} +\lhs{logical-OR-expression} +\rhs \nonterm{logical-AND-expression} +\rhs \nonterm{logical-OR-expression} \lstinline$||$ \nonterm{logical-AND-expression} +\end{syntax} + +\semantics + +The operands of the expression ``\lstinline$a || b$'' are treated as ``\lstinline$(int)((a)!=0)$'' +and ``\lstinline$(int)((b})!=0)$'', which shall both be unambiguous. The expression has only one +interpretation, which is of type \lstinline$int$. + + +\subsection{Conditional operator} + +\begin{syntax} +\lhs{conditional-expression} +\rhs \nonterm{logical-OR-expression} +\rhs \nonterm{logical-OR-expression} \lstinline$?$ \nonterm{expression} + \lstinline$:$ \nonterm{conditional-expression} +\end{syntax} + +\semantics +In the conditional expression\use{?:} ``\lstinline$a?b:c$'', if the second and +third operands both have an interpretation with \lstinline$void$ type, then the expression has an +interpretation with type \lstinline$void$, equivalent to +\begin{lstlisting} +( int)(( a)!=0) ? ( void)( b) : ( void)( c) +\end{lstlisting} + +If the second and third operands both have interpretations with non-\lstinline$void$ types, the +expression is treated as if it were the call ``\lstinline$cond((a)!=0, b, c)$'', +with \lstinline$cond$ declared as +\begin{lstlisting} +forall( type T ) T cond( int, T, T ); + +forall( dtype D ) void + * cond( int, D *, void * ), + * cond( int, void *, D * ); + +forall( dtype D ) _atomic void + * cond( int, _Atomic D *, _Atomic void * ), + * cond( int, _Atomic void *, _Atomic D * ); + +forall( dtype D ) const void + * cond( int, const D *, const void * ), + * cond( int, const void *, const D * ); + +forall( dtype D ) restrict void + * cond( int, restrict D *, restrict void * ), + * cond( int, restrict void *, restrict D * ); + +forall( dtype D ) volatile void + * cond( int, volatile D *, volatile void * ), + * cond( int, volatile void *, volatile D * ); + +forall( dtype D ) _Atomic const void + * cond( int, _Atomic const D *, _Atomic const void * ), + * cond( int, _Atomic const void *, _Atomic const D * ); + +forall( dtype D ) _Atomic restrict void + * cond( int, _Atomic restrict D *, _Atomic restrict void * ), + * cond( int, _Atomic restrict void *, _Atomic restrict D * ); + +forall( dtype D ) _Atomic volatile void + * cond( int, _Atomic volatile D *, _Atomic volatile void * ), + * cond( int, _Atomic volatile void *, _Atomic volatile D * ); + +forall( dtype D ) const restrict void + * cond( int, const restrict D *, const restrict void * ), + * cond( int, const restrict void *, const restrict D * ); + +forall( dtype D ) const volatile void + * cond( int, const volatile D *, const volatile void * ), + * cond( int, const volatile void *, const volatile D * ); + +forall( dtype D ) restrict volatile void + * cond( int, restrict volatile D *, restrict volatile void * ), + * cond( int, restrict volatile void *, restrict volatile D * ); + +forall( dtype D ) _Atomic const restrict void + * cond( int, _Atomic const restrict D *, _Atomic const restrict void * ), + * cond( int, _Atomic const restrict void *, _Atomic const restrict D * ); + +forall( dtype D ) _Atomic const volatile void + * cond( int, _Atomic const volatile D *, _Atomic const volatile void * ), + * cond( int, _Atomic const volatile void *, _Atomic const volatile D * ); + +forall( dtype D ) _Atomic restrict volatile void + * cond( int, _Atomic restrict volatile D *, + _Atomic restrict volatile void * ), + * cond( int, _Atomic restrict volatile void *, + _Atomic restrict volatile D * ); + +forall( dtype D ) const restrict volatile void + * cond( int, const restrict volatile D *, + const restrict volatile void * ), + * cond( int, const restrict volatile void *, + const restrict volatile D * ); + +forall( dtype D ) _Atomic const restrict volatile void + * cond( int, _Atomic const restrict volatile D *, + _Atomic const restrict volatile void * ), + * cond( int, _Atomic const restrict volatile void *, + _Atomic const restrict volatile D * ); +\end{lstlisting} + +\begin{rationale} +The object of the above is to apply the usual arithmetic conversions\index{usual arithmetic +conversions} when the second and third operands have arithmetic type, and to combine the +qualifiers of the second and third operands if they are pointers. +\end{rationale} + +\examples +\begin{lstlisting} +#include +int i; +long l; +rand() ? i : l; +\end{lstlisting} +The best interpretation infers the expression's type to be \lstinline$long$ and applies the safe +\lstinline$int$-to-\lstinline$long$ conversion to \lstinline$i$. + +\begin{lstlisting} +const int *cip; +volatile int *vip; +rand() ? cip : vip; +\end{lstlisting} +The expression has type \lstinline$const volatile int *$, with safe conversions applied to the second +and third operands to add \lstinline$volatile$ and \lstinline$const$ qualifiers, respectively. + +\begin{lstlisting} +rand() ? cip : 0; +\end{lstlisting} +The expression has type \lstinline$const int *$, with a specialization conversion applied to +\lstinline$0$. + + +\subsection{Assignment operators} + +\begin{syntax} +\lhs{assignment-expression} +\rhs \nonterm{conditional-expression} +\rhs \nonterm{unary-expression} \nonterm{assignment-operator} + \nonterm{assignment-expression} +\lhs{assignment-operator} one of +\rhs \lstinline$=$\ \ \lstinline$*=$\ \ \lstinline$/=$\ \ \lstinline$%=$\ \ \lstinline$+=$\ \ \lstinline$-=$\ \ + \lstinline$<<=$\ \ \lstinline$>>=$\ \ \lstinline$&=$\ \ \lstinline$^=$\ \ \lstinline$|=$ +\end{syntax} + +\rewriterules +Let ``\(\leftarrow\)'' be any of the assignment operators. Then +\use{?=?}\use{?*=?}\use{?/=?}\use{?%=?}\use{?+=?}\use{?-=?} +\use{?>>=?}\use{?&=?}\use{?^=?}\use{?"|=?}%use{?<<=?} +\begin{lstlisting} +a @$\leftarrow$@ b @\rewrite@ ?@$\leftarrow$@?( &( a ), b ) +\end{lstlisting} + +\semantics +Each interpretation of the left operand of an assignment expression is considered separately. For +each interpretation that is a bit-field or is declared with the \lstinline$register$ storage class +specifier, the expression has one valid interpretation, with the type of the left operand. The +right operand is cast to that type, and the assignment expression is ambiguous if either operand is. +For the remaining interpretations, the expression is rewritten, and the interpretations of the +assignment expression are the interpretations of the corresponding function call. Finally, all +interpretations of the expression produced for the different interpretations of the left operand are +combined to produce the interpretations of the expression as a whole; where interpretations have +compatible result types, the best interpretations are selected in the manner described for function +call expressions. + + +\subsubsection{Simple assignment} + +\begin{lstlisting} +_Bool + ?=?( volatile _Bool *, _Bool ), + ?=?( volatile _Bool *, forall( dtype D ) D * ), + ?=?( volatile _Bool *, forall( ftype F ) F * ), + ?=?( _Atomic volatile _Bool *, _Bool ), + ?=?( _Atomic volatile _Bool *, forall( dtype D ) D * ), + ?=?( _Atomic volatile _Bool *, forall( ftype F ) F * ); +char + ?=?( volatile char *, char ), + ?=?( _Atomic volatile char *, char ); +unsigned char + ?=?( volatile unsigned char *, unsigned char ), + ?=?( _Atomic volatile unsigned char *, unsigned char ); +signed char + ?=?( volatile signed char *, signed char ), + ?=?( _Atomic volatile signed char *, signed char ); +short int + ?=?( volatile short int *, short int ), + ?=?( _Atomic volatile short int *, short int ); +unsigned short + ?=?( volatile unsigned int *, unsigned int ), + ?=?( _Atomic volatile unsigned int *, unsigned int ); +int + ?=?( volatile int *, int ), + ?=?( _Atomic volatile int *, int ); +unsigned int + ?=?( volatile unsigned int *, unsigned int ), + ?=?( _Atomic volatile unsigned int *, unsigned int ); +long int + ?=?( volatile long int *, long int ), + ?=?( _Atomic volatile long int *, long int ); +unsigned long int + ?=?( volatile unsigned long int *, unsigned long int ), + ?=?( _Atomic volatile unsigned long int *, unsigned long int ); +long long int + ?=?( volatile long long int *, long long int ), + ?=?( _Atomic volatile long long int *, long long int ); +unsigned long long int + ?=?( volatile unsigned long long int *, unsigned long long int ), + ?=?( _Atomic volatile unsigned long long int *, unsigned long long int ); +float + ?=?( volatile float *, float ), + ?=?( _Atomic volatile float *, float ); +double + ?=?( volatile double *, double ), + ?=?( _Atomic volatile double *, double ); +long double + ?=?( volatile long double *, long double ), + ?=?( _Atomic volatile long double *, long double ); +_Complex float + ?=?( volatile float *, float ), + ?=?( _Atomic volatile float *, float ); +_Complex double + ?=?( volatile double *, double ), + ?=?( _Atomic volatile double *, double ); +_Complex long double + ?=?( volatile _Complex long double *, _Complex long double ), + ?=?( _Atomic volatile _Complex long double *, _Atomic _Complex long double ); + +forall( ftype FT ) FT + * ?=?( FT * volatile *, FT * ), + * ?=?( FT * volatile *, forall( ftype F ) F * ); + +forall( ftype FT ) FT const + * ?=?( FT const * volatile *, FT const * ), + * ?=?( FT const * volatile *, forall( ftype F ) F * ); + +forall( ftype FT ) FT volatile + * ?=?( FT volatile * volatile *, FT * ), + * ?=?( FT volatile * volatile *, forall( ftype F ) F * ); + +forall( ftype FT ) FT const + * ?=?( FT const volatile * volatile *, FT const * ), + * ?=?( FT const volatile * volatile *, forall( ftype F ) F * ); + +forall( dtype DT ) DT + * ?=?( DT * restrict volatile *, DT * ), + * ?=?( DT * restrict volatile *, void * ), + * ?=?( DT * restrict volatile *, forall( dtype D ) D * ), + * ?=?( DT * _Atomic restrict volatile *, DT * ), + * ?=?( DT * _Atomic restrict volatile *, void * ), + * ?=?( DT * _Atomic restrict volatile *, forall( dtype D ) D * ); + +forall( dtype DT ) DT _Atomic + * ?=?( _Atomic DT * restrict volatile *, DT _Atomic * ), + * ?=?( _Atomic DT * restrict volatile *, void * ), + * ?=?( _Atomic DT * restrict volatile *, forall( dtype D ) D * ), + * ?=?( _Atomic DT * _Atomic restrict volatile *, DT _Atomic * ), + * ?=?( _Atomic DT * _Atomic restrict volatile *, void * ), + * ?=?( _Atomic DT * _Atomic restrict volatile *, forall( dtype D ) D * ); + +forall( dtype DT ) DT const + * ?=?( DT const * restrict volatile *, DT const * ), + * ?=?( DT const * restrict volatile *, void const * ), + * ?=?( DT const * restrict volatile *, forall( dtype D ) D * ), + * ?=?( DT const * _Atomic restrict volatile *, DT const * ), + * ?=?( DT const * _Atomic restrict volatile *, void const * ), + * ?=?( DT const * _Atomic restrict volatile *, forall( dtype D ) D * ); + +forall( dtype DT ) DT restrict + * ?=?( restrict DT * restrict volatile *, DT restrict * ), + * ?=?( restrict DT * restrict volatile *, void * ), + * ?=?( restrict DT * restrict volatile *, forall( dtype D ) D * ), + * ?=?( restrict DT * _Atomic restrict volatile *, DT restrict * ), + * ?=?( restrict DT * _Atomic restrict volatile *, void * ), + * ?=?( restrict DT * _Atomic restrict volatile *, forall( dtype D ) D * ); + +forall( dtype DT ) DT volatile + * ?=?( DT volatile * restrict volatile *, DT volatile * ), + * ?=?( DT volatile * restrict volatile *, void volatile * ), + * ?=?( DT volatile * restrict volatile *, forall( dtype D ) D * ), + * ?=?( DT volatile * _Atomic restrict volatile *, DT volatile * ), + * ?=?( DT volatile * _Atomic restrict volatile *, void volatile * ), + * ?=?( DT volatile * _Atomic restrict volatile *, forall( dtype D ) D * ); + +forall( dtype DT ) DT _Atomic const + * ?=?( DT _Atomic const * restrict volatile *, DT _Atomic const * ), + * ?=?( DT _Atomic const * restrict volatile *, void const * ), + * ?=?( DT _Atomic const * restrict volatile *, forall( dtype D ) D * ), + * ?=?( DT _Atomic const * _Atomic restrict volatile *, DT _Atomic const * ), + * ?=?( DT _Atomic const * _Atomic restrict volatile *, void const * ), + * ?=?( DT _Atomic const * _Atomic restrict volatile *, forall( dtype D ) D * ); + +forall( dtype DT ) DT _Atomic restrict + * ?=?( _Atomic restrict DT * restrict volatile *, DT _Atomic restrict * ), + * ?=?( _Atomic restrict DT * restrict volatile *, void * ), + * ?=?( _Atomic restrict DT * restrict volatile *, forall( dtype D ) D * ), + * ?=?( _Atomic restrict DT * _Atomic restrict volatile *, DT _Atomic restrict * ), + * ?=?( _Atomic restrict DT * _Atomic restrict volatile *, void * ), + * ?=?( _Atomic restrict DT * _Atomic restrict volatile *, forall( dtype D ) D * ); + +forall( dtype DT ) DT _Atomic volatile + * ?=?( DT _Atomic volatile * restrict volatile *, DT _Atomic volatile * ), + * ?=?( DT _Atomic volatile * restrict volatile *, void volatile * ), + * ?=?( DT _Atomic volatile * restrict volatile *, forall( dtype D ) D * ), + * ?=?( DT _Atomic volatile * _Atomic restrict volatile *, DT _Atomic volatile * ), + * ?=?( DT _Atomic volatile * _Atomic restrict volatile *, void volatile * ), + * ?=?( DT _Atomic volatile * _Atomic restrict volatile *, forall( dtype D ) D * ); + +forall( dtype DT ) DT const restrict + * ?=?( DT const restrict * restrict volatile *, DT const restrict * ), + * ?=?( DT const restrict * restrict volatile *, void const * ), + * ?=?( DT const restrict * restrict volatile *, forall( dtype D ) D * ), + * ?=?( DT const restrict * _Atomic restrict volatile *, DT const restrict * ), + * ?=?( DT const restrict * _Atomic restrict volatile *, void const * ), + * ?=?( DT const restrict * _Atomic restrict volatile *, forall( dtype D ) D * ); + +forall( dtype DT ) DT const volatile + * ?=?( DT const volatile * restrict volatile *, DT const volatile * ), + * ?=?( DT const volatile * restrict volatile *, void const volatile * ), + * ?=?( DT const volatile * restrict volatile *, forall( dtype D ) D * ), + * ?=?( DT const volatile * _Atomic restrict volatile *, DT const volatile * ), + * ?=?( DT const volatile * _Atomic restrict volatile *, void const volatile * ), + * ?=?( DT const volatile * _Atomic restrict volatile *, forall( dtype D ) D * ); + +forall( dtype DT ) DT restrict volatile + * ?=?( DT restrict volatile * restrict volatile *, DT restrict volatile * ), + * ?=?( DT restrict volatile * restrict volatile *, void volatile * ), + * ?=?( DT restrict volatile * restrict volatile *, forall( dtype D ) D * ), + * ?=?( DT restrict volatile * _Atomic restrict volatile *, DT restrict volatile * ), + * ?=?( DT restrict volatile * _Atomic restrict volatile *, void volatile * ), + * ?=?( DT restrict volatile * _Atomic restrict volatile *, forall( dtype D ) D * ); + +forall( dtype DT ) DT _Atomic const restrict + * ?=?( DT _Atomic const restrict * restrict volatile *, + DT _Atomic const restrict * ), + * ?=?( DT _Atomic const restrict * restrict volatile *, + void const * ), + * ?=?( DT _Atomic const restrict * restrict volatile *, + forall( dtype D ) D * ), + * ?=?( DT _Atomic const restrict * _Atomic restrict volatile *, + DT _Atomic const restrict * ), + * ?=?( DT _Atomic const restrict * _Atomic restrict volatile *, + void const * ), + * ?=?( DT _Atomic const restrict * _Atomic restrict volatile *, + forall( dtype D ) D * ); + +forall( dtype DT ) DT _Atomic const volatile + * ?=?( DT _Atomic const volatile * restrict volatile *, + DT _Atomic const volatile * ), + * ?=?( DT _Atomic const volatile * restrict volatile *, + void const volatile * ), + * ?=?( DT _Atomic const volatile * restrict volatile *, + forall( dtype D ) D * ), + * ?=?( DT _Atomic const volatile * _Atomic restrict volatile *, + DT _Atomic const volatile * ), + * ?=?( DT _Atomic const volatile * _Atomic restrict volatile *, + void const volatile * ), + * ?=?( DT _Atomic const volatile * _Atomic restrict volatile *, + forall( dtype D ) D * ); + +forall( dtype DT ) DT _Atomic restrict volatile + * ?=?( DT _Atomic restrict volatile * restrict volatile *, + DT _Atomic restrict volatile * ), + * ?=?( DT _Atomic restrict volatile * restrict volatile *, + void volatile * ), + * ?=?( DT _Atomic restrict volatile * restrict volatile *, + forall( dtype D ) D * ), + * ?=?( DT _Atomic restrict volatile * _Atomic restrict volatile *, + DT _Atomic restrict volatile * ), + * ?=?( DT _Atomic restrict volatile * _Atomic restrict volatile *, + void volatile * ), + * ?=?( DT _Atomic restrict volatile * _Atomic restrict volatile *, + forall( dtype D ) D * ); + +forall( dtype DT ) DT const restrict volatile + * ?=?( DT const restrict volatile * restrict volatile *, + DT const restrict volatile * ), + * ?=?( DT const restrict volatile * restrict volatile *, + void const volatile * ), + * ?=?( DT const restrict volatile * restrict volatile *, + forall( dtype D ) D * ), + * ?=?( DT const restrict volatile * _Atomic restrict volatile *, + DT const restrict volatile * ), + * ?=?( DT const restrict volatile * _Atomic restrict volatile *, + void const volatile * ), + * ?=?( DT const restrict volatile * _Atomic restrict volatile *, + forall( dtype D ) D * ); + +forall( dtype DT ) DT _Atomic const restrict volatile + * ?=?( DT _Atomic const restrict volatile * restrict volatile *, + DT _Atomic const restrict volatile * ), + * ?=?( DT _Atomic const restrict volatile * restrict volatile *, + void const volatile * ), + * ?=?( DT _Atomic const restrict volatile * restrict volatile *, + forall( dtype D ) D * ), + * ?=?( DT _Atomic const restrict volatile * _Atomic restrict volatile *, + DT _Atomic const restrict volatile * ), + * ?=?( DT _Atomic const restrict volatile * _Atomic restrict volatile *, + void const volatile * ), + * ?=?( DT _Atomic const restrict volatile * _Atomic restrict volatile *, + forall( dtype D ) D * ); + +forall( dtype DT ) void + * ?=?( void * restrict volatile *, DT * ); + +forall( dtype DT ) void const + * ?=?( void const * restrict volatile *, DT const * ); + +forall( dtype DT ) void volatile + * ?=?( void volatile * restrict volatile *, DT volatile * ); + +forall( dtype DT ) void const volatile + * ?=?( void const volatile * restrict volatile *, DT const volatile * ); +\end{lstlisting} +\begin{rationale} +The pattern of overloadings for simple assignment resembles that of pointer increment and decrement, +except that the polymorphic pointer assignment functions declare a \lstinline$dtype$ parameter, +instead of a \lstinline$type$ parameter, because the left operand may be a pointer to an incomplete +type. +\end{rationale} + +For every complete structure or union type \lstinline$S$ there exist +% Don't use predefined: keep this out of prelude.cf. +\begin{lstlisting} +S ?=?( S volatile *, S ), ?=?( S _Atomic volatile *, S ); +\end{lstlisting} + +For every extended integer type \lstinline$X$ there exist +% Don't use predefined: keep this out of prelude.cf. +\begin{lstlisting} +X ?=?( X volatile *, X ), ?=?( X _Atomic volatile *, X ); +\end{lstlisting} + +For every complete enumerated type \lstinline$E$ there exist +% Don't use predefined: keep this out of prelude.cf. +\begin{lstlisting} +E ?=?( E volatile *, int ), ?=?( E _Atomic volatile *, int ); +\end{lstlisting} +\begin{rationale} +The right-hand argument is \lstinline$int$ because enumeration constants have type \lstinline$int$. +\end{rationale} + +\semantics +The structure assignment functions provide member-wise assignment; each non-array member and each +element of each array member of the right argument is assigned to the corresponding member or +element of the left argument using the assignment function defined for its type. All other +assignment functions have the same effect as the corresponding C assignment expression. +\begin{rationale} +Note that, by default, union assignment\index{deficiencies!union assignment} uses C semantics---that +is, bitwise copy---even if some of the union members have programmer-defined assignment functions. +\end{rationale} + + +\subsubsection{Compound assignment} + +\begin{lstlisting} +forall( type T ) T + * ?+=?( T * restrict volatile *, ptrdiff_t ), + * ?-=?( T * restrict volatile *, ptrdiff_t ), + * ?+=?( T * _Atomic restrict volatile *, ptrdiff_t ), + * ?-=?( T * _Atomic restrict volatile *, ptrdiff_t ); + +forall( type T ) T _Atomic + * ?+=?( T _Atomic * restrict volatile *, ptrdiff_t ), + * ?-=?( T _Atomic * restrict volatile *, ptrdiff_t ), + * ?+=?( T _Atomic * _Atomic restrict volatile *, ptrdiff_t ), + * ?-=?( T _Atomic * _Atomic restrict volatile *, ptrdiff_t ); + +forall( type T ) T const + * ?+=?( T const * restrict volatile *, ptrdiff_t ), + * ?-=?( T const * restrict volatile *, ptrdiff_t ), + * ?+=?( T const * _Atomic restrict volatile *, ptrdiff_t ), + * ?-=?( T const * _Atomic restrict volatile *, ptrdiff_t ); + +forall( type T ) T restrict + * ?+=?( T restrict * restrict volatile *, ptrdiff_t ), + * ?-=?( T restrict * restrict volatile *, ptrdiff_t ), + * ?+=?( T restrict * _Atomic restrict volatile *, ptrdiff_t ), + * ?-=?( T restrict * _Atomic restrict volatile *, ptrdiff_t ); + +forall( type T ) T volatile + * ?+=?( T volatile * restrict volatile *, ptrdiff_t ), + * ?-=?( T volatile * restrict volatile *, ptrdiff_t ), + * ?+=?( T volatile * _Atomic restrict volatile *, ptrdiff_t ), + * ?-=?( T volatile * _Atomic restrict volatile *, ptrdiff_t ); + +forall( type T ) T _Atomic const + * ?+=?( T _Atomic const restrict volatile *, ptrdiff_t ), + * ?-=?( T _Atomic const restrict volatile *, ptrdiff_t ), + * ?+=?( T _Atomic const _Atomic restrict volatile *, ptrdiff_t ), + * ?-=?( T _Atomic const _Atomic restrict volatile *, ptrdiff_t ); + +forall( type T ) T _Atomic restrict + * ?+=?( T _Atomic restrict * restrict volatile *, ptrdiff_t ), + * ?-=?( T _Atomic restrict * restrict volatile *, ptrdiff_t ), + * ?+=?( T _Atomic restrict * _Atomic restrict volatile *, ptrdiff_t ), + * ?-=?( T _Atomic restrict * _Atomic restrict volatile *, ptrdiff_t ); + +forall( type T ) T _Atomic volatile + * ?+=?( T _Atomic volatile * restrict volatile *, ptrdiff_t ), + * ?-=?( T _Atomic volatile * restrict volatile *, ptrdiff_t ), + * ?+=?( T _Atomic volatile * _Atomic restrict volatile *, ptrdiff_t ), + * ?-=?( T _Atomic volatile * _Atomic restrict volatile *, ptrdiff_t ); + +forall( type T ) T const restrict + * ?+=?( T const restrict * restrict volatile *, ptrdiff_t ), + * ?-=?( T const restrict * restrict volatile *, ptrdiff_t ), + * ?+=?( T const restrict * _Atomic restrict volatile *, ptrdiff_t ), + * ?-=?( T const restrict * _Atomic restrict volatile *, ptrdiff_t ); + +forall( type T ) T const volatile + * ?+=?( T const volatile * restrict volatile *, ptrdiff_t ), + * ?-=?( T const volatile * restrict volatile *, ptrdiff_t ), + * ?+=?( T const volatile * _Atomic restrict volatile *, ptrdiff_t ), + * ?-=?( T const volatile * _Atomic restrict volatile *, ptrdiff_t ); + +forall( type T ) T restrict volatile + * ?+=?( T restrict volatile * restrict volatile *, ptrdiff_t ), + * ?-=?( T restrict volatile * restrict volatile *, ptrdiff_t ), + * ?+=?( T restrict volatile * _Atomic restrict volatile *, ptrdiff_t ), + * ?-=?( T restrict volatile * _Atomic restrict volatile *, ptrdiff_t ); + +forall( type T ) T _Atomic const restrict + * ?+=?( T _Atomic const restrict * restrict volatile *, ptrdiff_t ), + * ?-=?( T _Atomic const restrict * restrict volatile *, ptrdiff_t ), + * ?+=?( T _Atomic const restrict * _Atomic restrict volatile *, ptrdiff_t ), + * ?-=?( T _Atomic const restrict * _Atomic restrict volatile *, ptrdiff_t ); + +forall( type T ) T _Atomic const volatile + * ?+=?( T _Atomic const volatile * restrict volatile *, ptrdiff_t ), + * ?-=?( T _Atomic const volatile * restrict volatile *, ptrdiff_t ), + * ?+=?( T _Atomic const volatile * _Atomic restrict volatile *, ptrdiff_t ), + * ?-=?( T _Atomic const volatile * _Atomic restrict volatile *, ptrdiff_t ); + +forall( type T ) T _Atomic restrict volatile + * ?+=?( T _Atomic restrict volatile * restrict volatile *, ptrdiff_t ), + * ?-=?( T _Atomic restrict volatile * restrict volatile *, ptrdiff_t ), + * ?+=?( T _Atomic restrict volatile * _Atomic restrict volatile *, ptrdiff_t ), + * ?-=?( T _Atomic restrict volatile * _Atomic restrict volatile *, ptrdiff_t ); + +forall( type T ) T const restrict volatile + * ?+=?( T const restrict volatile * restrict volatile *, ptrdiff_t ), + * ?-=?( T const restrict volatile * restrict volatile *, ptrdiff_t ), + * ?+=?( T const restrict volatile * _Atomic restrict volatile *, ptrdiff_t ), + * ?-=?( T const restrict volatile * _Atomic restrict volatile *, ptrdiff_t ); + +forall( type T ) T _Atomic const restrict volatile + * ?+=?( T _Atomic const restrict volatile * restrict volatile *, ptrdiff_t ), + * ?-=?( T _Atomic const restrict volatile * restrict volatile *, ptrdiff_t ), + * ?+=?( T _Atomic const restrict volatile * _Atomic restrict volatile *, ptrdiff_t ), + * ?-=?( T _Atomic const restrict volatile * _Atomic restrict volatile *, ptrdiff_t ); + +_Bool + ?*=?( _Bool volatile *, _Bool ), + ?/=?( _Bool volatile *, _Bool ), + ?+=?( _Bool volatile *, _Bool ), + ?-=?( _Bool volatile *, _Bool ), + ?%=?( _Bool volatile *, _Bool ), + ?<<=?( _Bool volatile *, int ), + ?>>=?( _Bool volatile *, int ), + ?&=?( _Bool volatile *, _Bool ), + ?^=?( _Bool volatile *, _Bool ), + ?|=?( _Bool volatile *, _Bool ); +char + ?*=?( char volatile *, char ), + ?/=?( char volatile *, char ), + ?+=?( char volatile *, char ), + ?-=?( char volatile *, char ), + ?%=?( char volatile *, char ), + ?<<=?( char volatile *, int ), + ?>>=?( char volatile *, int ), + ?&=?( char volatile *, char ), + ?^=?( char volatile *, char ), + ?|=?( char volatile *, char ); +unsigned char + ?*=?( unsigned char volatile *, unsigned char ), + ?/=?( unsigned char volatile *, unsigned char ), + ?+=?( unsigned char volatile *, unsigned char ), + ?-=?( unsigned char volatile *, unsigned char ), + ?%=?( unsigned char volatile *, unsigned char ), + ?<<=?( unsigned char volatile *, int ), + ?>>=?( unsigned char volatile *, int ), + ?&=?( unsigned char volatile *, unsigned char ), + ?^=?( unsigned char volatile *, unsigned char ), + ?|=?( unsigned char volatile *, unsigned char ); +signed char + ?*=?( signed char volatile *, signed char ), + ?/=?( signed char volatile *, signed char ), + ?+=?( signed char volatile *, signed char ), + ?-=?( signed char volatile *, signed char ), + ?%=?( signed char volatile *, signed char ), + ?<<=?( signed char volatile *, int ), + ?>>=?( signed char volatile *, int ), + ?&=?( signed char volatile *, signed char ), + ?^=?( signed char volatile *, signed char ), + ?|=?( signed char volatile *, signed char ); +short int + ?*=?( short int volatile *, short int ), + ?/=?( short int volatile *, short int ), + ?+=?( short int volatile *, short int ), + ?-=?( short int volatile *, short int ), + ?%=?( short int volatile *, short int ), + ?<<=?( short int volatile *, int ), + ?>>=?( short int volatile *, int ), + ?&=?( short int volatile *, short int ), + ?^=?( short int volatile *, short int ), + ?|=?( short int volatile *, short int ); +unsigned short int + ?*=?( unsigned short int volatile *, unsigned short int ), + ?/=?( unsigned short int volatile *, unsigned short int ), + ?+=?( unsigned short int volatile *, unsigned short int ), + ?-=?( unsigned short int volatile *, unsigned short int ), + ?%=?( unsigned short int volatile *, unsigned short int ), + ?<<=?( unsigned short int volatile *, int ), + ?>>=?( unsigned short int volatile *, int ), + ?&=?( unsigned short int volatile *, unsigned short int ), + ?^=?( unsigned short int volatile *, unsigned short int ), + ?|=?( unsigned short int volatile *, unsigned short int ); +int + ?*=?( int volatile *, int ), + ?/=?( int volatile *, int ), + ?+=?( int volatile *, int ), + ?-=?( int volatile *, int ), + ?%=?( int volatile *, int ), + ?<<=?( int volatile *, int ), + ?>>=?( int volatile *, int ), + ?&=?( int volatile *, int ), + ?^=?( int volatile *, int ), + ?|=?( int volatile *, int ); +unsigned int + ?*=?( unsigned int volatile *, unsigned int ), + ?/=?( unsigned int volatile *, unsigned int ), + ?+=?( unsigned int volatile *, unsigned int ), + ?-=?( unsigned int volatile *, unsigned int ), + ?%=?( unsigned int volatile *, unsigned int ), + ?<<=?( unsigned int volatile *, int ), + ?>>=?( unsigned int volatile *, int ), + ?&=?( unsigned int volatile *, unsigned int ), + ?^=?( unsigned int volatile *, unsigned int ), + ?|=?( unsigned int volatile *, unsigned int ); +long int + ?*=?( long int volatile *, long int ), + ?/=?( long int volatile *, long int ), + ?+=?( long int volatile *, long int ), + ?-=?( long int volatile *, long int ), + ?%=?( long int volatile *, long int ), + ?<<=?( long int volatile *, int ), + ?>>=?( long int volatile *, int ), + ?&=?( long int volatile *, long int ), + ?^=?( long int volatile *, long int ), + ?|=?( long int volatile *, long int ); +unsigned long int + ?*=?( unsigned long int volatile *, unsigned long int ), + ?/=?( unsigned long int volatile *, unsigned long int ), + ?+=?( unsigned long int volatile *, unsigned long int ), + ?-=?( unsigned long int volatile *, unsigned long int ), + ?%=?( unsigned long int volatile *, unsigned long int ), + ?<<=?( unsigned long int volatile *, int ), + ?>>=?( unsigned long int volatile *, int ), + ?&=?( unsigned long int volatile *, unsigned long int ), + ?^=?( unsigned long int volatile *, unsigned long int ), + ?|=?( unsigned long int volatile *, unsigned long int ); +long long int + ?*=?( long long int volatile *, long long int ), + ?/=?( long long int volatile *, long long int ), + ?+=?( long long int volatile *, long long int ), + ?-=?( long long int volatile *, long long int ), + ?%=?( long long int volatile *, long long int ), + ?<<=?( long long int volatile *, int ), + ?>>=?( long long int volatile *, int ), + ?&=?( long long int volatile *, long long int ), + ?^=?( long long int volatile *, long long int ), + ?|=?( long long int volatile *, long long int ); +unsigned long long int + ?*=?( unsigned long long int volatile *, unsigned long long int ), + ?/=?( unsigned long long int volatile *, unsigned long long int ), + ?+=?( unsigned long long int volatile *, unsigned long long int ), + ?-=?( unsigned long long int volatile *, unsigned long long int ), + ?%=?( unsigned long long int volatile *, unsigned long long int ), + ?<<=?( unsigned long long int volatile *, int ), + ?>>=?( unsigned long long int volatile *, int ), + ?&=?( unsigned long long int volatile *, unsigned long long int ), + ?^=?( unsigned long long int volatile *, unsigned long long int ), + ?|=?( unsigned long long int volatile *, unsigned long long int ); +float + ?*=?( float volatile *, float ), + ?/=?( float volatile *, float ), + ?+=?( float volatile *, float ), + ?-=?( float volatile *, float ); +double + ?*=?( double volatile *, double ), + ?/=?( double volatile *, double ), + ?+=?( double volatile *, double ), + ?-=?( double volatile *, double ); +long double + ?*=?( long double volatile *, long double ), + ?/=?( long double volatile *, long double ), + ?+=?( long double volatile *, long double ), + ?-=?( long double volatile *, long double ); +_Complex float + ?*=?( _Complex float volatile *, _Complex float ), + ?/=?( _Complex float volatile *, _Complex float ), + ?+=?( _Complex float volatile *, _Complex float ), + ?-=?( _Complex float volatile *, _Complex float ); +_Complex double + ?*=?( _Complex double volatile *, _Complex double ), + ?/=?( _Complex double volatile *, _Complex double ), + ?+=?( _Complex double volatile *, _Complex double ), + ?-=?( _Complex double volatile *, _Complex double ); +_Complex long double + ?*=?( _Complex long double volatile *, _Complex long double ), + ?/=?( _Complex long double volatile *, _Complex long double ), + ?+=?( _Complex long double volatile *, _Complex long double ), + ?-=?( _Complex long double volatile *, _Complex long double ); +\end{lstlisting} + +For every extended integer type \lstinline$X$ there exist +% Don't use predefined: keep this out of prelude.cf. +\begin{lstlisting} +?*=?( X volatile *, X ), +?/=?( X volatile *, X ), +?+=?( X volatile *, X ), +?-=?( X volatile *, X ), +?%=?( X volatile *, X ), +?<<=?( X volatile *, int ), +?>>=?( X volatile *, int ), +?&=?( X volatile *, X ), +?^=?( X volatile *, X ), +?|=?( X volatile *, X ); +\end{lstlisting} + +For every complete enumerated type \lstinline$E$ there exist +% Don't use predefined: keep this out of prelude.cf. +\begin{lstlisting} +?*=?( E volatile *, E ), +?/=?( E volatile *, E ), +?+=?( E volatile *, E ), +?-=?( E volatile *, E ), +?%=?( E volatile *, E ), +?<<=?( E volatile *, int ), +?>>=?( E volatile *, int ), +?&=?( E volatile *, E ), +?^=?( E volatile *, E ), +?|=?( E volatile *, E ); +\end{lstlisting} + + +\subsection{Comma operator} + +\begin{syntax} +\lhs{expression} +\rhs \nonterm{assignment-expression} +\rhs \nonterm{expression} \lstinline$,$ \nonterm{assignment-expression} +\end{syntax} + +\semantics +In the comma expression ``\lstinline$a, b$'', the first operand is interpreted as +``\lstinline$( void )(a)$'', which shall be unambiguous\index{ambiguous interpretation}. The +interpretations of the expression are the interpretations of the second operand. + + +\section{Constant expressions} + + +\section{Declarations} + +\begin{syntax} +\oldlhs{declaration} +\rhs \nonterm{type-declaration} +\rhs \nonterm{spec-definition} +\end{syntax} + +\constraints +If an identifier has no linkage\index{no linkage}, there shall be no more than one declaration of +the identifier ( in a declarator or type specifier ) with compatible types in the same scope and in +the same name space, except that: +\begin{itemize} +\item +a typedef name may be redefined to denote the same type as it currently does, provided that type is +not a variably modified type; +\item +tags may be redeclared as specified in section 6.7.2.3 of the {\c11} standard. +\end{itemize} +\begin{rationale} +This constraint adds the phrase ``with compatible types'' to the {\c11} constraint, to allow +overloading. +\end{rationale} + +An identifier declared by a type declaration shall not be redeclared as a parameter in a function +definition whose declarator includes an identifier list. +\begin{rationale} +This restriction echos {\c11}'s ban on the redeclaration of typedef names as parameters. This +avoids an ambiguity between old-style function declarations and new-style function prototypes: +\begin{lstlisting} +void f( Complex, // ... 3000 characters ... +void g( Complex, // ... 3000 characters ... +int Complex; { ... } +\end{lstlisting} +Without the rule, \lstinline$Complex$ would be a type in the first case, and a parameter name in the +second. +\end{rationale} + + +\setcounter{subsection}{1} +\subsection{Type specifiers} + +\begin{syntax} +\oldlhs{type-specifier} +\rhs \nonterm{forall-specifier} +\end{syntax} + +\semantics +Forall specifiers are discussed in \VRef{forall}. + + +\subsubsection{Structure and union specifiers} + +\semantics +\CFA extends the {\c11} definition of \define{anonymous structure} to include structure +specifiers with tags, and extends the {\c11} definition of \define{anonymous union} to include union +specifiers with tags. +\begin{rationale} +This extension imitates an extension in the Plan 9 C compiler \cite{Thompson90new}. +\end{rationale} + +\examples +\begin{lstlisting} +struct point {@\impl{point}@ + int x, y; +}; +struct color_point {@\impl{color_point}@ + enum { RED, BLUE, GREEN } color; + struct point; +}; +struct color_point cp; +cp.x = 0; +cp.color = RED; + +struct literal {@\impl{literal}@ + enum { NUMBER, STRING } tag; + union { + double n; + char *s; + }; +}; +struct literal *next; +int length; +extern int strlen( const char * ); +... +if ( next->tag == STRING ) length = strlen( next->s ); +\end{lstlisting} + + +\setcounter{subsubsection}{4} +\subsubsection{Forall specifiers}\label{forall} + +\begin{syntax} +\lhs{forall-specifier} +\rhs \lstinline$forall$ \lstinline$($ \nonterm{type-parameter-list} \lstinline$)$ +\end{syntax} + +\constraints +If the \nonterm{declaration-specifiers} of a declaration that contains a \nonterm{forall-specifier} +declares a structure or union tag, the types of the members of the structure or union shall not use +any of the type identifiers declared by the \nonterm{type-parameter-list}. +\begin{rationale} +This sort of declaration is illegal because the scope of the type identifiers ends at the end of the +declaration, but the scope of the structure tag does not. +\begin{lstlisting} +forall( type T ) struct Pair { T a, b; } mkPair( T, T ); // illegal +\end{lstlisting} +If an instance of \lstinline$struct Pair$ was declared later in the current scope, what would the +members' type be? +\end{rationale} + +\semantics +The \nonterm{type-parameter-list}s and assertions of the \nonterm{forall-specifier}s declare type +identifiers, function and object identifiers with no linkage\index{no linkage}. + +If, in the declaration ``\lstinline$T D1$'', \lstinline$T$ contains \nonterm{forall-specifier}s and +\lstinline$D1$ has the form +\begin{lstlisting} +D( @\normalsize\nonterm{parameter-type-list}@ ) +\end{lstlisting} +then a type identifier declared by one of the \nonterm{forall-specifier}s is an \define{inferred + parameter} of the function declarator if and only if it is not an inferred parameter of a function +declarator in \lstinline$D$, and it is used in the type of a parameter in the following +\nonterm{type-parameter-list} or it and an inferred parameter are used as arguments of a +specification\index{specification} in one of the \nonterm{forall-specifier}s. The identifiers +declared by assertions that use an inferred parameter of a function declarator are assertion +parameters\index{assertion parameters} of that function declarator. +\begin{rationale} +Since every inferred parameter is used by some parameter, inference can be understood as a single +bottom-up pass over the expression tree, that only needs to apply local reasoning at each node. + +If this restriction were lifted, it would be possible to write +\begin{lstlisting} +forall( type T ) T * alloc( void );@\use{alloc}@ +int *p = alloc(); +\end{lstlisting} +Here \lstinline$alloc()$ would receive \lstinline$int$ as an inferred argument, and return an +\lstinline$int *$. In general, if a call to \lstinline$alloc()$ is a subexpression of an expression +involving polymorphic functions and overloaded identifiers, there could be considerable distance +between the call and the subexpression that causes \lstinline$T$ to be bound. + +With the current restriction, \lstinline$alloc()$ must be given an argument that determines +\lstinline$T$: +\begin{lstlisting} +forall( type T ) T * alloc( T initial_value );@\use{alloc}@ +\end{lstlisting} +\end{rationale} + +If a function declarator is part of a function definition, its inferred parameters and assertion +parameters have block scope\index{block scope}; otherwise, identifiers declared by assertions have a +\define{declaration scope}, which terminates at the end of the \nonterm{declaration}. + +A function type that has at least one inferred parameter is a \define{polymorphic function} type. +Function types with no inferred parameters are \define{monomorphic function} types. One function +type is \define{less polymorphic} than another if it has fewer inferred parameters, or if it has the +same number of inferred parameters and fewer of its explicit parameters have types that depend on an +inferred parameter. + +The names of inferred parameters and the order of identifiers in forall specifiers are not relevant +to polymorphic function type compatibility. Let $f$ and $g$ be two polymorphic function types with +the same number of inferred parameters, and let $f_i$ and $g_i$ be the inferred parameters of $f$ +and $g$ in their order of occurance in the function types' \nonterm{parameter-type-list}s. Let $f'$ +be $f$ with every occurrence of $f_i$ replaced by $g_i$, for all $i$. Then $f$ and $g$ are +compatible types\index{compatible type} if $f'$'s and $g$'s return types and parameter lists are +compatible, and if for every assertion parameter of $f'$ there is an assertion parameter in $g$ with +the same identifier and compatible type, and vice versa. + +\examples +Consider these analogous monomorphic and polymorphic declarations. +\begin{lstlisting} +int fi( int ); +forall( type T ) T fT( T ); +\end{lstlisting} +\lstinline$fi()$ takes an \lstinline$int$ and returns an \lstinline$int$. \lstinline$fT()$ takes a +\lstinline$T$ and returns a \lstinline$T$, for any type \lstinline$T$. +\begin{lstlisting} +int (*pfi )( int ) = fi; +forall( type T ) T (*pfT )( T ) = fT; +\end{lstlisting} +\lstinline$pfi$ and \lstinline$pfT$ are pointers to functions. \lstinline$pfT$ is not +polymorphic, but the function it points at is. +\begin{lstlisting} +int (*fvpfi( void ))( int ) { + return pfi; +} +forall( type T ) T (*fvpfT( void ))( T ) { + return pfT; +} +\end{lstlisting} +\lstinline$fvpfi()$ and \lstinline$fvpfT()$ are functions taking no arguments and returning pointers +to functions. \lstinline$fvpfT()$ is monomorphic, but the function that its return value points +at is polymorphic. +\begin{lstlisting} +forall( type T ) int ( *fTpfi( T ) )( int ); +forall( type T ) T ( *fTpfT( T ) )( T ); +forall( type T, type U ) U ( *fTpfU( T ) )( U ); +\end{lstlisting} +\lstinline$fTpfi()$ is a polymorphic function that returns a pointer to a monomorphic function +taking an integer and returning an integer. It could return \lstinline$pfi$. \lstinline$fTpfT()$ +is subtle: it is a polymorphic function returning a \emph{monomorphic} function taking and returning +\lstinline$T$, where \lstinline$T$ is an inferred parameter of \lstinline$fTpfT()$. For instance, +in the expression ``\lstinline$fTpfT(17)$'', \lstinline$T$ is inferred to be \lstinline$int$, and +the returned value would have type \lstinline$int ( * )( int )$. ``\lstinline$fTpfT(17)(13)$'' and +``\lstinline$fTpfT("yes")("no")$'' are legal, but ``\lstinline$fTpfT(17)("no")$'' is illegal. +\lstinline$fTpfU()$ is polymorphic ( in type \lstinline$T$), and returns a pointer to a function that +is polymorphic ( in type \lstinline$U$). ``\lstinline$f5(17)("no")$'' is a legal expression of type +\lstinline$char *$. +\begin{lstlisting} +forall( type T, type U, type V ) U * f( T *, U, V * const ); +forall( type U, type V, type W ) U * g( V *, U, W * const ); +\end{lstlisting} +The functions \lstinline$f()$ and \lstinline$g()$ have compatible types. Let \(f\) and \(g\) be +their types; then \(f_1\) = \lstinline$T$, \(f_2\) = \lstinline$U$, \(f_3\) = \lstinline$V$, \(g_1\) += \lstinline$V$, \(g_2\) = \lstinline$U$, and \(g_3\) = \lstinline$W$. Replacing every \(f_i\) +by \(g_i\) in \(f\) gives +\begin{lstlisting} +forall( type V, type U, type W ) U * f( V *, U, W * const ); +\end{lstlisting} +which has a return type and parameter list that is compatible with \(g\). +\begin{rationale} +The word ``\lstinline$type$'' in a forall specifier is redundant at the moment, but I want to leave +room for inferred parameters of ordinary types in case parameterized types get added one day. + +Even without parameterized types, I might try to allow +\begin{lstlisting} +forall( int n ) int sum( int vector[n] ); +\end{lstlisting} +but C currently rewrites array parameters as pointer parameters, so the effects of such a change +require more thought. +\end{rationale} + +\begin{rationale} +A polymorphic declaration must do two things: it must introduce type parameters, and it must apply +assertions to those types. Adding this to existing C declaration syntax and semantics was delicate, +and not entirely successful. + +C depends on declaration-before-use, so a forall specifier must introduce type names before they can +be used in the declaration specifiers. This could be done by making the forall specifier part of +the declaration specifiers, or by making it a new introductory clause of declarations. + +Assertions are also part of polymorphic function types, because it must be clear which functions +have access to the assertion parameters declared by the assertions. All attempts to put assertions +inside an introductory clause produced complex semantics and confusing code. Building them into the +declaration specifiers could be done by placing them in the function's parameter list, or in a +forall specifier that is a declaration specifier. Assertions are also used with type parameters of +specifications, and by type declarations. For consistency's sake it seems best to attach assertions +to the type declarations in forall specifiers, which means that forall specifiers must be +declaration specifiers. +\end{rationale} +%HERE + + +\subsection{Type qualifiers} + +\CFA defines a new type qualifier \lstinline$lvalue$\impl{lvalue}\index{lvalue}. +\begin{syntax} +\oldlhs{type-qualifier} +\rhs \lstinline$lvalue$ +\end{syntax} + +\constraints +\lstinline$restrict$\index{register@{\lstinline$restrict$}} Types other than type parameters and +pointer types whose referenced type is an object type shall not be restrict-qualified. + +\semantics +An object's type may be a restrict-qualified type parameter. \lstinline$restrict$ does not +establish any special semantics in that case. + +\begin{rationale} +\CFA loosens the constraint on the restrict qualifier so that restrict-qualified pointers may be +passed to polymorphic functions. +\end{rationale} + +\lstinline$lvalue$ may be used to qualify the return type of a function type. Let \lstinline$T$ be +an unqualified version of a type; then the result of calling a function with return type +\lstinline$lvalue T$ is a modifiable lvalue\index{modifiable lvalue} of type \lstinline$T$. +\lstinline$const$\use{const} and \lstinline$volatile$\use{volatile} qualifiers may also be added to +indicate that the function result is a constant or volatile lvalue. +\begin{rationale} +The \lstinline$const$ and \lstinline$volatile$ qualifiers can only be sensibly used to qualify the +return type of a function if the \lstinline$lvalue$ qualifier is also used. +\end{rationale} + +An {lvalue}-qualified type may be used in a cast expression\index{cast expression} if the operand is +an lvalue; the result of the expression is an lvalue. + +\begin{rationale} +\lstinline$lvalue$ provides some of the functionality of {\CC}'s ``\lstinline$T&$'' ( reference to +object of type \lstinline$T$) type. Reference types have four uses in {\CC}. +\begin{itemize} +\item +They are necessary for user-defined operators that return lvalues, such as ``subscript'' and +``dereference''. + +\item +A reference can be used to define an alias for a complicated lvalue expression, as a way of getting +some of the functionality of the Pascal \lstinline$with$ statement. The following {\CC} code gives +an example. +\begin{lstlisting} +{ + char &code = long_name.some_field[i].data->code; + code = toupper( code ); +} +\end{lstlisting} +This is not very useful. + +\item +A reference parameter can be used to allow a function to modify an argument without forcing the +caller to pass the address of the argument. This is most useful for user-defined assignment +operators. In {\CC}, plain assignment is done by a function called ``\lstinline$operator=$'', and +the two expressions +\begin{lstlisting} +a = b; +operator=( a, b ); +\end{lstlisting} +are equivalent. If \lstinline$a$ and \lstinline$b$ are of type \lstinline$T$, then the first +parameter of \lstinline$operator=$ must have type ``\lstinline$T&$''. It cannot have type +\lstinline$T$, because then assignment couldn't alter the variable, and it can't have type +``\lstinline$T *$'', because the assignment would have to be written ``\lstinline$&a = b;$''. + +In the case of user-defined operators, this could just as well be handled by using pointer types and +by changing the rewrite rules so that ``\lstinline$a = b;$'' is equivalent to +``\lstinline$operator=(&( a), b )$''. Reference parameters of ``normal'' functions are Bad Things, +because they remove a useful property of C function calls: an argument can only be modified by a +function if it is preceded by ``\lstinline$&$''. + +\item +References to const-qualified\index{const-qualified} types can be used instead of value parameters. +Given the {\CC} function call ``\lstinline$fiddle( a_thing )$'', where the type of +\lstinline$a_thing$ is \lstinline$Thing$, the type of \lstinline$fiddle$ could be either of +\begin{lstlisting} +void fiddle( Thing ); +void fiddle( const Thing & ); +\end{lstlisting} +If the second form is used, then constructors and destructors are not invoked to create a temporary +variable at the call site ( and it is bad style for the caller to make any assumptions about such +things), and within \lstinline$fiddle$ the parameter is subject to the usual problems caused by +aliases. The reference form might be chosen for efficiency's sake if \lstinline$Thing$s are too +large or their constructors or destructors are too expensive. An implementation may switch between +them without causing trouble for well-behaved clients. This leaves the implementor to define ``too +large'' and ``too expensive''. + +I propose to push this job onto the compiler by allowing it to implement +\begin{lstlisting} +void fiddle( const volatile Thing ); +\end{lstlisting} +with call-by-reference. Since it knows all about the size of \lstinline$Thing$s and the parameter +passing mechanism, it should be able to come up with a better definition of ``too large'', and may +be able to make a good guess at ``too expensive''. +\end{itemize} + +In summary, since references are only really necessary for returning lvalues, I'll only provide +lvalue functions. +\end{rationale} + + +\setcounter{subsection}{8} +\subsection{Initialization} + +An expression that is used as an \nonterm{initializer} is treated as being cast to the type of the +object being initialized. An expression used in an \nonterm{initializer-list} is treated as being +cast to the type of the aggregate member that it initializes. In either case the cast must have a +single unambiguous interpretation\index{interpretations}. + + +\setcounter{subsection}{10} +\subsection{Specification definitions} + +\begin{syntax} +\lhs{spec-definition} +\rhs \lstinline$spec$ \nonterm{identifier} + \lstinline$($ \nonterm{type-parameter-list} \lstinline$)$ + \lstinline${$ \nonterm{spec-declaration-list}\opt \lstinline$}$ +\lhs{spec-declaration-list} +\rhs \nonterm{spec-declaration} \lstinline$;$ +\rhs \nonterm{spec-declaration-list} \nonterm{spec-declaration} \lstinline$;$ +\lhs{spec-declaration} +\rhs \nonterm{specifier-qualifier-list} \nonterm{declarator-list} +\lhs{declarator-list} +\rhs \nonterm{declarator} +\rhs \nonterm{declarator-list} \lstinline$,$ \nonterm{declarator} +\end{syntax} +\begin{rationale} +The declarations allowed in a specification are much the same as those allowed in a structure, +except that bit fields are not allowed, and incomplete types\index{incomplete types} and function +types are allowed. +\end{rationale} + +\semantics +A \define{specification definition} defines a name for a \define{specification}: a parameterized +collection of object and function declarations. + +The declarations in a specification consist of the declarations in the +\nonterm{spec-declaration-list} and declarations produced by any assertions in the +\nonterm{spec-parameter-list}. If the collection contains two declarations that declare the same +identifier and have compatible types, they are combined into one declaration with the composite type +constructed from the two types. + + +\subsubsection{Assertions} +\begin{syntax} +\lhs{assertion-list} +\rhs \nonterm{assertion} +\rhs \nonterm{assertion-list} \nonterm{assertion} +\lhs{assertion} +\rhs \lstinline$|$ \nonterm{identifier} \lstinline$($ \nonterm{type-name-list} \lstinline$)$ +\rhs \lstinline$|$ \nonterm{spec-declaration} +\lhs{type-name-list} +\rhs \nonterm{type-name} +\rhs \nonterm{type-name-list} \lstinline$,$ \nonterm{type-name} +\end{syntax} + +\constraints +The \nonterm{identifier} in an assertion that is not a \nonterm{spec-declaration} shall be the name +of a specification. The \nonterm{type-name-list} shall contain one \nonterm{type-name} argument for +each \nonterm{type-parameter} in that specification's \nonterm{spec-parameter-list}. If the +\nonterm{type-parameter} uses type-class \lstinline$type$\use{type}, the argument shall be the type +name of an object type\index{object types}; if it uses \lstinline$dtype$, the argument shall be the +type name of an object type or an incomplete type\index{incomplete types}; and if it uses +\lstinline$ftype$, the argument shall be the type name of a function type\index{function types}. + +\semantics +An \define{assertion} is a declaration of a collection of objects and functions, called +\define{assertion parameters}. + +The assertion parameters produced by an assertion that applies the name of a specification to type +arguments are found by taking the declarations specified in the specification and treating each of +the specification's parameters as a synonym for the corresponding \nonterm{type-name} argument. + +The collection of assertion parameters produced by the \nonterm{assertion-list} are found by +combining the declarations produced by each assertion. If the collection contains two declarations +that declare the same identifier and have compatible types, they are combined into one declaration +with the composite type\index{composite type} constructed from the two types. + +\examples +\begin{lstlisting} +forall( type T | T ?*?( T, T ))@\use{?*?}@ +T square( T val ) {@\impl{square}@ + return val + val; +} + +context summable( type T ) {@\impl{summable}@ + T ?+=?( T *, T );@\use{?+=?}@ + const T 0;@\use{0}@ +}; +context list_of( type List, type Element ) {@\impl{list_of}@ + Element car( List ); + List cdr( List ); + List cons( Element, List ); + List nil; + int is_nil( List ); +}; +context sum_list( type List, type Element | summable( Element ) | list_of( List, Element ) ) {}; +\end{lstlisting} +\lstinline$sum_list$ contains seven declarations, which describe a list whose elements can be added +up. The assertion ``\lstinline$|sum_list( i_list, int )$''\use{sum_list} produces the assertion +parameters +\begin{lstlisting} +int ?+=?( int *, int ); +const int 0; +int car( i_list ); +i_list cdr( i_list ); +i_list cons( int, i_list ); +i_list nil; +int is_nil; +\end{lstlisting} + +\subsection{Type declarations} +\begin{syntax} +\lhs{type-parameter-list} +\rhs \nonterm{type-parameter} +\rhs \nonterm{type-parameter-list} \lstinline$,$ \nonterm{type-parameter} +\lhs{type-parameter} +\rhs \nonterm{type-class} \nonterm{identifier} \nonterm{assertion-list}\opt +\lhs{type-class} +\rhs \lstinline$type$ +\rhs \lstinline$dtype$ +\rhs \lstinline$ftype$ +\lhs{type-declaration} +\rhs \nonterm{storage-class-specifier}\opt \lstinline$type$ \nonterm{type-declarator-list} \verb|;| +\lhs{type-declarator-list} +\rhs \nonterm{type-declarator} +\rhs \nonterm{type-declarator-list} \lstinline$,$ \nonterm{type-declarator} +\lhs{type-declarator} +\rhs \nonterm{identifier} \nonterm{assertion-list}\opt \lstinline$=$ \nonterm{type-name} +\rhs \nonterm{identifier} \nonterm{assertion-list}\opt +\end{syntax} + +\constraints +If a type declaration has block scope, and the declared identifier has external or internal linkage, +the declaration shall have no initializer for the identifier. + +\semantics +A \nonterm{type-parameter} or a \nonterm{type-declarator} declares an identifier to be a type +name\index{type names} for a type incompatible with all other types. + +An identifier declared by a \nonterm{type-parameter} has no linkage\index{no linkage}. Identifiers +declared with type-class \lstinline$type$\use{type} are object types\index{object types}; those +declared with type-class \lstinline$dtype$\use{dtype} are incomplete types\index{incomplete types}; +and those declared with type-class \lstinline$ftype$\use{ftype} are function types\index{function + types}. The identifier has block scope\index{block scope} that terminates at the end of the +\nonterm{spec-declaration-list} or polymorphic function that contains the \nonterm{type-parameter}. + +A \nonterm{type-declarator} with an initializer\index{initializer} is a \define{type definition}. +The declared identifier is an incomplete type\index{incomplete types} within the initializer, and an +object type\index{object types} after the end of the initializer. The type in the initializer is +called the \define{implementation type}. Within the scope of the declaration, implicit +conversions\index{implicit conversions} can be performed between the defined type and the +implementation type, and between pointers to the defined type and pointers to the implementation +type. + +A type declaration without an initializer\index{initializer} and without a storage-class +specifier\index{storage-class specifiers} or with storage-class specifier +\lstinline$static$\use{static} defines an incomplete type\index{incomplete types}. If a translation +unit\index{translation unit} or block \index{block} contains one or more such declarations for an +identifier, it must contain exactly one definition of the identifier ( but not in an enclosed block, +which would define a new type known only within that block). +\begin{rationale} +Incomplete type declarations allow compact mutually-recursive types. +\begin{lstlisting} +type t1; // Incomplete type declaration. +type t2 = struct { t1 * p; ... }; +type t1 = struct { t2 * p; ... }; +\end{lstlisting} +Without them, mutual recursion could be handled by declaring mutually recursive structures, then +initializing the types to those structures. +\begin{lstlisting} +struct s1; +type t2 = struct s2 { struct s1 * p; ... }; +type t1 = struct s1 { struct s2 * p; ... }; +\end{lstlisting} +This introduces extra names, and may force the programmer to cast between the types and their +implementations. +\end{rationale} + +A type declaration without an initializer and with storage-class specifier \index{storage-class + specifiers} \lstinline$extern$\use{extern} is an \define{opaque type declaration}. Opaque types +are object types\index{object types}. An opaque type is not a \nonterm{constant-expression}; +neither is a structure or union that has a member whose type is not a \nonterm{constant-expression}. +Every other object type\index{object types} is a \nonterm{constant-expression}. Objects with static +storage duration shall be declared with a type that is a \nonterm{constant-expression}. +\begin{rationale} +Type declarations can declare identifiers with external linkage, whereas typedef declarations +declare identifiers that only exist within a translation unit. These opaque types can be used in +declarations, but the implementation of the type is not visible. + +Static objects can not have opaque types because space for them would have to be allocated at +program start-up. This is a deficiency\index{deficiencies!static opaque objects}, but I don't want +to deal with ``module initialization'' code just now. +\end{rationale} + +An incomplete type\index{incomplete types} which is not a qualified version\index{qualified type} of +a type is a value of type-class\index{type-class} \lstinline$dtype$. An object type\index{object + types} which is not a qualified version of a type is a value of type-classes \lstinline$type$ and +\lstinline$dtype$. A function type\index{function types} is a value of type-class +\lstinline$ftype$. +\begin{rationale} +Syntactically, a type value is a \nonterm{type-name}, which is a declaration for an object which +omits the identifier being declared. + +Object types are precisely the types that can be instantiated. Type qualifiers are not included in +type values because the compiler needs the information they provide at compile time to detect +illegal statements or to produce efficient machine instructions. For instance, the code that a +compiler must generate to manipulate an object that has volatile-qualified type may be different +from the code to manipulate an ordinary object. + +Type qualifiers are a weak point of C's type system. Consider the standard library function +\lstinline$strchr()$ which, given a string and a character, returns a pointer to the first +occurrence of the character in the string. +\begin{lstlisting} +char *strchr( const char *s, int c ) {@\impl{strchr}@ + char real_c = c; // done because c was declared as int. + for ( ; *s != real_c; s++ ) + if ( *s == '\0' ) return NULL; + return ( char * )s; +} +\end{lstlisting} +The parameter \lstinline$s$ must be \lstinline$const char *$, because \lstinline$strchr()$ might be +used to search a constant string, but the return type must be \lstinline$char *$, because the result +might be used to modify a non-constant string. Hence the body must perform a cast, and ( even worse) +\lstinline$strchr()$ provides a type-safe way to attempt to modify constant strings. What is needed +is some way to say that \lstinline$s$'s type might contain qualifiers, and the result type has +exactly the same qualifiers. Polymorphic functions do not provide a fix for this +deficiency\index{deficiencies!pointers to qualified types}, because type qualifiers are not part of +type values. Instead, overloading can be used to define \lstinline$strchr()$ for each combination +of qualifiers. +\end{rationale} + +\begin{rationale} +Since incomplete types\index{incomplete types} are not type values, they can not be used as the +initializer in a type declaration, or as the type of a structure or union member. This prevents the +declaration of types that contain each other. +\begin{lstlisting} +type t1; +type t2 = t1; // illegal: incomplete type t1. +type t1 = t2; +\end{lstlisting} + +The initializer in a file-scope declaration must be a constant expression. This means type +declarations can not build on opaque types, which is a deficiency\index{deficiencies!nesting opaque + types}. +\begin{lstlisting} +extern type Huge; // extended-precision integer type. +type Rational = struct { + Huge numerator, denominator; // illegal +}; +struct Pair { + Huge first, second; // legal +}; +\end{lstlisting} +Without this restriction, \CFA might require ``module initialization'' code ( since +\lstinline$Rational$ has external linkage, it must be created before any other translation unit +instantiates it), and would force an ordering on the initialization of the translation unit that +defines \lstinline$Huge$ and the translation that declares \lstinline$Rational$. + +A benefit of the restriction is that it prevents the declaration in separate translation units of +types that contain each other, which would be hard to prevent otherwise. +\begin{lstlisting} +// File a.c: + extern type t1; + type t2 = struct { t1 f1; ... } // illegal +// File b.c: + extern type t2; + type t1 = struct { t2 f2; ... } // illegal +\end{lstlisting} +\end{rationale} + +\begin{rationale} +Since a \nonterm{type-declaration} is a \nonterm{declaration} and not a +\nonterm{struct-declaration}, type declarations can not be structure members. The form of +\nonterm{type-declaration} forbids arrays of, pointers to, and functions returning \lstinline$type$. +Hence the syntax of \nonterm{type-specifier} does not have to be extended to allow type-valued +expressions. It also side-steps the problem of type-valued expressions producing different values +in different declarations. + +Since a type declaration is not a \nonterm{parameter-declaration}, functions can not have explicit +type parameters. This may be too restrictive, but it attempts to make compilation simpler. Recall +that when traditional C scanners read in an identifier, they look it up in the symbol table to +determine whether or not it is a typedef name, and return a ``type'' or ``identifier'' token +depending on what they find. A type parameter would add a type name to the current scope. The +scope manipulations involved in parsing the declaration of a function that takes function pointer +parameters and returns a function pointer may just be too complicated. + +Explicit type parameters don't seem to be very useful, anyway, because their scope would not include +the return type of the function. Consider the following attempt to define a type-safe memory +allocation function. +\begin{lstlisting} +#include +T * new( type T ) { return ( T * )malloc( sizeof( T) ); }; +@\ldots@ +int * ip = new( int ); +\end{lstlisting} +This looks sensible, but \CFA's declaration-before-use rules mean that ``\lstinline$T$'' in the +function body refers to the parameter, but the ``\lstinline$T$'' in the return type refers to the +meaning of \lstinline$T$ in the scope that contains \lstinline$new$; it could be undefined, or a +type name, or a function or variable name. Nothing good can result from such a situation. +\end{rationale} + +\examples +Since type declarations create new types, instances of types are always passed by value. +\begin{lstlisting} +type A1 = int[2]; +void f1( A1 a ) { a[0] = 0; }; +typedef int A2[2]; +void f2( A2 a ) { a[0] = 0; }; +A1 v1; +A2 v2; +f1( v1 ); +f2( v2 ); +\end{lstlisting} +\lstinline$V1$ is passed by value, so \lstinline$f1()$'s assignment to \lstinline$a[0]$ does not +modify v1. \lstinline$V2$ is converted to a pointer, so \lstinline$f2()$ modifies +\lstinline$v2[0]$. + +A translation unit containing the declarations +\begin{lstlisting} +extern type Complex;@\use{Complex}@ // opaque type declaration. +extern float abs( Complex );@\use{abs}@ +\end{lstlisting} +can contain declarations of complex numbers, which can be passed to \lstinline$abs$. Some other +translation unit must implement \lstinline$Complex$ and \lstinline$abs$. That unit might contain +the declarations +\begin{lstlisting} +type Complex = struct { float re, im; };@\impl{Complex}@ +Complex cplx_i = { 0.0, 1.0 };@\impl{cplx_i}@ +float abs( Complex c ) {@\impl{abs( Complex )}@ + return sqrt( c.re * c.re + c.im * c.im ); +} +\end{lstlisting} +Note that \lstinline$c$ is implicitly converted to a \lstinline$struct$ so that its components can +be retrieved. + +\begin{lstlisting} +type Time_of_day = int;@\impl{Time_of_day}@ // seconds since midnight. +Time_of_day ?+?( Time_of_day t1, int seconds ) {@\impl{?+?}@ + return (( int)t1 + seconds ) % 86400; +} +\end{lstlisting} +\lstinline$t1$ must be cast to its implementation type to prevent infinite recursion. + +\begin{rationale} +Within the scope of a type definition, an instance of the type can be viewed as having that type or +as having the implementation type. In the \lstinline$Time_of_day$ example, the difference is +important. Different languages have treated the distinction between the abstraction and the +implementation in different ways. +\begin{itemize} +\item +Inside a Clu cluster \cite{clu}, the declaration of an instance states which view applies. Two +primitives called \lstinline$up$ and \lstinline$down$ can be used to convert between the views. +\item +The Simula class \cite{Simula87} is essentially a record type. Since the only operations on a +record are member selection and assignment, which can not be overloaded, there is never any +ambiguity as to whether the abstraction or the implementation view is being used. In {\CC} +\cite{c++}, operations on class instances include assignment and ``\lstinline$&$'', which can be +overloaded. A ``scope resolution'' operator can be used inside the class to specify whether the +abstract or implementation version of the operation should be used. +\item +An Ada derived type definition \cite{ada} creates a new type from an old type, and also implicitly +declares derived subprograms that correspond to the existing subprograms that use the old type as a +parameter type or result type. The derived subprograms are clones of the existing subprograms with +the old type replaced by the derived type. Literals and aggregates of the old type are also cloned. +In other words, the abstract view provides exactly the same operations as the implementation view. +This allows the abstract view to be used in all cases. + +The derived subprograms can be replaced by programmer-specified subprograms. This is an exception +to the normal scope rules, which forbid duplicate definitions of a subprogram in a scope. In this +case, explicit conversions between the derived type and the old type can be used. +\end{itemize} +\CFA's rules are like Clu's, except that implicit conversions and +conversion costs allow it to do away with most uses of \lstinline$up$ and \lstinline$down$. +\end{rationale} + + +\subsubsection{Default functions and objects} + +A declaration\index{type declaration} of a type identifier \lstinline$T$ with type-class +\lstinline$type$ implicitly declares a \define{default assignment} function +\lstinline$T ?=?( T *, T )$\use{?=?}, with the same scope\index{scopes} and linkage\index{linkage} as +the identifier \lstinline$T$. +\begin{rationale} +Assignment is central to C's imperative programming style, and every existing C object type has +assignment defined for it ( except for array types, which are treated as pointer types for purposes +of assignment). Without this rule, nearly every inferred type parameter would need an accompanying +assignment assertion parameter. If a type parameter should not have an assignment operation, +\lstinline$dtype$ should be used. If a type should not have assignment defined, the user can define +an assignment function that causes a run-time error, or provide an external declaration but no +definition and thus cause a link-time error. +\end{rationale} + +A definition\index{type definition} of a type identifier \lstinline$T$ with implementation +type\index{implementation type} \lstinline$I$ and type-class \lstinline$type$ implicitly defines a +default assignment function. A definition\index{type definition} of a type identifier \lstinline$T$ +with implementation type \lstinline$I$ and an assertion list implicitly defines \define{default + functions} and \define{default objects} as declared by the assertion declarations. The default +objects and functions have the same scope\index{scopes} and linkage\index{linkage} as the identifier +\lstinline$T$. Their values are determined as follows: +\begin{itemize} +\item +If at the definition of \lstinline$T$ there is visible a declaration of an object with the same name +as the default object, and if the type of that object with all occurrence of \lstinline$I$ replaced +by \lstinline$T$ is compatible with the type of the default object, then the default object is +initialized with that object. Otherwise the scope of the declaration of \lstinline$T$ must contain +a definition of the default object. + +\item +If at the definition of \lstinline$T$ there is visible a declaration of a function with the same +name as the default function, and if the type of that function with all occurrence of \lstinline$I$ +replaced by \lstinline$T$ is compatible with the type of the default function, then the default +function calls that function after converting its arguments and returns the converted result. + +Otherwise, if \lstinline$I$ contains exactly one anonymous member\index{anonymous member} such that +at the definition of \lstinline$T$ there is visible a declaration of a function with the same name +as the default function, and the type of that function with all occurrences of the anonymous +member's type in its parameter list replaced by \lstinline$T$ is compatible with the type of the +default function, then the default function calls that function after converting its arguments and +returns the result. + +Otherwise the scope of the declaration of \lstinline$T$ must contain a definition of the default +function. +\end{itemize} +\begin{rationale} +Note that a pointer to a default function will not compare as equal to a pointer to the inherited +function. +\end{rationale} + +A function or object with the same type and name as a default function or object that is declared +within the scope of the definition of \lstinline$T$ replaces the default function or object. + +\examples +\begin{lstlisting} +context s( type T ) { + T a, b; +} +struct impl { int left, right; } a = { 0, 0 }; +type Pair | s( Pair ) = struct impl; +Pair b = { 1, 1 }; +\end{lstlisting} +The definition of \lstinline$Pair$ implicitly defines two objects \lstinline$a$ and \lstinline$b$. +\lstinline$Pair a$ inherits its value from the \lstinline$struct impl a$. The definition of +\lstinline$Pair b$ is compulsory because there is no \lstinline$struct impl b$ to construct a value +from. +\begin{lstlisting} +context ss( type T ) { + T clone( T ); + void munge( T * ); +} +type Whatsit | ss( Whatsit );@\use{Whatsit}@ +type Doodad | ss( Doodad ) = struct doodad {@\use{Doodad}@ + Whatsit; // anonymous member + int extra; +}; +Doodad clone( Doodad ) { ... } +\end{lstlisting} +The definition of \lstinline$Doodad$ implicitly defines three functions: +\begin{lstlisting} +Doodad ?=?( Doodad *, Doodad ); +Doodad clone( Doodad ); +void munge( Doodad * ); +\end{lstlisting} +The assignment function inherits \lstinline$struct doodad$'s assignment function because the types +match when \lstinline$struct doodad$ is replaced by \lstinline$Doodad$ throughout. +\lstinline$munge()$ inherits \lstinline$Whatsit$'s \lstinline$munge()$ because the types match when +\lstinline$Whatsit$ is replaced by \lstinline$Doodad$ in the parameter list. \lstinline$clone()$ +does \emph{not} inherit \lstinline$Whatsit$'s \lstinline$clone()$: replacement in the parameter +list yields ``\lstinline$Whatsit clone( Doodad )$'', which is not compatible with +\lstinline$Doodad$'s \lstinline$clone()$'s type. Hence the definition of +``\lstinline$Doodad clone( Doodad )$'' is necessary. + +Default functions and objects are subject to the normal scope rules. +\begin{lstlisting} +type T = @\ldots@; +T a_T = @\ldots@; // Default assignment used. +T ?=?( T *, T ); +T a_T = @\ldots@; // Programmer-defined assignment called. +\end{lstlisting} +\begin{rationale} +A compiler warning would be helpful in this situation. +\end{rationale} + +\begin{rationale} +The \emph{class} construct of object-oriented programming languages performs three independent +functions. It \emph{encapsulates} a data structure; it defines a \emph{subtype} relationship, whereby +instances of one class may be used in contexts that require instances of another; and it allows one +class to \emph{inherit} the implementation of another. + +In \CFA, encapsulation is provided by opaque types and the scope rules, and subtyping is provided +by specifications and assertions. Inheritance is provided by default functions and objects. +\end{rationale} + + +\section{Statements and blocks} +Many statements contain expressions, which may have more than one interpretation. The following +sections describe how the \CFA translator selects an interpretation. In all cases the result of +the selection shall be a single unambiguous interpretation\index{interpretations}. + + +\setcounter{subsection}{2} +\subsection{Expression and null statements} + +The expression in an expression statement is treated as being cast to \lstinline$void$. + + +\subsection{Selection statements} + +The controlling expression \lstinline$E$ in the switch statement +\begin{lstlisting} +switch ( E ) ... +\end{lstlisting} +may have more than one interpretation, but it shall have only one interpretation with an integral +type. An integer promotion\index{integer promotion} is performed on the expression if necessary. +The constant expressions in \lstinline$case$ statements with the switch are converted to the +promoted type. + + +\subsection{Iteration statements} + +The controlling expression \lstinline$E$ in the loops +\begin{lstlisting} +if ( E ) ... +while ( E ) ... +do ... while ( E ); +\end{lstlisting} +is treated as ``\lstinline$( int )((E)!=0)$''. + +The statement +\begin{lstlisting} +for ( a; b; c ) @\ldots@ +\end{lstlisting} +is treated as +\begin{lstlisting} +for ( ( void )( a ); ( int )(( b )!=0); ( void )( c ) ) @\ldots@ +\end{lstlisting} + + +\subsection{Jump statements} + +An expression in a \lstinline$return$ statement is treated as being +cast to the result type of the function. + + +\setcounter{section}{9} +\section{Preprocessing directives} + + +\setcounter{subsection}{7} +\subsection{Predefined macro names} + +The implementation shall define the macro names \lstinline$__LINE__$, \lstinline$__FILE__$, +\lstinline$__DATE__$, and \lstinline$__TIME__$, as in the {\c11} standard. It shall not define the +macro name \lstinline$__STDC__$. + +In addition, the implementation shall define the macro name \lstinline$__CFORALL__$ to be the +decimal constant 1. + + +\appendix + +\chapter{Examples} + +\section{C types} +This section gives example specifications for some groups of types that are important in the C +language, in terms of the predefined operations that can be applied to those types. + + +\subsection{Scalar, arithmetic, and integral types} + +The pointer, integral, and floating-point types are all \define{scalar types}. All of these types +can be logically negated and compared. The assertion ``\lstinline$scalar( Complex )$'' should be read +as ``type \lstinline$Complex$ is scalar''. +\begin{lstlisting} +context scalar( type T ) {@\impl{scalar}@ + int !?( T ); + int ?=?( T, T ), ?>?( T, T ), ?!=?( T, T ); +}; +\end{lstlisting} + +The integral and floating-point types are \define{arithmetic types}, which support the basic +arithmetic operators. The use of an assertion in the \nonterm{spec-parameter-list} declares that, +in order to be arithmetic, a type must also be scalar ( and hence that scalar operations are +available ). This is equivalent to inheritance of specifications. +\begin{lstlisting} +context arithmetic( type T | scalar( T ) ) {@\impl{arithmetic}@@\use{scalar}@ + T +?( T ), -?( T ); + T ?*?( T, T ), ?/?( T, T ), ?+?( T, T ), ?-?( T, T ); +}; +\end{lstlisting} + +The various flavors of \lstinline$char$ and \lstinline$int$ and the enumerated types make up the +\define{integral types}. +\begin{lstlisting} +context integral( type T | arithmetic( T ) ) {@\impl{integral}@@\use{arithmetic}@ + T ~?( T ); + T ?&?( T, T ), ?|?( T, T ), ?^?( T, T ); + T ?%?( T, T ); + T ?<>?( T, T ); +}; +\end{lstlisting} + + +\subsection{Modifiable types} +\index{modifiable lvalue} + +The only operation that can be applied to all modifiable lvalues is simple assignment. +\begin{lstlisting} +context m_lvalue( type T ) {@\impl{m_lvalue}@ + T ?=?( T *, T ); +}; +\end{lstlisting} + +Modifiable scalar lvalues are scalars and are modifiable lvalues, and assertions in the +\nonterm{spec-parameter-list} reflect those relationships. This is equivalent to multiple +inheritance of specifications. Scalars can also be incremented and decremented. +\begin{lstlisting} +context m_l_scalar( type T | scalar( T ) | m_lvalue( T ) ) {@\impl{m_l_scalar}@ + T ?++( T * ), ?--( T * );@\use{scalar}@@\use{m_lvalue}@ + T ++?( T * ), --?( T * ); +}; +\end{lstlisting} + +Modifiable arithmetic lvalues are both modifiable scalar lvalues and arithmetic. Note that this +results in the ``inheritance'' of \lstinline$scalar$ along both paths. +\begin{lstlisting} +context m_l_arithmetic( type T | m_l_scalar( T ) | arithmetic( T ) ) {@\impl{m_l_arithmetic}@ + T ?/=?( T *, T ), ?*=?( T *, T );@\use{m_l_scalar}@@\use{arithmetic}@ + T ?+=?( T *, T ), ?-=?( T *, T ); +}; + +context m_l_integral( type T | m_l_arithmetic( T ) | integral( T ) ) {@\impl{m_l_integral}@ + T ?&=?( T *, T ), ?|=?( T *, T ), ?^=?( T *, T );@\use{m_l_arithmetic}@ + T ?%=?( T *, T ), ?<<=?( T *, T ), ?>>=?( T *, T );@\use{integral}@ +}; +\end{lstlisting} + + +\subsection{Pointer and array types} + +Array types can barely be said to exist in {\c11}, since in most cases an array name is treated as a +constant pointer to the first element of the array, and the subscript expression +``\lstinline$a[i]$'' is equivalent to the dereferencing expression ``\lstinline$(*( a+( i )))$''. +Technically, pointer arithmetic and pointer comparisons other than ``\lstinline$==$'' and +``\lstinline$!=$'' are only defined for pointers to array elements, but the type system does not +enforce those restrictions. Consequently, there is no need for a separate ``array type'' +specification. + +Pointer types are scalar types. Like other scalar types, they have ``\lstinline$+$'' and +``\lstinline$-$'' operators, but the types do not match the types of the operations in +\lstinline$arithmetic$, so these operators cannot be consolidated in \lstinline$scalar$. +\begin{lstlisting} +context pointer( type P | scalar( P ) ) {@\impl{pointer}@@\use{scalar}@ + P ?+?( P, long int ), ?+?( long int, P ), ?-?( P, long int ); + ptrdiff_t ?-?( P, P ); +}; + +context m_l_pointer( type P | pointer( P ) | m_l_scalar( P ) ) {@\impl{m_l_pointer}@ + P ?+=?( P *, long int ), ?-=?( P *, long int ); + P ?=?( P *, void * ); + void * ?=?( void **, P ); +}; +\end{lstlisting} + +Specifications that define the dereference operator ( or subscript operator ) require two parameters, +one for the pointer type and one for the pointed-at ( or element ) type. Different specifications are +needed for each set of type qualifiers\index{type qualifiers}, because qualifiers are not included +in types. The assertion ``\lstinline$|ptr_to( Safe_pointer, int )$'' should be read as +``\lstinline$Safe_pointer$ acts like a pointer to \lstinline$int$''. +\begin{lstlisting} +context ptr_to( type P | pointer( P ), type T ) {@\impl{ptr_to}@@\use{pointer}@ + lvalue T *?( P ); lvalue T ?[?]( P, long int ); +}; + +context ptr_to_const( type P | pointer( P ), type T ) {@\impl{ptr_to_const}@ + const lvalue T *?( P ); const lvalue T ?[?]( P, long int );@\use{pointer}@ +}; + +context ptr_to_volatile( type P | pointer( P ), type T ) }@\impl{ptr_to_volatile}@ + volatile lvalue T *?( P ); volatile lvalue T ?[?]( P, long int );@\use{pointer}@ +}; +\end{lstlisting} +\begin{lstlisting} +context ptr_to_const_volatile( type P | pointer( P ), type T ) }@\impl{ptr_to_const_volatile}@ + const volatile lvalue T *?( P );@\use{pointer}@ + const volatile lvalue T ?[?]( P, long int ); +}; +\end{lstlisting} + +Assignment to pointers is more complicated than is the case with other types, because the target's +type can have extra type qualifiers in the pointed-at type: a ``\lstinline$T *$'' can be assigned to +a ``\lstinline$const T *$'', a ``\lstinline$volatile T *$'', and a ``\lstinline$const volatile T *$''. +Again, the pointed-at type is passed in, so that assertions can connect these specifications to the +``\lstinline$ptr_to$'' specifications. +\begin{lstlisting} +context m_l_ptr_to( type P | m_l_pointer( P ),@\use{m_l_pointer}@@\impl{m_l_ptr_to}@ type T | ptr_to( P, T )@\use{ptr_to}@ { + P ?=?( P *, T * ); + T * ?=?( T **, P ); +}; + +context m_l_ptr_to_const( type P | m_l_pointer( P ),@\use{m_l_pointer}@@\impl{m_l_ptr_to_const}@ type T | ptr_to_const( P, T )@\use{ptr_to_const}@) { + P ?=?( P *, const T * ); + const T * ?=?( const T **, P ); +}; + +context m_l_ptr_to_volatile( type P | m_l_pointer( P ),@\use{m_l_pointer}@@\impl{m_l_ptr_to_volatile}@ type T | ptr_to_volatile( P, T )) {@\use{ptr_to_volatile}@ + P ?=?( P *, volatile T * ); + volatile T * ?=?( volatile T **, P ); +}; + +context m_l_ptr_to_const_volatile( type P | ptr_to_const_volatile( P ),@\use{ptr_to_const_volatile}@@\impl{m_l_ptr_to_const_volatile}@ + type T | m_l_ptr_to_volatile( P, T ) | m_l_ptr_to_const( P )) {@\use{m_l_ptr_to_const}@@\use{m_l_ptr_to_volatile}@ + P ?=?( P *, const volatile T * ); + const volatile T * ?=?( const volatile T **, P ); +}; +\end{lstlisting} + +Note the regular manner in which type qualifiers appear in those specifications. An alternative +specification can make use of the fact that qualification of the pointed-at type is part of a +pointer type to capture that regularity. +\begin{lstlisting} +context m_l_ptr_like( type MyP | m_l_pointer( MyP ),@\use{m_l_pointer}@@\impl{m_l_ptr_like}@ type CP | m_l_pointer( CP ) ) { + MyP ?=?( MyP *, CP ); + CP ?=?( CP *, MyP ); +}; +\end{lstlisting} +The assertion ``\lstinline$| m_l_ptr_like( Safe_ptr, const int * )$'' should be read as +``\lstinline$Safe_ptr$ is a pointer type like \lstinline$const int *$''. This specification has two +defects, compared to the original four: there is no automatic assertion that dereferencing a +\lstinline$MyP$ produces an lvalue of the type that \lstinline$CP$ points at, and the +``\lstinline$|m_l_pointer( CP )$'' assertion provides only a weak assurance that the argument passed +to \lstinline$CP$ really is a pointer type. + + +\section{Relationships between operations} + +Different operators often have related meanings; for instance, in C, ``\lstinline$+$'', +``\lstinline$+=$'', and the two versions of ``\lstinline$++$'' perform variations of addition. +Languages like {\CC} and Ada allow programmers to define operators for new types, but do not +require that these relationships be preserved, or even that all of the operators be implemented. +Completeness and consistency is left to the good taste and discretion of the programmer. It is +possible to encourage these attributes by providing generic operator functions, or member functions +of abstract classes, that are defined in terms of other, related operators. + +In \CFA, polymorphic functions provide the equivalent of these generic operators, and +specifications explicitly define the minimal implementation that a programmer should provide. This +section shows a few examples. + + +\subsection{Relational and equality operators} + +The different comparison operators have obvious relationships, but there is no obvious subset of the +operations to use in the implementation of the others. However, it is usually convenient to +implement a single comparison function that returns a negative integer, 0, or a positive integer if +its first argument is respectively less than, equal to, or greater than its second argument; the +library function \lstinline$strcmp$ is an example. + +C and \CFA have an extra, non-obvious comparison operator: ``\lstinline$!$'', logical negation, +returns 1 if its operand compares equal to 0, and 0 otherwise. +\begin{lstlisting} +context comparable( type T ) { + const T 0; + int compare( T, T ); +} + +forall( type T | comparable( T ) ) int ?=, >, and !=. + +forall( type T | comparable( T ) ) int !?( T operand ) { + return !compare( operand, 0 ); +} +\end{lstlisting} + + +\subsection{Arithmetic and integer operations} + +A complete arithmetic type would provide the arithmetic operators and the corresponding assignment +operators. Of these, the assignment operators are more likely to be implemented directly, because +it is usually more efficient to alter the contents of an existing object than to create and return a +new one. Similarly, a complete integral type would provide integral operations based on integral +assignment operations. +\begin{lstlisting} +context arith_base( type T ) { + const T 1; + T ?+=?( T *, T ), ?-=?( T *, T ), ?*=?( T *, T ), ?/=?( T *, T ); +} + +forall( type T | arith_base( T ) ) T ?+?( T l, T r ) { + return l += r; +} + +forall( type T | arith_base( T ) ) T ?++( T * operand ) { + T temporary = *operand; + *operand += 1; + return temporary; +} + +forall( type T | arith_base( T ) ) T ++?( T * operand ) { + return *operand += 1; +} +// ... similarly for -, --, *, and /. + +context int_base( type T ) { + T ?&=?( T *, T ), ?|=?( T *, T ), ?^=?( T *, T ); + T ?%=?( T *, T ), ?<<=?( T *, T ), ?>>=?( T *, T ); +} + +forall( type T | int_base( T ) ) T ?&?( T l, T r ) { + return l &= r; +} +// ... similarly for |, ^, %, <<, and >>. +\end{lstlisting} + +Note that, although an arithmetic type would certainly provide comparison functions, and an integral +type would provide arithmetic operations, there does not have to be any relationship among +\lstinline$int_base$, \lstinline$arith_base$ and \lstinline$comparable$. Note also that these +declarations provide guidance and assistance, but they do not define an absolutely minimal set of +requirements. A truly minimal implementation of an arithmetic type might only provide +\lstinline$0$, \lstinline$1$, and \lstinline$?-=?$, which would be used by polymorphic +\lstinline$?+=?$, \lstinline$?*=?$, and \lstinline$?/=?$ functions. + +Note also that \lstinline$short$ is an integer type in C11 terms, but has no operations! + + +\chapter{TODO} +Review index entries. + +Restrict allowed to qualify anything, or type/dtype parameters, but only affects pointers. This gets +into \lstinline$noalias$ territory. Qualifying anything (``\lstinline$short restrict rs$'') means +pointer parameters of \lstinline$?++$, etc, would need restrict qualifiers. + +Enumerated types. Constants are not ints. Overloading. Definition should be ``representable as an +integer type'', not ``as an int''. C11 usual conversions freely convert to and from ordinary +integer types via assignment, which works between any integer types. Does enum Color ?*?( enum +Color, enum Color ) really make sense? ?++ does, but it adds (int)1. + +Operators on {,signed,unsigned} char and other small types. ?