Index: doc/man/README =================================================================== --- doc/man/README (revision adcdd2ffceadd5c6f09a325cc6644532ea21eea9) +++ doc/man/README (revision adcdd2ffceadd5c6f09a325cc6644532ea21eea9) @@ -0,0 +1,5 @@ +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: doc/man/cfa.1 =================================================================== --- doc/man/cfa.1 (revision adcdd2ffceadd5c6f09a325cc6644532ea21eea9) +++ doc/man/cfa.1 (revision adcdd2ffceadd5c6f09a325cc6644532ea21eea9) @@ -0,0 +1,186 @@ +.\" -*- 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 50eac1b9aebf9a91794280deee4d312e282b4891) +++ (revision ) @@ -1,73 +1,0 @@ -## Define the appropriate configuration variables. - -TeXLIB = .:: -LaTeX = TEXINPUTS=${TeXLIB} && export TEXINPUTS && latex -BibTeX = BSTINPUTS=${TeXLIB} && export BSTINPUTS && bibtex - -## Define the text source files. - -SOURCES = ${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 *.cf \ - ${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} ${SOURCES} ${basename ${DOCUMENT}}.tex ${basename ${DOCUMENT}}.bib - # Conditionally create an empty *.ind (index) file for inclusion until makeindex is run. - if [ ! -r ${basename $@}.ind ] ; then touch ${basename $@}.ind ; fi - # Must have *.aux file containing citations for bibtex - if [ ! -r ${basename $@}.aux ] ; then ${LaTeX} ${basename $@}.tex ; fi - -${BibTeX} ${basename $@} - # Some citations reference others so run steps again to resolve these citations - ${LaTeX} ${basename $@}.tex - -${BibTeX} ${basename $@} - # Make index from *.aux entries and input index at end of document - makeindex -s indexstyle ${basename $@}.idx - ${LaTeX} ${basename $@}.tex - # Run again to get index title into table of contents - ${LaTeX} ${basename $@}.tex - -predefined : - sed -f predefined.sed ${basename ${DOCUMENT}}.tex > ${basename $@}.cf - -## 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 50eac1b9aebf9a91794280deee4d312e282b4891) +++ (revision ) @@ -1,2 +1,0 @@ -preamble "" -postamble "" Index: doc/refrat/predefined.sed =================================================================== --- doc/refrat/predefined.sed (revision 50eac1b9aebf9a91794280deee4d312e282b4891) +++ (revision ) @@ -1,5 +1,0 @@ -/^\\predefined/,/^\\end{lstlisting}/ !d -/^\\begin{lstlisting}/,/^\\end{lstlisting}/ s/@\\use{.*}@//g -/^\\predefined/ d -/^\\begin{lstlisting}/ d -/^\\end{lstlisting}/ d Index: doc/refrat/refrat.bib =================================================================== --- doc/refrat/refrat.bib (revision 50eac1b9aebf9a91794280deee4d312e282b4891) +++ (revision ) @@ -1,119 +1,0 @@ -@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 50eac1b9aebf9a91794280deee4d312e282b4891) +++ doc/refrat/refrat.tex (revision adcdd2ffceadd5c6f09a325cc6644532ea21eea9) @@ -1,4736 +1,0 @@ -% requires tex packages: texlive-base texlive-latex-base tex-common texlive-humanities texlive-latex-extra texlive-fonts-recommended - -\documentclass[openright,twoside]{report} -%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% - -% Latex packages used in the document. - -\usepackage{fullpage,times} -\usepackage{xspace} -\usepackage{varioref} -\usepackage{listings} -\usepackage{comment} -\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} - -%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% - -% Names used in the document. - -\newcommand{\CFA}{Cforall\xspace} % set language text name -\newcommand{\CFAA}{C$\forall$\xspace} % set language symbolic name -\newcommand{\CC}{C\kern-.1em\hbox{+\kern-.25em+}\xspace} % CC symbolic name -\def\c11{ISO/IEC C} % C11 name (cannot have numbers in latex command name) - -%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% - -% Bespoke macros used in the document. - -\makeatletter -% index macros -\newcommand{\italic}[1]{\emph{\hyperpage{#1}}} -\newcommand{\definition}[1]{\textbf{\hyperpage{#1}}} -\newcommand{\see}[1]{\emph{see} #1} - -% Define some commands that produce formatted index entries suitable for cross-references. -% ``\spec'' produces entries for specifications of entities. ``\impl'' produces entries for their -% implementations, and ``\use'' for their uses. - -% \newcommand{\bold}[1]{{\bf #1}} -% \def\spec{\@bsphack\begingroup -% \def\protect##1{\string##1\space}\@sanitize -% \@wrxref{|bold}} -\def\impl{\@bsphack\begingroup - \def\protect##1{\string##1\space}\@sanitize - \@wrxref{|definition}} -\newcommand{\indexcode}[1]{{\lstinline$#1$}} -\def\use{\@bsphack\begingroup - \def\protect##1{\string##1\space}\@sanitize - \@wrxref{|hyperpage}} -\def\@wrxref#1#2{\let\thepage\relax - \xdef\@gtempa{\write\@indexfile{\string - \indexentry{#2@{\lstinline$#2$}#1}{\thepage}}}\endgroup\@gtempa - \if@nobreak \ifvmode\nobreak\fi\fi\@esphack} -%\newcommand{\use}[1]{\index{#1@{\lstinline$#1$}}} -%\newcommand{\impl}[1]{\index{\protect#1@{\lstinline$\protect#1$}|definition}} - -% text inline and lowercase index: \Index{Inline and index text} -% text inline and as-in index: \Index{Inline and Index text} -% text inline but index with different as-is text: \Index[index text]{inline text} -\newcommand{\Index}{\@ifstar\@sIndex\@Index} -\newcommand{\@Index}[2][\@empty]{\lowercase{\def\temp{#2}}#2\ifx#1\@empty\index{\temp}\else\index{#1@{\protect#2}}\fi} -\newcommand{\@sIndex}[2][\@empty]{#2\ifx#1\@empty\index{#2}\else\index{#1@{\protect#2}}\fi} -\makeatother - -% blocks and titles -\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}~\par\noindent} -\newcommand{\examples}{\paragraph{Examples}~\par\noindent} -\newcommand{\semantics}{\paragraph{Semantics}~\par\noindent} -\newcommand{\constraints}{\paragraph{Constraints}~\par\noindent} -\newcommand{\predefined}{\paragraph{Predefined Identifiers}~\par\noindent} - -% BNF macros -\def\syntax{\paragraph{Syntax}\trivlist\parindent=.5in\item[\hskip.5in]} -\let\endsyntax=\endtrivlist -\newcommand{\lhs}[1]{\par{\emph{#1:}}\index{#1@{\emph{#1}}|italic}} -\newcommand{\rhs}{\hfil\break\hbox{\hskip1in}} -\newcommand{\oldlhs}[1]{\emph{#1: \ldots}\index{#1@{\emph{#1}}|italic}} -\newcommand{\nonterm}[1]{\emph{#1\/}\index{#1@{\emph{#1}}|italic}} -\newcommand{\opt}{$_{opt}$\ } - -% adjust varioref package with default "section" and "page" titles, and optional title with faraway page numbers -% \VRef{label} => Section 2.7, \VPageref{label} => page 17 -% \VRef[Figure]{label} => Figure 3.4, \VPageref{label} => page 17 -\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}} - -% adjust listings macros -\lstdefinelanguage{CFA}[ANSI]{C}% -{morekeywords={asm,_Alignas,_Alignof,_At,_Atomic,_Bool,catch,catchResume,choose,_Complex,context,disable,dtype,enable, - fallthru,finally,forall,ftype,_Generic,_Imaginary,inline,lvalue,_Noreturn,restrict,_Static_assert, - _Thread_local,throw,throwResume,try,type,}, -}% - -\lstset{ -language=CFA, -columns=fullflexible, -basicstyle=\sf\small, -tabsize=4, -xleftmargin=\parindent, -escapechar=@, -%fancyvrb=true, -%showtabs=true, -keepspaces=true, -showtabs=true, -tab=, -}% - -\makeatletter -% replace/adjust listings characters that look bad in sanserif -\lst@CCPutMacro -\lst@ProcessOther{"2D}{\lst@ttfamily{-{}}{{\ttfamily\upshape -}}} % replace minus -\lst@ProcessOther{"3C}{\lst@ttfamily{<}{\texttt{<}}} % replace less than -\lst@ProcessOther{"3E}{\lst@ttfamily{<}{\texttt{>}}} % replace greater than -\lst@ProcessOther{"5E}{\raisebox{0.4ex}{$\scriptstyle\land\,$}} % replace circumflex -\lst@ProcessLetter{"5F}{\lst@ttfamily{\char95}{{\makebox[1.2ex][c]{\rule{1ex}{0.1ex}}}}} % replace underscore -\lst@ProcessOther{"7E}{\raisebox{0.3ex}{$\scriptstyle\sim\,$}} % replace tilde -%\lst@ProcessOther{"7E}{\raisebox{-.4ex}[1ex][0pt]{\textasciitilde}} % lower tilde -\@empty\z@\@empty -\makeatother - -\setcounter{secnumdepth}{3} % number subsubsections -\setcounter{tocdepth}{3} % subsubsections in table of contents -\makeindex - -%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% - -\begin{document} -\pagestyle{headings} -\linenumbers % comment out to turn off line numbering - -\title{\CFA (\CFAA) Reference Manual and Rationale} -\author{Glen Ditchfield \and Peter A. Buhr} -\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 the manual contains more ``forward references'' than usual, -making it harder to follow if the reader does not have a copy of the {\c11} standard. For a simple -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 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 -\Index{name space}, instead of hiding them. The outer declaration is hidden if the two declarations -have \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 -\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 \Index{external linkage} denote the same object or function if they have -\Index{compatible type}s, 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 \Index{internal linkage} denotes the same object or function in the same circumstances. -Identifiers with \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} - - -\setcounter{subsection}{8} -\subsection{Generic Types} - - -\subsubsection{Semantics} - -\CFA provides a capability for generic types; using this capability a single "generic type -generator" can be written that can represent multiple concrete type instantiations by substitution -of the "type parameters" of the generic type for concrete types. Syntactically a generic type -generator is represented by putting a forall specifier on a struct or union declaration, as defined -in \VRef{forall}. An instantiation of the generic type is written by specifying the type parameters -in parentheses after the name of the generic type generator: -\begin{lstlisting} -forall( type T | sumable( T ) ) struct pair { - T x; - T y; -}; -pair( int ) p = { 3, 14 }; -\end{lstlisting} - -The type parameters in an instantiation of a generic type must satisfy any constraints in the forall -specifier on the type generator declaration, e.g., \lstinline$sumable$. The instantiation then has -the semantics that would result if the type parameters were substituted into the type generator -declaration by macro substitution. - -Polymorphic functions may have generic types as parameters, and those generic types may use type -parameters of the polymorphic function as type parameters of the generic type: -\begin{lstlisting} -forall( type T ) void swap( pair(T) *p ) { - T z = p->x; - p->x = p->y; - p->y = z; -} -\end{lstlisting} - - -\subsubsection{Constraints} - -To avoid unduly constraining implementors, the generic type generator definition must be visible at -any point where it is instantiated. Forward declarations of generic type generators are not -forbidden, but the definition must be visible to instantiate the generic type. Equivalently, -instantiations of generic types are not allowed to be incomplete types. - -\examples -\begin{lstlisting} -forall( type T ) struct A; - -forall( type T ) struct B { - A(T) *a; // legal, but cannot instantiate B(T) -}; - -B(T) x; // illegal, *x.a is of an incomplete generic type - -forall( type T ) struct A { - B( T ) *b; -}; - -B( T ) y; // legal, *x.a is now of a complete generic type - - -// box.h: - forall( type T ) struct box; - forall( type T ) box( T ) *make_box( T ); - forall( type T ) void use_box( box( T ) *b ); - -// main.c: - box( int ) *b = make_box( 42 ); // illegal, def'n of box not visible - use_box( b ); // illegal -\end{lstlisting} - - -\section{Conversions} -\CFA defines situations where values of one type are automatically converted to another type. -These conversions are called \define{implicit conversion}s. The programmer can request -\define{explicit conversion}s using cast expressions. - - -\subsection{Arithmetic operands} - - -\setcounter{subsubsection}{8} -\subsubsection{Safe arithmetic conversions} - -In C, a pattern of conversions known as the \define{usual arithmetic conversion}s 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 conversion}s. - -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 \Index{integer promotion}s. - -\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 \Index{real type}s to \Index{complex type}s 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 -\Index{anonymous structure} or an \Index{anonymous union}, it can be implicitly -converted\index{implicit conversion} 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 -\Index{less polymorphic} by binding values to one or more of its \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 \Index{assertion parameter} 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 \Index{anonymous structure} or an \Index{anonymous union}; -\item -within the scope of an initialized \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 conversion}s. -\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 conversion} -conversion\footnote{Unsafe\index{unsafe conversion} 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 \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 detects a syntax error because it treats ``\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{interpretation}s, each of which has a different type. The interpretations that are -potentially executable are called \define{valid interpretation}s. 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 conversion} 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 \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 \Index{null pointer} -\lstinline$0$\use{0}). 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 \Index{internal linkage} and are implicitly declared with \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} - -\predefined -\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 \Index{valid interpretation} 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} - -\predefined -\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 \Index{monomorphic function} -designators, the combination has a \Index{valid interpretation} 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 \Index{default argument promotion} 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 -\Index{polymorphic function} designator and the function designator accepts the number of arguments -given, there shall be at least one set of \define{implicit argument}s for the implicit parameters -such that -\begin{itemize} -\item -If the declaration of the implicit parameter uses \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 conversion} 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 \Index{assertion parameter} 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 \Index{composite type} of the types of the valid interpretations, and the value of the -interpretation is that of the \Index{best valid interpretation}. -\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 -\Index{unsafe conversion} 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 *)$ \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 \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 \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} - -\predefined -\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$}} \index{Itorage-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} - -\predefined -\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} - -\predefined -\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 -\Index{interpretation}\index{ambiguous interpretation}, 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} - -\predefined -\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 \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 \lstinline$sizeof$ and \lstinline$_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 \Index{interpretation}\index{ambiguous interpretation}, 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 \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} - -\predefined -\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 \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 \Index{real type}s to \Index{complex type}s in the -\Index{usual arithmetic conversion}s. 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 \Index{integer promotion} to any argument that -belongs to a type that has an \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} - -\predefined -\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 \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} - -\predefined -\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 \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 \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} - -\predefined -\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 \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} - -\predefined -\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 \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 \Index{null pointer} constant 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} - -\predefined -\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 \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} - -\predefined -\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 \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} - -\predefined -\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 \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 \Index{usual arithmetic conversion}s 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} - -\predefined -\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} - -\predefined -\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 \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} - -\begin{comment} -\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} -\end{comment} - -\semantics -The \nonterm{type-parameter-list}s and assertions of the \nonterm{forall-specifier}s declare type -identifiers, function and object identifiers with \Index{no linkage}. - -If, in the declaration ``\lstinline$T D$'', \lstinline$T$ contains \nonterm{forall-specifier}s and -\lstinline$D$ 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 -\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 \Index{assertion parameter}s -of that function declarator. - -\begin{comment} -\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} -\end{comment} - -If a function declarator is part of a function definition, its inferred parameters and assertion -parameters have \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 -\Index{compatible type}s 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 \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 \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 \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 \Index{interpretation}. - - -\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 \Index{incomplete type}s 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 \Index{object type}; if it uses \lstinline$dtype$, the argument shall be the type name of -an object type or an \Index{incomplete type}; and if it uses \lstinline$ftype$, the argument shall -be the type name of a \Index{function type}. - -\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 \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 \Index{type -name} for a type incompatible with all other types. - -An identifier declared by a \nonterm{type-parameter} has \Index{no linkage}. Identifiers declared -with type-class \lstinline$type$\use{type} are \Index{object type}s; those declared with type-class -\lstinline$dtype$\use{dtype} are \Index{incomplete type}s; and those declared with type-class -\lstinline$ftype$\use{ftype} are \Index{function type}s. The identifier has \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 \Index{initializer} is a \define{type definition}. The declared -identifier is an \Index{incomplete type} within the initializer, and an \Index{object type} after -the end of the initializer. The type in the initializer is called the \define{implementation - type}. Within the scope of the declaration, \Index{implicit conversion}s 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 \Index{initializer} and without a \Index{storage-class specifier} or -with storage-class specifier \lstinline$static$\use{static} defines an \Index{incomplete type}. If a -\Index{translation unit} or \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 \Index{storage-class specifier} -\lstinline$extern$\use{extern} is an \define{opaque type declaration}. Opaque types are -\Index{object type}s. 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 -\Index{object type} 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 \Index{incomplete type} which is not a qualified version\index{qualified type} of a type is a -value of \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 -\Index{function type} 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 \Index{incomplete type}s 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 \Index{scope} and \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 \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 function}s and -\define{default object}s as declared by the assertion declarations. The default objects and -functions have the same \Index{scope} and \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} - -\begin{syntax} -\oldlhs{statement} -\rhs \nonterm{exception-statement} -\end{syntax} - -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 \Index{interpretation}. - - -\subsection{Labeled statements} - -\begin{syntax} -\oldlhs{labeled-statement} -\rhs \lstinline$case$ \nonterm{case-value-list} : \nonterm{statement} -\lhs{case-value-list} -\rhs \nonterm{case-value} -\rhs \nonterm{case-value-list} \lstinline$,$ \nonterm{case-value} -\lhs{case-value} -\rhs \nonterm{constant-expression} -\rhs \nonterm{subrange} -\lhs{subrange} -\rhs \nonterm{constant-expression} \lstinline$~$ \nonterm{constant-expression} -\end{syntax} - -The following have identical meaning: -\begin{lstlisting} -case 1: case 2: case 3: case 4: case 5: -case 1, 2, 3, 4, 5: -case 1~5: -\end{lstlisting} -Multiple subranges are allowed: -\begin{lstlisting} -case 1~4, 9~14, 27~32: -\end{lstlisting} -The \lstinline$case$ and \lstinline$default$ clauses are restricted within the \lstinline$switch$ and \lstinline$choose$ statements, precluding Duff's device. - - -\subsection{Expression and null statements} - -The expression in an expression statement is treated as being cast to \lstinline$void$. - - -\subsection{Selection statements} - -\begin{syntax} -\oldlhs{selection-statement} -\rhs \lstinline$choose$ \lstinline$($ \nonterm{expression} \lstinline$)$ \nonterm{statement} -\end{syntax} - -The controlling expression \lstinline$E$ in the \lstinline$switch$ and \lstinline$choose$ statement: -\begin{lstlisting} -switch ( E ) ... -choose ( E ) ... -\end{lstlisting} -may have more than one interpretation, but it shall have only one interpretation with an integral type. -An \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. - - -\setcounter{subsubsection}{3} -\subsubsection{The \lstinline$choose$ statement} - -The \lstinline$choose$ statement is the same as the \lstinline$switch$ statement except control transfers to the end of the \lstinline$choose$ statement at a \lstinline$case$ or \lstinline$default$ labeled statement. -The \lstinline$fallthru$ statement is used to fall through to the next \lstinline$case$ or \lstinline$default$ labeled statement. -The following have identical meaning: -\begin{flushleft} -\begin{tabular}{@{\hspace{2em}}l@{\hspace{2em}}l@{}} -\begin{lstlisting} -switch (...) { - case 1: ... ; break; - case 2: ... ; break; - case 3: ... ; // fall through - case 4: ... ; // fall through - default: ... break; -} -\end{lstlisting} -& -\begin{lstlisting} -choose (...) { - case 1: ... ; // exit - case 2: ... ; // exit - case 3: ... ; fallthru; - case 4: ... ; fallthru; - default: ... ; // exit -} -\end{lstlisting} -\end{tabular} -\end{flushleft} -The \lstinline$choose$ statement addresses the problem of accidental fall-through associated with the \lstinline$switch$ statement. - - -\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 ) ) ... -\end{lstlisting} - - -\subsection{Jump statements} - -\begin{syntax} -\oldlhs{jump-statement} -\rhs \lstinline$continue$ \nonterm{identifier}\opt -\rhs \lstinline$break$ \nonterm{identifier}\opt -\rhs \ldots -\rhs \lstinline$throw$ \nonterm{assignment-expression}\opt -\rhs \lstinline$throwResume$ \nonterm{assignment-expression}\opt \nonterm{at-expression}\opt -\lhs{at-expression} \lstinline$_At$ \nonterm{assignment-expression} -\end{syntax} - -Labeled \lstinline$continue$ and \lstinline$break$ allow useful but restricted control-flow that reduces the need for the \lstinline$goto$ statement for exiting multiple nested control-structures. -\begin{lstlisting} -L1: { // compound - L2: switch ( ... ) { // switch - case ...: - L3: for ( ;; ) { // outer for - L4: for ( ;; ) { // inner for - continue L1; // error: not enclosing iteration - continue L2; // error: not enclosing iteration - continue L3; // next iteration of outer for - continue L4; // next iteration of inner for - break L1; // exit compound - break L2; // exit switch - break L3; // exit outer for - break L4; // exit inner for - } // for - } // for - break; // exit switch - default: - break L1; // exit compound - } // switch - ... -} // compound -\end{lstlisting} - - -\setcounter{subsubsection}{1} -\subsubsection{The \lstinline$continue$ statement} - -The identifier in a \lstinline$continue$ statement shall name a label located on an enclosing iteration statement. - - -\subsubsection{The \lstinline$break$ statement} - -The identifier in a \lstinline$break$ statement shall name a label located on an enclosing compound, selection or iteration statement. - - -\subsubsection{The \lstinline$return$ statement} - -An expression in a \lstinline$return$ statement is treated as being cast to the result type of the function. - - -\subsubsection{The \lstinline$throw$ statement} - -When an exception is raised, \Index{propagation} directs control from a raise in the source execution to a handler in the faulting execution. - - -\subsubsection{The \lstinline$throwResume$ statement} - - -\subsection{Exception statements} - -\begin{syntax} -\lhs{exception-statement} -\rhs \lstinline$try$ \nonterm{compound-statement} \nonterm{handler-list} -\rhs \lstinline$try$ \nonterm{compound-statement} \nonterm{finally-clause} -\rhs \lstinline$try$ \nonterm{compound-statement} \nonterm{handler-list} \nonterm{finally-clause} -\lhs{handler-list} -\rhs \nonterm{handler-clause} -\rhs \lstinline$catch$ \lstinline$($ \ldots \lstinline$)$ \nonterm{compound-statement} -\rhs \nonterm{handler-clause} \lstinline$catch$ \lstinline$($ \ldots \lstinline$)$ \nonterm{compound-statement} -\rhs \lstinline$catchResume$ \lstinline$($ \ldots \lstinline$)$ \nonterm{compound-statement} -\rhs \nonterm{handler-clause} \lstinline$catchResume$ \lstinline$($ \ldots \lstinline$)$ \nonterm{compound-statement} -\lhs{handler-clause} -\rhs \lstinline$catch$ \lstinline$($ \nonterm{exception-declaration} \lstinline$)$ \nonterm{compound-statement} -\rhs \nonterm{handler-clause} \lstinline$catch$ \lstinline$($ \nonterm{exception-declaration} \lstinline$)$ \nonterm{compound-statement} -\rhs \lstinline$catchResume$ \lstinline$($ \nonterm{exception-declaration} \lstinline$)$ \nonterm{compound-statement} -\rhs \nonterm{handler-clause} \lstinline$catchResume$ \lstinline$($ \nonterm{exception-declaration} \lstinline$)$ \nonterm{compound-statement} -\lhs{finally-clause} -\rhs \lstinline$finally$ \nonterm{compound-statement} -\lhs{exception-declaration} -\rhs \nonterm{type-specifier} -\rhs \nonterm{type-specifier} \nonterm{declarator} -\rhs \nonterm{type-specifier} \nonterm{abstract-declarator} -\rhs \nonterm{new-abstract-declarator-tuple} \nonterm{identifier} -\rhs \nonterm{new-abstract-declarator-tuple} -\lhs{asynchronous-statement} -\rhs \lstinline$enable$ \nonterm{identifier-list} \nonterm{compound-statement} -\rhs \lstinline$disable$ \nonterm{identifier-list} \nonterm{compound-statement} -\end{syntax} - -\Index{Exception statement}s allow a dynamic call to a handler for \Index{recovery} (\Index{termination}) or \Index{correction} (\Index{resumption}) of an \Index{abnormal event}. - - -\subsubsection{The \lstinline$try$ statement} - -The \lstinline$try$ statement is a block with associated handlers, called a \Index{guarded block}; -all other blocks are \Index{unguarded block}s. -A \lstinline$goto$, \lstinline$break$, \lstinline$return$, or \lstinline$continue$ statement can be used to transfer control out of a try block or handler, but not into one. - - -\subsubsection{The \lstinline$enable$/\lstinline$disable$ statements} - -The \lstinline$enable$/\lstinline$disable$ statements toggle delivery of \Index{asynchronous exception}s. - - -\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 \Index{type qualifier}s, 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. ?