[2fc0e5c] | 1 | % requires tex packages: texlive-base texlive-latex-base tex-common texlive-humanities texlive-latex-extra texlive-fonts-recommended
|
---|
| 2 |
|
---|
[f60d997] | 3 | \documentclass[openright,twoside]{report}
|
---|
[ce6c57c] | 4 | %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
---|
| 5 |
|
---|
| 6 | % Latex packages used in the document.
|
---|
| 7 |
|
---|
[f60d997] | 8 | \usepackage{fullpage,times}
|
---|
| 9 | \usepackage{xspace}
|
---|
| 10 | \usepackage{varioref}
|
---|
| 11 | \usepackage{listings}
|
---|
[41b3ddd] | 12 | \usepackage{comment}
|
---|
[f60d997] | 13 | \usepackage{latexsym} % \Box
|
---|
| 14 | \usepackage{mathptmx} % better math font with "times"
|
---|
| 15 | \usepackage[pagewise]{lineno}
|
---|
| 16 | \renewcommand{\linenumberfont}{\scriptsize\sffamily}
|
---|
| 17 | \usepackage[dvips,plainpages=false,pdfpagelabels,pdfpagemode=UseNone,colorlinks=true,pagebackref=true,linkcolor=blue,citecolor=blue,urlcolor=blue,pagebackref=true,breaklinks=true]{hyperref}
|
---|
| 18 | \usepackage{breakurl}
|
---|
| 19 | \urlstyle{sf}
|
---|
| 20 |
|
---|
[ce6c57c] | 21 | %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
---|
| 22 |
|
---|
| 23 | % Names used in the document.
|
---|
| 24 |
|
---|
| 25 | \newcommand{\CFA}{Cforall\xspace} % set language text name
|
---|
| 26 | \newcommand{\CFAA}{C$\forall$\xspace} % set language symbolic name
|
---|
| 27 | \newcommand{\CC}{C\kern-.1em\hbox{+\kern-.25em+}\xspace} % CC symbolic name
|
---|
| 28 | \def\c11{ISO/IEC C} % C11 name (cannot have numbers in latex command name)
|
---|
| 29 |
|
---|
| 30 | %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
---|
| 31 |
|
---|
[bfee448] | 32 | % Bespoke macros used in the document.
|
---|
[ce6c57c] | 33 |
|
---|
[bfee448] | 34 | \makeatletter
|
---|
| 35 | % index macros
|
---|
[a188b16] | 36 | \newcommand{\italic}[1]{\emph{\hyperpage{#1}}}
|
---|
| 37 | \newcommand{\definition}[1]{\textbf{\hyperpage{#1}}}
|
---|
| 38 | \newcommand{\see}[1]{\emph{see} #1}
|
---|
| 39 |
|
---|
| 40 | % Define some commands that produce formatted index entries suitable for cross-references.
|
---|
| 41 | % ``\spec'' produces entries for specifications of entities. ``\impl'' produces entries for their
|
---|
| 42 | % implementations, and ``\use'' for their uses.
|
---|
| 43 |
|
---|
| 44 | % \newcommand{\bold}[1]{{\bf #1}}
|
---|
| 45 | % \def\spec{\@bsphack\begingroup
|
---|
| 46 | % \def\protect##1{\string##1\space}\@sanitize
|
---|
| 47 | % \@wrxref{|bold}}
|
---|
| 48 | \def\impl{\@bsphack\begingroup
|
---|
| 49 | \def\protect##1{\string##1\space}\@sanitize
|
---|
| 50 | \@wrxref{|definition}}
|
---|
| 51 | \newcommand{\indexcode}[1]{{\lstinline$#1$}}
|
---|
| 52 | \def\use{\@bsphack\begingroup
|
---|
| 53 | \def\protect##1{\string##1\space}\@sanitize
|
---|
| 54 | \@wrxref{|hyperpage}}
|
---|
| 55 | \def\@wrxref#1#2{\let\thepage\relax
|
---|
| 56 | \xdef\@gtempa{\write\@indexfile{\string
|
---|
| 57 | \indexentry{#2@{\lstinline$#2$}#1}{\thepage}}}\endgroup\@gtempa
|
---|
| 58 | \if@nobreak \ifvmode\nobreak\fi\fi\@esphack}
|
---|
| 59 | %\newcommand{\use}[1]{\index{#1@{\lstinline$#1$}}}
|
---|
| 60 | %\newcommand{\impl}[1]{\index{\protect#1@{\lstinline$\protect#1$}|definition}}
|
---|
[f60d997] | 61 |
|
---|
[bfee448] | 62 | % text inline and lowercase index: \Index{Inline and index text}
|
---|
| 63 | % text inline and as-in index: \Index{Inline and Index text}
|
---|
| 64 | % text inline but index with different as-is text: \Index[index text]{inline text}
|
---|
| 65 | \newcommand{\Index}{\@ifstar\@sIndex\@Index}
|
---|
| 66 | \newcommand{\@Index}[2][\@empty]{\lowercase{\def\temp{#2}}#2\ifx#1\@empty\index{\temp}\else\index{#1@{\protect#2}}\fi}
|
---|
| 67 | \newcommand{\@sIndex}[2][\@empty]{#2\ifx#1\@empty\index{#2}\else\index{#1@{\protect#2}}\fi}
|
---|
| 68 | \makeatother
|
---|
| 69 |
|
---|
| 70 | % blocks and titles
|
---|
[f60d997] | 71 | \newcommand{\define}[1]{\emph{#1\/}\index{#1}}
|
---|
| 72 | \newenvironment{rationale}{%
|
---|
| 73 | \begin{quotation}\noindent$\Box$\enspace
|
---|
| 74 | }{%
|
---|
| 75 | \hfill\enspace$\Box$\end{quotation}
|
---|
| 76 | }%
|
---|
| 77 | \newcommand{\rewrite}{\(\Rightarrow\)}
|
---|
[bfee448] | 78 | \newcommand{\rewriterules}{\paragraph{Rewrite Rules}~\par\noindent}
|
---|
| 79 | \newcommand{\examples}{\paragraph{Examples}~\par\noindent}
|
---|
| 80 | \newcommand{\semantics}{\paragraph{Semantics}~\par\noindent}
|
---|
| 81 | \newcommand{\constraints}{\paragraph{Constraints}~\par\noindent}
|
---|
| 82 | \newcommand{\predefined}{\paragraph{Predefined Identifiers}~\par\noindent}
|
---|
[f60d997] | 83 |
|
---|
[bfee448] | 84 | % BNF macros
|
---|
[f60d997] | 85 | \def\syntax{\paragraph{Syntax}\trivlist\parindent=.5in\item[\hskip.5in]}
|
---|
| 86 | \let\endsyntax=\endtrivlist
|
---|
[a188b16] | 87 | \newcommand{\lhs}[1]{\par{\emph{#1:}}\index{#1@{\emph{#1}}|italic}}
|
---|
[f60d997] | 88 | \newcommand{\rhs}{\hfil\break\hbox{\hskip1in}}
|
---|
[a188b16] | 89 | \newcommand{\oldlhs}[1]{\emph{#1: \ldots}\index{#1@{\emph{#1}}|italic}}
|
---|
| 90 | \newcommand{\nonterm}[1]{\emph{#1\/}\index{#1@{\emph{#1}}|italic}}
|
---|
[f60d997] | 91 | \newcommand{\opt}{$_{opt}$\ }
|
---|
| 92 |
|
---|
[bfee448] | 93 | % adjust varioref package with default "section" and "page" titles, and optional title with faraway page numbers
|
---|
| 94 | % \VRef{label} => Section 2.7, \VPageref{label} => page 17
|
---|
| 95 | % \VRef[Figure]{label} => Figure 3.4, \VPageref{label} => page 17
|
---|
[f60d997] | 96 | \renewcommand{\reftextfaceafter}{\unskip}
|
---|
| 97 | \renewcommand{\reftextfacebefore}{\unskip}
|
---|
| 98 | \renewcommand{\reftextafter}{\unskip}
|
---|
| 99 | \renewcommand{\reftextbefore}{\unskip}
|
---|
| 100 | \renewcommand{\reftextfaraway}[1]{\unskip, p.~\pageref{#1}}
|
---|
| 101 | \renewcommand{\reftextpagerange}[2]{\unskip, pp.~\pageref{#1}--\pageref{#2}}
|
---|
| 102 | \newcommand{\VRef}[2][Section]{\ifx#1\@empty\else{#1}\nobreakspace\fi\vref{#2}}
|
---|
| 103 | \newcommand{\VPageref}[2][page]{\ifx#1\@empty\else{#1}\nobreakspace\fi\pageref{#2}}
|
---|
| 104 |
|
---|
[bfee448] | 105 | % adjust listings macros
|
---|
[f60d997] | 106 | \lstdefinelanguage{CFA}[ANSI]{C}%
|
---|
[097e2b0] | 107 | {morekeywords={asm,_Alignas,_Alignof,_At,_Atomic,_Bool,catch,catchResume,choose,_Complex,context,disable,dtype,enable,
|
---|
| 108 | fallthru,finally,forall,ftype,_Generic,_Imaginary,inline,lvalue,_Noreturn,restrict,_Static_assert,
|
---|
| 109 | _Thread_local,throw,throwResume,try,type,},
|
---|
[bfee448] | 110 | }%
|
---|
[f60d997] | 111 |
|
---|
| 112 | \lstset{
|
---|
| 113 | language=CFA,
|
---|
[cf16f94] | 114 | columns=flexible,
|
---|
[f60d997] | 115 | basicstyle=\sf\small,
|
---|
| 116 | tabsize=4,
|
---|
| 117 | xleftmargin=\parindent,
|
---|
| 118 | escapechar=@,
|
---|
[ce6c57c] | 119 | keepspaces=true,
|
---|
[cf16f94] | 120 | %showtabs=true,
|
---|
| 121 | %tab=\rightarrowfill,
|
---|
[bfee448] | 122 | }%
|
---|
| 123 |
|
---|
| 124 | \makeatletter
|
---|
| 125 | % replace/adjust listings characters that look bad in sanserif
|
---|
| 126 | \lst@CCPutMacro
|
---|
| 127 | \lst@ProcessOther{"2D}{\lst@ttfamily{-{}}{{\ttfamily\upshape -}}} % replace minus
|
---|
| 128 | \lst@ProcessOther{"3C}{\lst@ttfamily{<}{\texttt{<}}} % replace less than
|
---|
| 129 | \lst@ProcessOther{"3E}{\lst@ttfamily{<}{\texttt{>}}} % replace greater than
|
---|
| 130 | \lst@ProcessOther{"5E}{\raisebox{0.4ex}{$\scriptstyle\land\,$}} % replace circumflex
|
---|
| 131 | \lst@ProcessLetter{"5F}{\lst@ttfamily{\char95}{{\makebox[1.2ex][c]{\rule{1ex}{0.1ex}}}}} % replace underscore
|
---|
| 132 | \lst@ProcessOther{"7E}{\raisebox{0.3ex}{$\scriptstyle\sim\,$}} % replace tilde
|
---|
| 133 | %\lst@ProcessOther{"7E}{\raisebox{-.4ex}[1ex][0pt]{\textasciitilde}} % lower tilde
|
---|
| 134 | \@empty\z@\@empty
|
---|
| 135 | \makeatother
|
---|
[f60d997] | 136 |
|
---|
| 137 | \setcounter{secnumdepth}{3} % number subsubsections
|
---|
[2fc0e5c] | 138 | \setcounter{tocdepth}{3} % subsubsections in table of contents
|
---|
[f60d997] | 139 | \makeindex
|
---|
| 140 |
|
---|
[ce6c57c] | 141 | %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
---|
| 142 |
|
---|
[f60d997] | 143 | \begin{document}
|
---|
| 144 | \pagestyle{headings}
|
---|
| 145 | \linenumbers % comment out to turn off line numbering
|
---|
| 146 |
|
---|
| 147 | \title{\CFA (\CFAA) Reference Manual and Rationale}
|
---|
[01414f1] | 148 | \author{Glen Ditchfield \and Peter A. Buhr}
|
---|
[f60d997] | 149 | \date{DRAFT\\\today}
|
---|
| 150 |
|
---|
| 151 | \pagenumbering{roman}
|
---|
| 152 | \pagestyle{plain}
|
---|
| 153 |
|
---|
| 154 | \maketitle
|
---|
| 155 |
|
---|
| 156 | \vspace*{\fill}
|
---|
| 157 | \thispagestyle{empty}
|
---|
| 158 | \noindent
|
---|
| 159 | \copyright\,2015 Glen Ditchfield \\ \\
|
---|
| 160 | \noindent
|
---|
| 161 | This work is licensed under the Creative Commons Attribution 4.0 International License. To view a
|
---|
| 162 | copy of this license, visit {\small\url{http://creativecommons.org/licenses/by/4.0}}.
|
---|
| 163 | \vspace*{1in}
|
---|
| 164 |
|
---|
| 165 | \clearpage
|
---|
| 166 | \pdfbookmark[1]{Contents}{section}
|
---|
| 167 | \tableofcontents
|
---|
| 168 |
|
---|
| 169 | \clearpage
|
---|
| 170 | \pagenumbering{arabic}
|
---|
| 171 |
|
---|
| 172 |
|
---|
| 173 | \chapter*{Introduction}\addcontentsline{toc}{chapter}{Introduction}
|
---|
| 174 |
|
---|
| 175 | This document is a reference manual and rationale for \CFA, a polymorphic extension of the C
|
---|
| 176 | programming language. It makes frequent reference to the {\c11} standard \cite{ANS:C11}, and
|
---|
| 177 | occasionally compares \CFA to {\CC} \cite{c++}.
|
---|
| 178 |
|
---|
| 179 | The manual deliberately imitates the ordering of the {\c11} standard (although the section numbering
|
---|
[bfee448] | 180 | differs). Unfortunately, this means the manual contains more ``forward references'' than usual,
|
---|
| 181 | making it harder to follow if the reader does not have a copy of the {\c11} standard. For a simple
|
---|
| 182 | introduction to \CFA, see the companion document ``An Overview of \CFA''
|
---|
| 183 | \cite{Ditchfield96:Overview}.
|
---|
[f60d997] | 184 |
|
---|
| 185 | \begin{rationale}
|
---|
| 186 | Commentary (like this) is quoted with quads. Commentary usually deals with subtle points, the
|
---|
| 187 | rationale behind a rule, and design decisions.
|
---|
| 188 | \end{rationale}
|
---|
| 189 |
|
---|
| 190 | % No ``Scope'' or ``Normative references'' chapters yet.
|
---|
[41b3ddd] | 191 |
|
---|
| 192 |
|
---|
[f60d997] | 193 | \setcounter{chapter}{2}
|
---|
| 194 | \chapter{Terms, definitions, and symbols}
|
---|
[41b3ddd] | 195 |
|
---|
[f60d997] | 196 | Terms from the {\c11} standard used in this document have the same meaning as in the {\c11}
|
---|
| 197 | standard.
|
---|
| 198 |
|
---|
| 199 | % No ``Conformance'' or ``Environment'' chapters yet.
|
---|
[41b3ddd] | 200 |
|
---|
| 201 |
|
---|
[f60d997] | 202 | \setcounter{chapter}{5}
|
---|
| 203 | \chapter{Language}
|
---|
[41b3ddd] | 204 |
|
---|
| 205 |
|
---|
[f60d997] | 206 | \section{Notation}
|
---|
[bfee448] | 207 | The syntax notation used in this document is the same as in the {\c11} standard, with one exception:
|
---|
| 208 | ellipsis in the definition of a nonterminal, as in ``\emph{declaration:} \ldots'', indicates that
|
---|
| 209 | these rules extend a previous definition, which occurs in this document or in the {\c11} standard.
|
---|
[f60d997] | 210 |
|
---|
| 211 |
|
---|
| 212 | \section{Concepts}
|
---|
| 213 |
|
---|
| 214 |
|
---|
| 215 | \subsection{Scopes of identifiers}\index{scopes}
|
---|
| 216 |
|
---|
| 217 | \CFA's scope rules differ from C's in one major respect: a declaration of an identifier may
|
---|
[2fc0e5c] | 218 | overload\index{overloading} outer declarations of lexically identical identifiers in the same
|
---|
| 219 | \Index{name space}, instead of hiding them. The outer declaration is hidden if the two declarations
|
---|
| 220 | have \Index{compatible type}, or if one declares an array type and the other declares a pointer type
|
---|
| 221 | and the element type and pointed-at type are compatible, or if one has function type and the other
|
---|
| 222 | is a pointer to a compatible function type, or if one declaration is a \lstinline$type$\use{type} or
|
---|
| 223 | \lstinline$typedef$\use{typedef} declaration and the other is not. The outer declaration becomes
|
---|
| 224 | \Index{visible} when the scope of the inner declaration terminates.
|
---|
[f60d997] | 225 | \begin{rationale}
|
---|
| 226 | Hence, a \CFA program can declare an \lstinline$int v$ and a \lstinline$float v$ in the same
|
---|
| 227 | scope; a {\CC} program can not.
|
---|
| 228 | \end{rationale}
|
---|
| 229 |
|
---|
| 230 |
|
---|
[2fc0e5c] | 231 | \subsection{Linkage of identifiers}
|
---|
| 232 | \index{linkage}
|
---|
[f60d997] | 233 |
|
---|
[2fc0e5c] | 234 | \CFA's linkage rules differ from C's in only one respect: instances of a particular identifier with
|
---|
| 235 | external or internal linkage do not necessarily denote the same object or function. Instead, in the
|
---|
| 236 | set of translation units and libraries that constitutes an entire program, any two instances of a
|
---|
| 237 | particular identifier with \Index{external linkage} denote the same object or function if they have
|
---|
| 238 | \Index{compatible type}s, or if one declares an array type and the other declares a pointer type and
|
---|
| 239 | the element type and pointed-at type are compatible, or if one has function type and the other is a
|
---|
| 240 | pointer to a compatible function type. Within one translation unit, each instance of an identifier
|
---|
| 241 | with \Index{internal linkage} denotes the same object or function in the same circumstances.
|
---|
| 242 | Identifiers with \Index{no linkage} always denote unique entities.
|
---|
[f60d997] | 243 | \begin{rationale}
|
---|
| 244 | A \CFA program can declare an \lstinline$extern int v$ and an \lstinline$extern float v$; a C
|
---|
| 245 | program cannot.
|
---|
| 246 | \end{rationale}
|
---|
| 247 |
|
---|
[41b3ddd] | 248 |
|
---|
| 249 | \setcounter{subsection}{8}
|
---|
| 250 | \subsection{Generic Types}
|
---|
| 251 |
|
---|
| 252 |
|
---|
| 253 | \subsubsection{Semantics}
|
---|
| 254 |
|
---|
[20e409e] | 255 | \CFA provides a capability for generic types; using this capability a single "generic type
|
---|
| 256 | generator" can be written that can represent multiple concrete type instantiations by substitution
|
---|
| 257 | of the "type parameters" of the generic type for concrete types. Syntactically a generic type
|
---|
| 258 | generator is represented by putting a forall specifier on a struct or union declaration, as defined
|
---|
| 259 | in \VRef{forall}. An instantiation of the generic type is written by specifying the type parameters
|
---|
| 260 | in parentheses after the name of the generic type generator:
|
---|
[41b3ddd] | 261 | \begin{lstlisting}
|
---|
[20e409e] | 262 | forall( type T | sumable( T ) ) struct pair {
|
---|
[41b3ddd] | 263 | T x;
|
---|
| 264 | T y;
|
---|
| 265 | };
|
---|
| 266 | pair( int ) p = { 3, 14 };
|
---|
| 267 | \end{lstlisting}
|
---|
| 268 |
|
---|
| 269 | The type parameters in an instantiation of a generic type must satisfy any constraints in the forall
|
---|
[20e409e] | 270 | specifier on the type generator declaration, e.g., \lstinline$sumable$. The instantiation then has
|
---|
| 271 | the semantics that would result if the type parameters were substituted into the type generator
|
---|
| 272 | declaration by macro substitution.
|
---|
[41b3ddd] | 273 |
|
---|
| 274 | Polymorphic functions may have generic types as parameters, and those generic types may use type
|
---|
[20e409e] | 275 | parameters of the polymorphic function as type parameters of the generic type:
|
---|
[41b3ddd] | 276 | \begin{lstlisting}
|
---|
| 277 | forall( type T ) void swap( pair(T) *p ) {
|
---|
| 278 | T z = p->x;
|
---|
| 279 | p->x = p->y;
|
---|
| 280 | p->y = z;
|
---|
| 281 | }
|
---|
| 282 | \end{lstlisting}
|
---|
| 283 |
|
---|
| 284 |
|
---|
| 285 | \subsubsection{Constraints}
|
---|
| 286 |
|
---|
| 287 | To avoid unduly constraining implementors, the generic type generator definition must be visible at
|
---|
| 288 | any point where it is instantiated. Forward declarations of generic type generators are not
|
---|
| 289 | forbidden, but the definition must be visible to instantiate the generic type. Equivalently,
|
---|
| 290 | instantiations of generic types are not allowed to be incomplete types.
|
---|
| 291 |
|
---|
| 292 | \examples
|
---|
| 293 | \begin{lstlisting}
|
---|
| 294 | forall( type T ) struct A;
|
---|
| 295 |
|
---|
| 296 | forall( type T ) struct B {
|
---|
| 297 | A(T) *a; // legal, but cannot instantiate B(T)
|
---|
| 298 | };
|
---|
| 299 |
|
---|
| 300 | B(T) x; // illegal, *x.a is of an incomplete generic type
|
---|
| 301 |
|
---|
| 302 | forall( type T ) struct A {
|
---|
| 303 | B( T ) *b;
|
---|
| 304 | };
|
---|
| 305 |
|
---|
| 306 | B( T ) y; // legal, *x.a is now of a complete generic type
|
---|
| 307 |
|
---|
| 308 |
|
---|
| 309 | // box.h:
|
---|
| 310 | forall( type T ) struct box;
|
---|
| 311 | forall( type T ) box( T ) *make_box( T );
|
---|
| 312 | forall( type T ) void use_box( box( T ) *b );
|
---|
| 313 |
|
---|
| 314 | // main.c:
|
---|
| 315 | box( int ) *b = make_box( 42 ); // illegal, def'n of box not visible
|
---|
| 316 | use_box( b ); // illegal
|
---|
| 317 | \end{lstlisting}
|
---|
| 318 |
|
---|
| 319 |
|
---|
[f60d997] | 320 | \section{Conversions}
|
---|
| 321 | \CFA defines situations where values of one type are automatically converted to another type.
|
---|
[2fc0e5c] | 322 | These conversions are called \define{implicit conversion}s. The programmer can request
|
---|
| 323 | \define{explicit conversion}s using cast expressions.
|
---|
[f60d997] | 324 |
|
---|
| 325 |
|
---|
| 326 | \subsection{Arithmetic operands}
|
---|
| 327 |
|
---|
| 328 |
|
---|
[41b3ddd] | 329 | \setcounter{subsubsection}{8}
|
---|
[f60d997] | 330 | \subsubsection{Safe arithmetic conversions}
|
---|
[41b3ddd] | 331 |
|
---|
[2fc0e5c] | 332 | In C, a pattern of conversions known as the \define{usual arithmetic conversion}s is used with most
|
---|
[f60d997] | 333 | binary arithmetic operators to convert the operands to a common type and determine the type of the
|
---|
| 334 | operator's result. In \CFA, these conversions play a role in overload resolution, and
|
---|
[2fc0e5c] | 335 | collectively are called the \define{safe arithmetic conversion}s.
|
---|
[f60d997] | 336 |
|
---|
| 337 | Let \(int_r\) and \(unsigned_r\) be the signed and unsigned integer types with integer conversion
|
---|
[2fc0e5c] | 338 | rank\index{integer conversion rank}\index{rank|see{integer conversion rank}} $r$. Let
|
---|
[f60d997] | 339 | \(unsigned_{mr}\) be the unsigned integer type with maximal rank.
|
---|
| 340 |
|
---|
| 341 | The following conversions are \emph{direct} safe arithmetic conversions.
|
---|
| 342 | \begin{itemize}
|
---|
| 343 | \item
|
---|
[2fc0e5c] | 344 | The \Index{integer promotion}s.
|
---|
[f60d997] | 345 |
|
---|
| 346 | \item
|
---|
| 347 | For every rank $r$ greater than or equal to the rank of \lstinline$int$, conversion from \(int_r\)
|
---|
| 348 | to \(unsigned_r\).
|
---|
| 349 |
|
---|
| 350 | \item
|
---|
| 351 | For every rank $r$ greater than or equal to the rank of \lstinline$int$, where \(int_{r+1}\) exists
|
---|
| 352 | and can represent all values of \(unsigned_r\), conversion from \(unsigned_r\) to \(int_{r+1}\).
|
---|
| 353 |
|
---|
| 354 | \item
|
---|
| 355 | Conversion from \(unsigned_{mr}\) to \lstinline$float$.
|
---|
| 356 |
|
---|
| 357 | \item
|
---|
| 358 | Conversion from an enumerated type to its compatible integer type.
|
---|
| 359 |
|
---|
| 360 | \item
|
---|
| 361 | Conversion from \lstinline$float$ to \lstinline$double$, and from \lstinline$double$ to
|
---|
| 362 | \lstinline$long double$.
|
---|
| 363 |
|
---|
| 364 | \item
|
---|
| 365 | Conversion from \lstinline$float _Complex$ to \lstinline$double _Complex$,
|
---|
| 366 | and from \lstinline$double _Complex$ to \lstinline$long double _Complex$.
|
---|
| 367 |
|
---|
| 368 | \begin{sloppypar}
|
---|
| 369 | \item
|
---|
| 370 | Conversion from \lstinline$float _Imaginary$ to \lstinline$double _Imaginary$, and from
|
---|
| 371 | \lstinline$double _Imaginary$ to \lstinline$long double$ \lstinline$_Imaginary$, if the
|
---|
| 372 | implementation supports imaginary types.
|
---|
| 373 | \end{sloppypar}
|
---|
| 374 | \end{itemize}
|
---|
| 375 |
|
---|
| 376 | If type \lstinline$T$ can be converted to type \lstinline$U$ by a safe direct arithmetic conversion
|
---|
| 377 | and type \lstinline$U$ can be converted to type \lstinline$V$ by a safe arithmetic conversion, then
|
---|
| 378 | the conversion from \lstinline$T$ to type \lstinline$V$ is an \emph{indirect} safe arithmetic
|
---|
| 379 | conversion.
|
---|
| 380 |
|
---|
| 381 | \begin{rationale}
|
---|
[2fc0e5c] | 382 | Note that {\c11} does not include conversion from \Index{real type}s to \Index{complex type}s in the
|
---|
| 383 | usual arithmetic conversions, and \CFA does not include them as safe conversions.
|
---|
[f60d997] | 384 | \end{rationale}
|
---|
| 385 |
|
---|
| 386 |
|
---|
| 387 | \subsection{Other operands}
|
---|
| 388 |
|
---|
| 389 |
|
---|
[41b3ddd] | 390 | \setcounter{subsubsection}{3}
|
---|
[f60d997] | 391 | \subsubsection{Anonymous structures and unions}
|
---|
| 392 | \label{anon-conv}
|
---|
| 393 |
|
---|
| 394 | If an expression's type is a pointer to a structure or union type that has a member that is an
|
---|
[2fc0e5c] | 395 | \Index{anonymous structure} or an \Index{anonymous union}, it can be implicitly
|
---|
| 396 | converted\index{implicit conversion} to a pointer to the anonymous structure's or anonymous union's
|
---|
| 397 | type. The result of the conversion is a pointer to the member.
|
---|
[f60d997] | 398 |
|
---|
| 399 | \examples
|
---|
| 400 | \begin{lstlisting}
|
---|
| 401 | struct point {
|
---|
| 402 | int x, y;
|
---|
| 403 | };
|
---|
| 404 | void move_by(struct point * p1, struct point * p2) {@\impl{move_by}@
|
---|
| 405 | p1->x += p2.x;
|
---|
| 406 | p1->y += p2.y;
|
---|
| 407 | }
|
---|
| 408 |
|
---|
| 409 | struct color_point {
|
---|
| 410 | enum { RED, BLUE, GREEN } color;
|
---|
| 411 | struct point;
|
---|
| 412 | } cp1, cp2;
|
---|
| 413 | move_to(&cp1, &cp2);
|
---|
| 414 | \end{lstlisting}
|
---|
| 415 | Thanks to implicit conversion, the two arguments that \lstinline$move_by()$ receives are pointers to
|
---|
| 416 | \lstinline$cp1$'s second member and \lstinline$cp2$'s second member.
|
---|
| 417 |
|
---|
| 418 |
|
---|
| 419 | \subsubsection{Specialization}
|
---|
[2fc0e5c] | 420 | A function or value whose type is polymorphic may be implicitly converted to one whose type is
|
---|
| 421 | \Index{less polymorphic} by binding values to one or more of its \Index{inferred parameter}. Any
|
---|
| 422 | value that is legal for the inferred parameter may be used, including other inferred parameters.
|
---|
[f60d997] | 423 |
|
---|
[2fc0e5c] | 424 | If, after the inferred parameter binding, an \Index{assertion parameter} has no inferred parameters
|
---|
| 425 | in its type, then an object or function must be visible at the point of the specialization that has
|
---|
| 426 | the same identifier as the assertion parameter and has a type that is compatible\index{compatible
|
---|
| 427 | type} with or can be specialized to the type of the assertion parameter. The assertion parameter
|
---|
| 428 | is bound to that object or function.
|
---|
[f60d997] | 429 |
|
---|
| 430 | The type of the specialization is the type of the original with the bound inferred parameters and
|
---|
| 431 | the bound assertion parameters replaced by their bound values.
|
---|
| 432 |
|
---|
| 433 | \examples
|
---|
| 434 | The type
|
---|
| 435 | \begin{lstlisting}
|
---|
| 436 | forall( type T, type U ) void (*)( T, U );
|
---|
| 437 | \end{lstlisting}
|
---|
| 438 | can be specialized to (among other things)
|
---|
| 439 | \begin{lstlisting}
|
---|
| 440 | forall( type T ) void (*)( T, T ); // U bound to T
|
---|
| 441 | forall( type T ) void (*)( T, real ); // U bound to real
|
---|
| 442 | forall( type U ) void (*)( real, U ); // T bound to real
|
---|
| 443 | void f( real, real ); // both bound to real
|
---|
| 444 | \end{lstlisting}
|
---|
| 445 |
|
---|
| 446 | The type
|
---|
| 447 | \begin{lstlisting}
|
---|
| 448 | forall( type T | T ?+?( T, T )) T (*)( T );
|
---|
| 449 | \end{lstlisting}
|
---|
| 450 | can be specialized to (among other things)
|
---|
| 451 | \begin{lstlisting}
|
---|
| 452 | int (*)( int ); // T bound to int, and T ?+?(T, T ) bound to int ?+?( int, int )
|
---|
| 453 | \end{lstlisting}
|
---|
| 454 |
|
---|
| 455 |
|
---|
| 456 | \subsubsection{Safe conversions}
|
---|
| 457 |
|
---|
| 458 | A \define{direct safe conversion} is one of the following conversions:
|
---|
| 459 | \begin{itemize}
|
---|
| 460 | \item
|
---|
| 461 | a direct safe arithmetic conversion;
|
---|
| 462 | \item
|
---|
| 463 | from any object type or incomplete type to \lstinline$void$;
|
---|
| 464 | \item
|
---|
| 465 | from a pointer to any non-\lstinline$void$ type to a pointer to \lstinline$void$;
|
---|
| 466 | \item
|
---|
| 467 | from a pointer to any type to a pointer to a more qualified version of the type\index{qualified
|
---|
| 468 | type};
|
---|
| 469 | \item
|
---|
| 470 | from a pointer to a structure or union type to a pointer to the type of a member of the structure or
|
---|
[2fc0e5c] | 471 | union that is an \Index{anonymous structure} or an \Index{anonymous union};
|
---|
[f60d997] | 472 | \item
|
---|
[2fc0e5c] | 473 | within the scope of an initialized \Index{type declaration}, conversions between a type and its
|
---|
| 474 | implementation or between a pointer to a type and a pointer to its implementation.
|
---|
[f60d997] | 475 | \end{itemize}
|
---|
| 476 |
|
---|
[2fc0e5c] | 477 | Conversions that are not safe conversions are \define{unsafe conversion}s.
|
---|
[f60d997] | 478 | \begin{rationale}
|
---|
| 479 | As in C, there is an implicit conversion from \lstinline$void *$ to any pointer type. This is
|
---|
| 480 | clearly dangerous, and {\CC} does not have this implicit conversion.
|
---|
| 481 | \CFA\index{deficiencies!void * conversion} keeps it, in the interest of remaining as pure a
|
---|
| 482 | superset of C as possible, but discourages it by making it unsafe.
|
---|
| 483 | \end{rationale}
|
---|
| 484 |
|
---|
| 485 |
|
---|
| 486 | \subsection{Conversion cost}
|
---|
| 487 |
|
---|
[2fc0e5c] | 488 | The \define{conversion cost} of a safe\index{safe conversion}
|
---|
| 489 | conversion\footnote{Unsafe\index{unsafe conversion} conversions do not have defined conversion
|
---|
[f60d997] | 490 | costs.} is a measure of how desirable or undesirable it is. It is defined as follows.
|
---|
| 491 | \begin{itemize}
|
---|
| 492 | \item
|
---|
| 493 | The cost of a conversion from any type to itself is 0.
|
---|
| 494 |
|
---|
| 495 | \item
|
---|
| 496 | The cost of a direct safe conversion is 1.
|
---|
| 497 |
|
---|
| 498 | \item
|
---|
| 499 | The cost of an indirect safe arithmetic conversion is the smallest number of direct conversions
|
---|
| 500 | needed to make up the conversion.
|
---|
| 501 | \end{itemize}
|
---|
| 502 |
|
---|
| 503 | \examples
|
---|
| 504 | In the following, assume an implementation that does not provide any extended integer types.
|
---|
| 505 |
|
---|
| 506 | \begin{itemize}
|
---|
| 507 | \item
|
---|
| 508 | The cost of an implicit conversion from \lstinline$int$ to \lstinline$long$ is 1. The cost of an
|
---|
| 509 | implicit conversion from \lstinline$long$ to \lstinline$double$ is 3, because it is defined in terms
|
---|
| 510 | of conversions from \lstinline$long$ to \lstinline$unsigned long$, then to \lstinline$float$, and
|
---|
| 511 | then to \lstinline$double$.
|
---|
| 512 |
|
---|
| 513 | \item
|
---|
| 514 | If \lstinline$int$ can represent all the values of \lstinline$unsigned short$, then the cost of an
|
---|
| 515 | implicit conversion from \lstinline$unsigned short$ to \lstinline$unsigned$ is 2:
|
---|
| 516 | \lstinline$unsigned short$ to \lstinline$int$ to \lstinline$unsigned$. Otherwise,
|
---|
| 517 | \lstinline$unsigned short$ is converted directly to \lstinline$unsigned$, and the cost is 1.
|
---|
| 518 |
|
---|
| 519 | \item
|
---|
| 520 | If \lstinline$long$ can represent all the values of \lstinline$unsigned$, then the conversion cost
|
---|
| 521 | of \lstinline$unsigned$ to \lstinline$long$ is 1. Otherwise, the conversion is an unsafe
|
---|
| 522 | conversion, and its conversion cost is undefined.
|
---|
| 523 | \end{itemize}
|
---|
| 524 |
|
---|
| 525 | \section{Lexical elements}
|
---|
| 526 | \subsection{Keywords}
|
---|
| 527 | \begin{syntax}
|
---|
| 528 | \oldlhs{keyword}
|
---|
| 529 | \rhs \lstinline$forall$
|
---|
| 530 | \rhs \lstinline$lvalue$
|
---|
| 531 | \rhs \lstinline$context$
|
---|
| 532 | \rhs \lstinline$dtype$
|
---|
| 533 | \rhs \lstinline$ftype$
|
---|
| 534 | \rhs \lstinline$type$
|
---|
| 535 | \end{syntax}
|
---|
| 536 |
|
---|
| 537 |
|
---|
| 538 | \subsection{Identifiers}
|
---|
| 539 |
|
---|
[2fc0e5c] | 540 | \CFA allows operator \Index{overloading} by associating operators with special function
|
---|
| 541 | identifiers. Furthermore, the constants ``\lstinline$0$'' and ``\lstinline$1$'' have special status
|
---|
| 542 | for many of C's data types (and for many programmer-defined data types as well), so \CFA treats them
|
---|
| 543 | as overloadable identifiers. Programmers can use these identifiers to declare functions and objects
|
---|
| 544 | that implement operators and constants for their own types.
|
---|
[f60d997] | 545 |
|
---|
| 546 |
|
---|
| 547 | \setcounter{subsubsection}{2}
|
---|
| 548 | \subsubsection{Constant identifiers}
|
---|
| 549 |
|
---|
| 550 | \begin{syntax}
|
---|
| 551 | \oldlhs{identifier}
|
---|
| 552 | \rhs \lstinline$0$
|
---|
| 553 | \rhs \lstinline$1$
|
---|
| 554 | \end{syntax}
|
---|
| 555 |
|
---|
| 556 | \index{constant identifiers}\index{identifiers!for constants} The tokens ``\lstinline$0$''\impl{0}
|
---|
| 557 | and ``\lstinline$1$''\impl{1} are identifiers. No other tokens defined by the rules for integer
|
---|
| 558 | constants are considered to be identifiers.
|
---|
| 559 | \begin{rationale}
|
---|
| 560 | Why ``\lstinline$0$'' and ``\lstinline$1$''? Those integers have special status in C. All scalar
|
---|
| 561 | types can be incremented and decremented, which is defined in terms of adding or subtracting 1. The
|
---|
| 562 | operations ``\lstinline$&&$'', ``\lstinline$||$'', and ``\lstinline$!$'' can be applied to any
|
---|
| 563 | scalar arguments, and are defined in terms of comparison against 0. A \nonterm{constant-expression}
|
---|
| 564 | that evaluates to 0 is effectively compatible with every pointer type.
|
---|
| 565 |
|
---|
| 566 | In C, the integer constants 0 and 1 suffice because the integer promotion rules can convert them to
|
---|
| 567 | any arithmetic type, and the rules for pointer expressions treat constant expressions evaluating to
|
---|
| 568 | 0 as a special case. However, user-defined arithmetic types often need the equivalent of a 1 or 0
|
---|
| 569 | for their functions or operators, polymorphic functions often need 0 and 1 constants of a type
|
---|
| 570 | matching their polymorphic parameters, and user-defined pointer-like types may need a null value.
|
---|
| 571 | Defining special constants for a user-defined type is more efficient than defining a conversion to
|
---|
| 572 | the type from \lstinline$_Bool$.
|
---|
| 573 |
|
---|
| 574 | Why \emph{just} ``\lstinline$0$'' and ``\lstinline$1$''? Why not other integers? No other integers
|
---|
| 575 | have special status in C. A facility that let programmers declare specific
|
---|
| 576 | constants---``\lstinline$const Rational 12$'', for instance---would not be much of an improvement.
|
---|
| 577 | Some facility for defining the creation of values of programmer-defined types from arbitrary integer
|
---|
| 578 | tokens would be needed. The complexity of such a feature doesn't seem worth the gain.
|
---|
| 579 | \end{rationale}
|
---|
| 580 |
|
---|
| 581 |
|
---|
| 582 | \subsubsection{Operator identifiers}
|
---|
| 583 |
|
---|
| 584 | \index{operator identifiers}\index{identifiers!for operators} Table \ref{opids} lists the
|
---|
| 585 | programmer-definable operator identifiers and the operations they are associated with. Functions
|
---|
| 586 | that are declared with (or pointed at by function pointers that are declared with) these identifiers
|
---|
| 587 | can be called by expressions that use the operator tokens and syntax, or the operator identifiers
|
---|
| 588 | and ``function call'' syntax. The relationships between operators and function calls are discussed
|
---|
| 589 | in descriptions of the operators.
|
---|
| 590 |
|
---|
| 591 | \begin{table}[hbt]
|
---|
| 592 | \hfil
|
---|
| 593 | \begin{tabular}[t]{ll}
|
---|
| 594 | %identifier & operation \\ \hline
|
---|
| 595 | \lstinline$?[?]$ & subscripting \impl{?[?]}\\
|
---|
| 596 | \lstinline$?()$ & function call \impl{?()}\\
|
---|
| 597 | \lstinline$?++$ & postfix increment \impl{?++}\\
|
---|
| 598 | \lstinline$?--$ & postfix decrement \impl{?--}\\
|
---|
| 599 | \lstinline$++?$ & prefix increment \impl{++?}\\
|
---|
| 600 | \lstinline$--?$ & prefix decrement \impl{--?}\\
|
---|
| 601 | \lstinline$*?$ & dereference \impl{*?}\\
|
---|
| 602 | \lstinline$+?$ & unary plus \impl{+?}\\
|
---|
| 603 | \lstinline$-?$ & arithmetic negation \impl{-?}\\
|
---|
| 604 | \lstinline$~?$ & bitwise negation \impl{~?}\\
|
---|
| 605 | \lstinline$!?$ & logical complement \impl{"!?}\\
|
---|
| 606 | \lstinline$?*?$ & multiplication \impl{?*?}\\
|
---|
| 607 | \lstinline$?/?$ & division \impl{?/?}\\
|
---|
| 608 | \end{tabular}\hfil
|
---|
| 609 | \begin{tabular}[t]{ll}
|
---|
| 610 | %identifier & operation \\ \hline
|
---|
| 611 | \lstinline$?%?$ & remainder \impl{?%?}\\
|
---|
| 612 | \lstinline$?+?$ & addition \impl{?+?}\\
|
---|
| 613 | \lstinline$?-?$ & subtraction \impl{?-?}\\
|
---|
| 614 | \lstinline$?<<?$ & left shift \impl{?<<?}\\
|
---|
| 615 | \lstinline$?>>?$ & right shift \impl{?>>?}\\
|
---|
| 616 | \lstinline$?<?$ & less than \impl{?<?}\\
|
---|
| 617 | \lstinline$?<=?$ & less than or equal \impl{?<=?}\\
|
---|
| 618 | \lstinline$?>=?$ & greater than or equal \impl{?>=?}\\
|
---|
| 619 | \lstinline$?>?$ & greater than \impl{?>?}\\
|
---|
| 620 | \lstinline$?==?$ & equality \impl{?==?}\\
|
---|
| 621 | \lstinline$?!=?$ & inequality \impl{?"!=?}\\
|
---|
| 622 | \lstinline$?&?$ & bitwise AND \impl{?&?}\\
|
---|
| 623 | \end{tabular}\hfil
|
---|
| 624 | \begin{tabular}[t]{ll}
|
---|
| 625 | %identifier & operation \\ \hline
|
---|
| 626 | \lstinline$?^?$ & exclusive OR \impl{?^?}\\
|
---|
| 627 | \lstinline$?|?$ & inclusive OR \impl{?"|?}\\
|
---|
| 628 | \lstinline$?=?$ & simple assignment \impl{?=?}\\
|
---|
| 629 | \lstinline$?*=?$ & multiplication assignment \impl{?*=?}\\
|
---|
| 630 | \lstinline$?/=?$ & division assignment \impl{?/=?}\\
|
---|
| 631 | \lstinline$?%=?$ & remainder assignment \impl{?%=?}\\
|
---|
| 632 | \lstinline$?+=?$ & addition assignment \impl{?+=?}\\
|
---|
| 633 | \lstinline$?-=?$ & subtraction assignment \impl{?-=?}\\
|
---|
| 634 | \lstinline$?<<=?$ & left-shift assignment \impl{?<<=?}\\
|
---|
| 635 | \lstinline$?>>=?$ & right-shift assignment \impl{?>>=?}\\
|
---|
| 636 | \lstinline$?&=?$ & bitwise AND assignment \impl{?&=?}\\
|
---|
| 637 | \lstinline$?^=?$ & exclusive OR assignment \impl{?^=?}\\
|
---|
| 638 | \lstinline$?|=?$ & inclusive OR assignment \impl{?"|=?}\\
|
---|
| 639 | \end{tabular}
|
---|
| 640 | \hfil
|
---|
| 641 | \caption{Operator Identifiers}
|
---|
| 642 | \label{opids}
|
---|
| 643 | \end{table}
|
---|
| 644 |
|
---|
| 645 | \begin{rationale}
|
---|
| 646 | Operator identifiers are made up of the characters of the operator token, with question marks added
|
---|
| 647 | to mark the positions of the arguments of operators. The question marks serve as mnemonic devices;
|
---|
| 648 | programmers can not create new operators by arbitrarily mixing question marks and other
|
---|
| 649 | non-alphabetic characters. Note that prefix and postfix versions of the increment and decrement
|
---|
| 650 | operators are distinguished by the position of the question mark.
|
---|
| 651 | \end{rationale}
|
---|
| 652 |
|
---|
| 653 | \begin{rationale}
|
---|
[bfee448] | 654 | The use of ``\lstinline$?$'' in identifiers means that some C programs are not \CFA programs. For
|
---|
| 655 | instance, the sequence of characters ``\lstinline$(i < 0)?--i:i$'' is legal in a C program, but a
|
---|
| 656 | \CFA compiler detects a syntax error because it treats ``\lstinline$?--$'' as an identifier, not
|
---|
| 657 | as the two tokens ``\lstinline$?$'' and ``\lstinline$--$''.
|
---|
[f60d997] | 658 | \end{rationale}
|
---|
| 659 |
|
---|
| 660 | \begin{rationale}
|
---|
| 661 | Certain operators \emph{cannot} be defined by the programmer:
|
---|
| 662 | \begin{itemize}
|
---|
| 663 | \item
|
---|
| 664 | The logical operators ``\lstinline$&&$'' and ``\lstinline$||$'', and the conditional operator
|
---|
| 665 | ``\lstinline$?:$''. These operators do not always evaluate their operands, and hence can not be
|
---|
| 666 | properly defined by functions unless some mechanism like call-by-name is added to the language.
|
---|
| 667 | Note that the definitions of ``\lstinline$&&$'' and ``\lstinline$||$'' say that they work by
|
---|
| 668 | checking that their arguments are unequal to 0, so defining ``\lstinline$!=$'' and ``\lstinline$0$''
|
---|
| 669 | for user-defined types is enough to allow them to be used in logical expressions.
|
---|
| 670 |
|
---|
| 671 | \item
|
---|
| 672 | The comma operator\index{comma expression}. It is a control-flow operator like those above.
|
---|
| 673 | Changing its meaning seems pointless and confusing.
|
---|
| 674 |
|
---|
| 675 | \item
|
---|
| 676 | The ``address of'' operator. It would seem useful to define a unary ``\lstinline$&$'' operator that
|
---|
| 677 | returns values of some programmer-defined pointer-like type. The problem lies with the type of the
|
---|
| 678 | operator. Consider the expression ``\lstinline$p = &x$'', where \lstinline$x$ is of type
|
---|
| 679 | \lstinline$T$ and \lstinline$p$ has the programmer-defined type \lstinline$T_ptr$. The expression
|
---|
| 680 | might be treated as a call to the unary function ``\lstinline$&?$''. Now what is the type of the
|
---|
| 681 | function's parameter? It can not be \lstinline$T$, because then \lstinline$x$ would be passed by
|
---|
| 682 | value, and there is no way to create a useful pointer-like result from a value. Hence the parameter
|
---|
| 683 | must have type \lstinline$T *$. But then the expression must be rewritten as ``\lstinline$p = &?( &x )$''
|
---|
| 684 | ---which doesn't seem like progress!
|
---|
| 685 |
|
---|
| 686 | The rule for address-of expressions would have to be something like ``keep applying address-of
|
---|
| 687 | functions until you get one that takes a pointer argument, then use the built-in operator and
|
---|
| 688 | stop''. It seems simpler to define a conversion function from \lstinline$T *$ to \lstinline$T_ptr$.
|
---|
| 689 |
|
---|
| 690 | \item
|
---|
| 691 | The \lstinline$sizeof$ operator. It is already defined for every object type, and intimately tied
|
---|
| 692 | into the language's storage allocation model. Redefining it seems pointless.
|
---|
| 693 |
|
---|
| 694 | \item
|
---|
| 695 | The ``member of'' operators ``\lstinline$.$'' and ``\lstinline$->$''. These are not really infix
|
---|
| 696 | operators, since their right ``operand'' is not a value or object.
|
---|
| 697 |
|
---|
| 698 | \item
|
---|
| 699 | Cast operators\index{cast expression}. Anything that can be done with an explicit cast can be done
|
---|
| 700 | with a function call. The difference in syntax is small.
|
---|
| 701 | \end{itemize}
|
---|
| 702 | \end{rationale}
|
---|
| 703 |
|
---|
| 704 |
|
---|
| 705 | \section{Expressions}
|
---|
[2fc0e5c] | 706 |
|
---|
[f60d997] | 707 | \CFA allows operators and identifiers to be overloaded. Hence, each expression can have a number
|
---|
[2fc0e5c] | 708 | of \define{interpretation}s, each of which has a different type. The interpretations that are
|
---|
| 709 | potentially executable are called \define{valid interpretation}s. The set of interpretations
|
---|
[f60d997] | 710 | depends on the kind of expression and on the interpretations of the subexpressions that it contains.
|
---|
| 711 | The rules for determining the valid interpretations of an expression are discussed below for each
|
---|
| 712 | kind of expression. Eventually the context of the outermost expression chooses one interpretation
|
---|
| 713 | of that expression.
|
---|
| 714 |
|
---|
| 715 | An \define{ambiguous interpretation} is an interpretation which does not specify the exact object or
|
---|
| 716 | function denoted by every identifier in the expression. An expression can have some interpretations
|
---|
| 717 | that are ambiguous and others that are unambiguous. An expression that is chosen to be executed
|
---|
| 718 | shall not be ambiguous.
|
---|
| 719 |
|
---|
| 720 | The \define{best valid interpretations} are the valid interpretations that use the fewest
|
---|
[2fc0e5c] | 721 | unsafe\index{unsafe conversion} conversions. Of these, the best are those where the functions and
|
---|
[f60d997] | 722 | objects involved are the least polymorphic\index{less polymorphic}. Of these, the best have the
|
---|
[2fc0e5c] | 723 | lowest total \Index{conversion cost}, including all implicit conversions in the argument
|
---|
| 724 | expressions. Of these, the best have the highest total conversion cost for the implicit conversions
|
---|
| 725 | (if any) applied to the argument expressions. If there is no single best valid interpretation, or if
|
---|
| 726 | the best valid interpretation is ambiguous, then the resulting interpretation is
|
---|
| 727 | ambiguous\index{ambiguous interpretation}.
|
---|
[f60d997] | 728 |
|
---|
| 729 | \begin{rationale}
|
---|
| 730 | \CFA's rules for selecting the best interpretation are designed to allow overload resolution to
|
---|
| 731 | mimic C's operator semantics. In C, the ``usual arithmetic conversions'' are applied to the
|
---|
| 732 | operands of binary operators if necessary to convert the operands to types with a common real type.
|
---|
| 733 | In \CFA, those conversions are ``safe''. The ``fewest unsafe conversions'' rule ensures that the
|
---|
| 734 | usual conversions are done, if possible. The ``lowest total expression cost'' rule chooses the
|
---|
| 735 | proper common type. The odd-looking ``highest argument conversion cost'' rule ensures that, when
|
---|
| 736 | unary expressions must be converted, conversions of function results are preferred to conversion of
|
---|
| 737 | function arguments: \lstinline$(double)-i$ will be preferred to \lstinline$-(double)i$.
|
---|
| 738 |
|
---|
| 739 | The ``least polymorphic'' rule reduces the number of polymorphic function calls, since such
|
---|
| 740 | functions are presumably more expensive than monomorphic functions and since the more specific
|
---|
[2fc0e5c] | 741 | function is presumably more appropriate. It also gives preference to monomorphic values (such as the
|
---|
| 742 | \lstinline$int$ \lstinline$0$) over polymorphic values (such as the \Index{null pointer}
|
---|
| 743 | \lstinline$0$\use{0}). However, interpretations that call polymorphic functions are preferred to
|
---|
| 744 | interpretations that perform unsafe conversions, because those conversions potentially lose accuracy
|
---|
| 745 | or violate strong typing.
|
---|
[f60d997] | 746 |
|
---|
| 747 | There are two notable differences between \CFA's overload resolution rules and the rules for
|
---|
| 748 | {\CC} defined in \cite{c++}. First, the result type of a function plays a role. In {\CC}, a
|
---|
| 749 | function call must be completely resolved based on the arguments to the call in most circumstances.
|
---|
| 750 | In \CFA, a function call may have several interpretations, each with a different result type, and
|
---|
| 751 | the interpretations of the containing context choose among them. Second, safe conversions are used
|
---|
| 752 | to choose among interpretations of all sorts of functions; in {\CC}, the ``usual arithmetic
|
---|
| 753 | conversions'' are a separate set of rules that apply only to the built-in operators.
|
---|
| 754 | \end{rationale}
|
---|
| 755 |
|
---|
| 756 | Expressions involving certain operators\index{operator identifiers} are considered to be equivalent
|
---|
| 757 | to function calls. A transformation from ``operator'' syntax to ``function call'' syntax is defined
|
---|
| 758 | by \define{rewrite rules}. Each operator has a set of predefined functions that overload its
|
---|
| 759 | identifier. Overload resolution determines which member of the set is executed in a given
|
---|
[2fc0e5c] | 760 | expression. The functions have \Index{internal linkage} and are implicitly declared with \Index{file
|
---|
| 761 | scope}. The predefined functions and rewrite rules are discussed below for each of these
|
---|
| 762 | operators.
|
---|
[f60d997] | 763 | \begin{rationale}
|
---|
| 764 | Predefined functions and constants have internal linkage because that simplifies optimization in
|
---|
| 765 | traditional compile-and-link environments. For instance, ``\lstinline$an_int + an_int$'' is
|
---|
| 766 | equivalent to ``\lstinline$?+?(an_int, an_int)$''. If integer addition has not been redefined in
|
---|
| 767 | the current scope, a compiler can generate code to perform the addition directly. If predefined
|
---|
| 768 | functions had external linkage, this optimization would be difficult.
|
---|
| 769 | \end{rationale}
|
---|
| 770 |
|
---|
| 771 | \begin{rationale}
|
---|
| 772 | Since each subsection describes the interpretations of an expression in terms of the interpretations
|
---|
| 773 | of its subexpressions, this chapter can be taken as describing an overload resolution algorithm that
|
---|
| 774 | uses one bottom-up pass over an expression tree. Such an algorithm was first described (for Ada) by
|
---|
[2fc0e5c] | 775 | Baker~\cite{Bak:overload}. It is extended here to handle polymorphic functions and arithmetic
|
---|
| 776 | conversions. The overload resolution rules and the predefined functions have been chosen so that, in
|
---|
| 777 | programs that do not introduce overloaded declarations, expressions will have the same meaning in C
|
---|
| 778 | and in \CFA.
|
---|
[f60d997] | 779 | \end{rationale}
|
---|
| 780 |
|
---|
| 781 | \begin{rationale}
|
---|
| 782 | Expression syntax is quoted from the {\c11} standard. The syntax itself defines the precedence and
|
---|
| 783 | associativity of operators. The sections are arranged in decreasing order of precedence, with all
|
---|
| 784 | operators in a section having the same precedence.
|
---|
| 785 | \end{rationale}
|
---|
| 786 |
|
---|
[2fc0e5c] | 787 |
|
---|
[f60d997] | 788 | \subsection{Primary expressions}
|
---|
[2fc0e5c] | 789 |
|
---|
[f60d997] | 790 | \begin{syntax}
|
---|
| 791 | \lhs{primary-expression}
|
---|
| 792 | \rhs \nonterm{identifier}
|
---|
| 793 | \rhs \nonterm{constant}
|
---|
| 794 | \rhs \nonterm{string-literal}
|
---|
| 795 | \rhs \lstinline$($ \nonterm{expression} \lstinline$)$
|
---|
| 796 | \rhs \nonterm{generic-selection}
|
---|
| 797 | \end{syntax}
|
---|
| 798 |
|
---|
[bfee448] | 799 | \predefined
|
---|
[f60d997] | 800 | \begin{lstlisting}
|
---|
| 801 | const int 1;@\use{1}@
|
---|
| 802 | const int 0;@\use{0}@
|
---|
| 803 | forall( dtype DT ) DT *const 0;
|
---|
| 804 | forall( ftype FT ) FT *const 0;
|
---|
| 805 | \end{lstlisting}
|
---|
| 806 |
|
---|
| 807 | \semantics
|
---|
[2fc0e5c] | 808 | The \Index{valid interpretation} of an \nonterm{identifier} are given by the visible\index{visible}
|
---|
| 809 | declarations of the identifier.
|
---|
[f60d997] | 810 |
|
---|
| 811 | A \nonterm{constant} or \nonterm{string-literal} has one valid interpretation, which has the type
|
---|
| 812 | and value defined by {\c11}. The predefined integer identifiers ``\lstinline$1$'' and
|
---|
| 813 | ``\lstinline$0$'' have the integer values 1 and 0, respectively. The other two predefined
|
---|
| 814 | ``\lstinline$0$'' identifiers are bound to polymorphic pointer values that, when
|
---|
| 815 | specialized\index{specialization} with a data type or function type respectively, produce a null
|
---|
| 816 | pointer of that type.
|
---|
| 817 |
|
---|
| 818 | A parenthesised expression has the same interpretations as the contained \nonterm{expression}.
|
---|
| 819 |
|
---|
| 820 | \examples
|
---|
[a188b16] | 821 | The expression \lstinline$(void *)0$\use{0} specializes the (polymorphic) null pointer to a null
|
---|
[f60d997] | 822 | pointer to \lstinline$void$. \lstinline$(const void *)0$ does the same, and also uses a safe
|
---|
| 823 | conversion from \lstinline$void *$ to \lstinline$const void *$. In each case, the null pointer
|
---|
| 824 | conversion is better\index{best valid interpretations} than the unsafe conversion of the integer
|
---|
| 825 | \lstinline$0$ to a pointer.
|
---|
| 826 |
|
---|
| 827 | \begin{rationale}
|
---|
| 828 | Note that the predefined identifiers have addresses.
|
---|
| 829 |
|
---|
| 830 | \CFA does not have C's concept of ``null pointer constants'', which are not typed values but
|
---|
| 831 | special strings of tokens. The C token ``\lstinline$0$'' is an expression of type \lstinline$int$
|
---|
| 832 | with the value ``zero'', and it \emph{also} is a null pointer constant. Similarly,
|
---|
| 833 | ``\lstinline$(void *)0$ is an expression of type \lstinline$(void *)$ whose value is a null pointer,
|
---|
| 834 | and it also is a null pointer constant. However, in C, ``\lstinline$(void *)(void *)0$'' is
|
---|
| 835 | \emph{not} a null pointer constant, even though it is null-valued, a pointer, and constant! The
|
---|
| 836 | semantics of C expressions contain many special cases to deal with subexpressions that are null
|
---|
| 837 | pointer constants.
|
---|
| 838 |
|
---|
| 839 | \CFA handles these cases through overload resolution. The declaration
|
---|
| 840 | \begin{lstlisting}
|
---|
| 841 | forall( dtype DT ) DT *const 0;
|
---|
| 842 | \end{lstlisting}
|
---|
| 843 | means that \lstinline$0$ is a polymorphic object, and contains a value that can have \emph{any}
|
---|
| 844 | pointer-to-object type or pointer-to-incomplete type. The only such value is the null pointer.
|
---|
| 845 | Therefore the type \emph{alone} is enough to identify a null pointer. Where C defines an operator
|
---|
| 846 | with a special case for the null pointer constant, \CFA defines predefined functions with a
|
---|
| 847 | polymorphic object parameter.
|
---|
| 848 | \end{rationale}
|
---|
| 849 |
|
---|
[2fc0e5c] | 850 |
|
---|
[f60d997] | 851 | \subsubsection{Generic selection}
|
---|
[2fc0e5c] | 852 |
|
---|
[f60d997] | 853 | \constraints The best interpretation of the controlling expression shall be
|
---|
| 854 | unambiguous\index{ambiguous interpretation}, and shall have type compatible with at most one of the
|
---|
| 855 | types named in its generic association list. If a generic selection has no \lstinline$default$
|
---|
| 856 | generic association, the best interpretation of its controlling expression shall have type
|
---|
| 857 | compatible with exactly one of the types named in its generic association list.
|
---|
| 858 |
|
---|
| 859 | \semantics
|
---|
| 860 | A generic selection has the same interpretations as its result expression.
|
---|
| 861 |
|
---|
| 862 |
|
---|
| 863 | \subsection{Postfix operators}
|
---|
| 864 |
|
---|
| 865 | \begin{syntax}
|
---|
| 866 | \lhs{postfix-expression}
|
---|
| 867 | \rhs \nonterm{primary-expression}
|
---|
| 868 | \rhs \nonterm{postfix-expression} \lstinline$[$ \nonterm{expression} \lstinline$]$
|
---|
| 869 | \rhs \nonterm{postfix-expression} \lstinline$($
|
---|
| 870 | \nonterm{argument-expression-list}\opt \lstinline$)$
|
---|
| 871 | \rhs \nonterm{postfix-expression} \lstinline$.$ \nonterm{identifier}
|
---|
| 872 | \rhs \nonterm{postfix-expression} \lstinline$->$ \nonterm{identifier}
|
---|
| 873 | \rhs \nonterm{postfix-expression} \lstinline$++$
|
---|
| 874 | \rhs \nonterm{postfix-expression} \lstinline$--$
|
---|
| 875 | \rhs \lstinline$($ \nonterm{type-name} \lstinline$)$ \lstinline${$ \nonterm{initializer-list} \lstinline$}$
|
---|
| 876 | \rhs \lstinline$($ \nonterm{type-name} \lstinline$)$ \lstinline${$ \nonterm{initializer-list} \lstinline$,$ \lstinline$}$
|
---|
| 877 | \lhs{argument-expression-list}
|
---|
| 878 | \rhs \nonterm{assignment-expression}
|
---|
| 879 | \rhs \nonterm{argument-expression-list} \lstinline$,$
|
---|
| 880 | \nonterm{assignment-expression}
|
---|
| 881 | \end{syntax}
|
---|
| 882 |
|
---|
| 883 | \rewriterules
|
---|
| 884 | \begin{lstlisting}
|
---|
| 885 | a[b] @\rewrite@ ?[?]( b, a ) // if a has integer type */@\use{?[?]}@
|
---|
| 886 | a[b] @\rewrite@ ?[?]( a, b ) // otherwise
|
---|
| 887 | a( ${\em arguments }$ ) @\rewrite@ ?()( a, ${\em arguments} )$@\use{?()}@
|
---|
| 888 | a++ @\rewrite@ ?++(&( a ))@\use{?++}@
|
---|
| 889 | a-- @\rewrite@ ?--(&( a ))@\use{?--}@
|
---|
| 890 | \end{lstlisting}
|
---|
| 891 |
|
---|
[2fc0e5c] | 892 |
|
---|
[f60d997] | 893 | \subsubsection{Array subscripting}
|
---|
[2fc0e5c] | 894 |
|
---|
[bfee448] | 895 | \predefined
|
---|
[f60d997] | 896 | \begin{lstlisting}
|
---|
| 897 | forall( type T ) lvalue T ?[?]( T *, ptrdiff_t );@\use{ptrdiff_t}@
|
---|
| 898 | forall( type T ) lvalue _Atomic T ?[?]( _Atomic T *, ptrdiff_t );
|
---|
| 899 | forall( type T ) lvalue const T ?[?]( const T *, ptrdiff_t );
|
---|
| 900 | forall( type T ) lvalue restrict T ?[?]( restrict T *, ptrdiff_t );
|
---|
| 901 | forall( type T ) lvalue volatile T ?[?]( volatile T *, ptrdiff_t );
|
---|
| 902 | forall( type T ) lvalue _Atomic const T ?[?]( _Atomic const T *, ptrdiff_t );
|
---|
| 903 | forall( type T ) lvalue _Atomic restrict T ?[?]( _Atomic restrict T *, ptrdiff_t );
|
---|
| 904 | forall( type T ) lvalue _Atomic volatile T ?[?]( _Atomic volatile T *, ptrdiff_t );
|
---|
| 905 | forall( type T ) lvalue const restrict T ?[?]( const restrict T *, ptrdiff_t );
|
---|
| 906 | forall( type T ) lvalue const volatile T ?[?]( const volatile T *, ptrdiff_t );
|
---|
| 907 | forall( type T ) lvalue restrict volatile T ?[?]( restrict volatile T *, ptrdiff_t );
|
---|
| 908 | forall( type T ) lvalue _Atomic const restrict T ?[?]( _Atomic const restrict T *, ptrdiff_t );
|
---|
| 909 | forall( type T ) lvalue _Atomic const volatile T ?[?]( _Atomic const volatile T *, ptrdiff_t );
|
---|
| 910 | forall( type T ) lvalue _Atomic restrict volatile T ?[?]( _Atomic restrict volatile T *, ptrdiff_t );
|
---|
| 911 | forall( type T ) lvalue const restrict volatile T ?[?]( const restrict volatile T *, ptrdiff_t );
|
---|
| 912 | forall( type T ) lvalue _Atomic const restrict volatile T ?[?]( _Atomic const restrict volatile T *, ptrdiff_t );
|
---|
| 913 | \end{lstlisting}
|
---|
| 914 | \semantics
|
---|
| 915 | The interpretations of subscript expressions are the interpretations of the corresponding function
|
---|
| 916 | call expressions.
|
---|
| 917 | \begin{rationale}
|
---|
| 918 | C defines subscripting as pointer arithmetic in a way that makes \lstinline$a[i]$ and
|
---|
| 919 | \lstinline$i[a]$ equivalent. \CFA provides the equivalence through a rewrite rule to reduce the
|
---|
| 920 | number of overloadings of \lstinline$?[?]$.
|
---|
| 921 |
|
---|
| 922 | Subscript expressions are rewritten as function calls that pass the first parameter by value. This
|
---|
| 923 | is somewhat unfortunate, since array-like types tend to be large. The alternative is to use the
|
---|
| 924 | rewrite rule ``\lstinline$a[b]$ \rewrite \lstinline$?[?](&(a), b)$''. However, C semantics forbid
|
---|
| 925 | this approach: the \lstinline$a$ in ``\lstinline$a[b]$'' can be an arbitrary pointer value, which
|
---|
| 926 | does not have an address.
|
---|
| 927 |
|
---|
| 928 | The repetitive form of the predefined identifiers shows up a deficiency\index{deficiencies!pointers
|
---|
| 929 | to qualified types} of \CFA's type system. Type qualifiers are not included in type values, so
|
---|
| 930 | polymorphic functions that take pointers to arbitrary types often come in one flavor for each
|
---|
| 931 | possible qualification of the pointed-at type.
|
---|
| 932 | \end{rationale}
|
---|
| 933 |
|
---|
| 934 |
|
---|
| 935 | \subsubsection{Function calls}
|
---|
| 936 |
|
---|
| 937 | \semantics
|
---|
| 938 | A \define{function designator} is an interpretation of an expression that has function type. The
|
---|
| 939 | \nonterm{postfix-expression} in a function call may have some interpretations that are function
|
---|
| 940 | designators and some that are not.
|
---|
| 941 |
|
---|
| 942 | For those interpretations of the \nonterm{postfix-expression} that are not function designators, the
|
---|
| 943 | expression is rewritten and becomes a call of a function named ``\lstinline$?()$''. The valid
|
---|
| 944 | interpretations of the rewritten expression are determined in the manner described below.
|
---|
| 945 |
|
---|
| 946 | Each combination of function designators and argument interpretations is considered. For those
|
---|
[2fc0e5c] | 947 | interpretations of the \nonterm{postfix-expression} that are \Index{monomorphic function}
|
---|
| 948 | designators, the combination has a \Index{valid interpretation} if the function designator accepts
|
---|
| 949 | the number of arguments given, and each argument interpretation matches the corresponding explicit
|
---|
| 950 | parameter:
|
---|
[f60d997] | 951 | \begin{itemize}
|
---|
| 952 | \item
|
---|
| 953 | if the argument corresponds to a parameter in the function designator's prototype, the argument
|
---|
| 954 | interpretation must have the same type as the corresponding parameter, or be implicitly convertible
|
---|
| 955 | to the parameter's type
|
---|
| 956 | \item
|
---|
| 957 | if the function designator's type does not include a prototype or if the argument corresponds to
|
---|
[2fc0e5c] | 958 | ``\lstinline$...$'' in a prototype, a \Index{default argument promotion} is applied to it.
|
---|
[f60d997] | 959 | \end{itemize}
|
---|
| 960 | The type of the valid interpretation is the return type of the function designator.
|
---|
| 961 |
|
---|
| 962 | For those combinations where the interpretation of the \nonterm{postfix-expression} is a
|
---|
[2fc0e5c] | 963 | \Index{polymorphic function} designator and the function designator accepts the number of arguments
|
---|
| 964 | given, there shall be at least one set of \define{implicit argument}s for the implicit parameters
|
---|
| 965 | such that
|
---|
[f60d997] | 966 | \begin{itemize}
|
---|
| 967 | \item
|
---|
[2fc0e5c] | 968 | If the declaration of the implicit parameter uses \Index{type-class} \lstinline$type$\use{type}, the
|
---|
| 969 | implicit argument must be an object type; if it uses \lstinline$dtype$, the implicit argument must
|
---|
| 970 | be an object type or an incomplete type; and if it uses \lstinline$ftype$, the implicit argument
|
---|
| 971 | must be a function type.
|
---|
[f60d997] | 972 |
|
---|
| 973 | \item
|
---|
| 974 | if an explicit parameter's type uses any implicit parameters, then the corresponding explicit
|
---|
[2fc0e5c] | 975 | argument must have a type that is (or can be safely converted\index{safe conversion} to) the type
|
---|
[f60d997] | 976 | produced by substituting the implicit arguments for the implicit parameters in the explicit
|
---|
| 977 | parameter type.
|
---|
| 978 |
|
---|
| 979 | \item
|
---|
| 980 | the remaining explicit arguments must match the remaining explicit parameters, as described for
|
---|
| 981 | monomorphic function designators.
|
---|
| 982 |
|
---|
| 983 | \item
|
---|
[2fc0e5c] | 984 | for each \Index{assertion parameter} in the function designator's type, there must be an object or
|
---|
| 985 | function with the same identifier that is visible at the call site and whose type is compatible with
|
---|
| 986 | or can be specialized to the type of the assertion declaration.
|
---|
[f60d997] | 987 | \end{itemize}
|
---|
| 988 | There is a valid interpretation for each such set of implicit parameters. The type of each valid
|
---|
| 989 | interpretation is the return type of the function designator with implicit parameter values
|
---|
| 990 | substituted for the implicit arguments.
|
---|
| 991 |
|
---|
| 992 | A valid interpretation is ambiguous\index{ambiguous interpretation} if the function designator or
|
---|
| 993 | any of the argument interpretations is ambiguous.
|
---|
| 994 |
|
---|
| 995 | Every valid interpretation whose return type is not compatible with any other valid interpretation's
|
---|
| 996 | return type is an interpretation of the function call expression.
|
---|
| 997 |
|
---|
| 998 | Every set of valid interpretations that have mutually compatible\index{compatible type} result types
|
---|
| 999 | also produces an interpretation of the function call expression. The type of the interpretation is
|
---|
[2fc0e5c] | 1000 | the \Index{composite type} of the types of the valid interpretations, and the value of the
|
---|
| 1001 | interpretation is that of the \Index{best valid interpretation}.
|
---|
[f60d997] | 1002 | \begin{rationale}
|
---|
| 1003 | One desirable property of a polymorphic programming language is \define{generalizability}: the
|
---|
| 1004 | ability to replace an abstraction with a more general but equivalent abstraction without requiring
|
---|
| 1005 | changes in any of the uses of the original\cite{Cormack90}. For instance, it should be possible to
|
---|
| 1006 | replace a function ``\lstinline$int f( int );$'' with ``\lstinline$forall( type T ) T f( T );$''
|
---|
| 1007 | without affecting any calls of \lstinline$f$.
|
---|
| 1008 |
|
---|
| 1009 | \CFA\index{deficiencies!generalizability} does not fully possess this property, because
|
---|
[2fc0e5c] | 1010 | \Index{unsafe conversion} are not done when arguments are passed to polymorphic parameters.
|
---|
| 1011 | Consider
|
---|
[f60d997] | 1012 | \begin{lstlisting}
|
---|
| 1013 | float g( float, float );
|
---|
| 1014 | int i;
|
---|
| 1015 | float f;
|
---|
| 1016 | double d;
|
---|
| 1017 | f = g( f, f ); // (1)
|
---|
| 1018 | f = g( i, f ); // (2) (safe conversion to float)
|
---|
| 1019 | f = g( d, f ); // (3) (unsafe conversion to float)
|
---|
| 1020 | \end{lstlisting}
|
---|
| 1021 | If \lstinline$g$ was replaced by ``\lstinline$forall( type T ) T g( T, T );$'', the first and second
|
---|
| 1022 | calls would be unaffected, but the third would change: \lstinline$f$ would be converted to
|
---|
| 1023 | \lstinline$double$, and the result would be a \lstinline$double$.
|
---|
| 1024 |
|
---|
| 1025 | Another example is the function ``\lstinline$void h( int *);$''. This function can be passed a
|
---|
| 1026 | \lstinline$void *$ argument, but the generalization ``\lstinline$forall( type T ) void h( T *);$''
|
---|
| 1027 | can not. In this case, \lstinline$void$ is not a valid value for \lstinline$T$ because it is not an
|
---|
| 1028 | object type. If unsafe conversions were allowed, \lstinline$T$ could be inferred to be \emph{any}
|
---|
| 1029 | object type, which is undesirable.
|
---|
| 1030 | \end{rationale}
|
---|
| 1031 |
|
---|
| 1032 | \examples
|
---|
| 1033 | A function called ``\lstinline$?()$'' might be part of a numerical differentiation package.
|
---|
| 1034 | \begin{lstlisting}
|
---|
| 1035 | extern type Derivative;
|
---|
| 1036 | extern double ?()( Derivative, double );
|
---|
| 1037 | extern Derivative derivative_of( double (*f)( double ) );
|
---|
| 1038 | extern double sin( double );
|
---|
| 1039 |
|
---|
| 1040 | Derivative sin_dx = derivative_of( sin );
|
---|
| 1041 | double d;
|
---|
| 1042 | d = sin_dx( 12.9 );
|
---|
| 1043 | \end{lstlisting}
|
---|
| 1044 | Here, the only interpretation of \lstinline$sin_dx$ is as an object of type \lstinline$Derivative$.
|
---|
| 1045 | For that interpretation, the function call is treated as ``\lstinline$?()( sin_dx, 12.9 )$''.
|
---|
| 1046 | \begin{lstlisting}
|
---|
| 1047 | int f( long ); // (1)
|
---|
| 1048 | int f( int, int ); // (2)
|
---|
| 1049 | int f( int *); // (3)
|
---|
| 1050 |
|
---|
| 1051 | int i = f( 5 ); // calls (1)
|
---|
| 1052 | \end{lstlisting}
|
---|
| 1053 | Function (1) provides a valid interpretation of ``\lstinline$f( 5 )$'', using an implicit
|
---|
| 1054 | \lstinline$int$ to \lstinline$long$ conversion. The other functions do not, since the second
|
---|
| 1055 | requires two arguments, and since there is no implicit conversion from \lstinline$int$ to
|
---|
| 1056 | \lstinline$int *$ that could be used with the third function.
|
---|
| 1057 |
|
---|
| 1058 | \begin{lstlisting}
|
---|
| 1059 | forall( type T ) T h( T );
|
---|
| 1060 | double d = h( 1.5 );
|
---|
| 1061 | \end{lstlisting}
|
---|
| 1062 | ``\lstinline$1.5$'' is a \lstinline$double$ constant, so \lstinline$T$ is inferred to be
|
---|
| 1063 | \lstinline$double$, and the result of the function call is a \lstinline$double$.
|
---|
| 1064 |
|
---|
| 1065 | \begin{lstlisting}
|
---|
| 1066 | forall( type T, type U ) void g( T, U ); // (4)
|
---|
| 1067 | forall( type T ) void g( T, T ); // (5)
|
---|
| 1068 | forall( type T ) void g( T, long ); // (6)
|
---|
| 1069 | void g( long, long ); // (7)
|
---|
| 1070 | double d;
|
---|
| 1071 | int i;
|
---|
| 1072 | int *p;
|
---|
| 1073 |
|
---|
| 1074 | g( d, d ); // calls (5)
|
---|
| 1075 | g( d, i ); // calls (6)
|
---|
| 1076 | g( i, i ); // calls (7)
|
---|
| 1077 | g( i, p ); // calls (4)
|
---|
| 1078 | \end{lstlisting}
|
---|
| 1079 | The first call has valid interpretations for all four versions of \lstinline$g$. (6) and (7) are
|
---|
| 1080 | discarded because they involve unsafe \lstinline$double$-to-\lstinline$long$ conversions. (5) is
|
---|
| 1081 | chosen because it is less polymorphic than (4).
|
---|
| 1082 |
|
---|
| 1083 | For the second call, (7) is again discarded. Of the remaining interpretations for (4), (5), and (6)
|
---|
| 1084 | (with \lstinline$i$ converted to \lstinline$long$), (6) is chosen because it is the least
|
---|
| 1085 | polymorphic.
|
---|
| 1086 |
|
---|
| 1087 | The third call has valid interpretations for all of the functions; (7) is chosen since it is not
|
---|
| 1088 | polymorphic at all.
|
---|
| 1089 |
|
---|
| 1090 | The fourth call has no interpretation for (5), because its arguments must have compatible type. (4)
|
---|
| 1091 | is chosen because it does not involve unsafe conversions.
|
---|
| 1092 | \begin{lstlisting}
|
---|
| 1093 | forall( type T ) T min( T, T );
|
---|
| 1094 | double max( double, double );
|
---|
| 1095 | context min_max( T ) {@\impl{min_max}@
|
---|
| 1096 | T min( T, T );
|
---|
| 1097 | T max( T, T );
|
---|
| 1098 | }
|
---|
| 1099 | forall( type U | min_max( U ) ) void shuffle( U, U );
|
---|
| 1100 | shuffle(9, 10);
|
---|
| 1101 | \end{lstlisting}
|
---|
| 1102 | The only possibility for \lstinline$U$ is \lstinline$double$, because that is the type used in the
|
---|
| 1103 | only visible \lstinline$max$ function. 9 and 10 must be converted to \lstinline$double$, and
|
---|
| 1104 | \lstinline$min$ must be specialized with \lstinline$T$ bound to \lstinline$double$.
|
---|
| 1105 | \begin{lstlisting}
|
---|
| 1106 | extern void q( int ); // (8)
|
---|
| 1107 | extern void q( void * ); // (9)
|
---|
| 1108 | extern void r();
|
---|
| 1109 | q( 0 );
|
---|
| 1110 | r( 0 );
|
---|
| 1111 | \end{lstlisting}
|
---|
[2fc0e5c] | 1112 | The \lstinline$int 0$ could be passed to (8), or the \lstinline$(void *)$ \Index{specialization} of
|
---|
| 1113 | the null pointer\index{null pointer} \lstinline$0$\use{0} could be passed to (9). The former is
|
---|
| 1114 | chosen because the \lstinline$int$ \lstinline$0$ is \Index{less polymorphic}. For
|
---|
| 1115 | the same reason, \lstinline$int$ \lstinline$0$ is passed to \lstinline$r()$, even though it has
|
---|
| 1116 | \emph{no} declared parameter types.
|
---|
[f60d997] | 1117 |
|
---|
| 1118 |
|
---|
| 1119 | \subsubsection{Structure and union members}
|
---|
| 1120 |
|
---|
| 1121 | \semantics In the member selection expression ``\lstinline$s$.\lstinline$m$'', there shall be at
|
---|
| 1122 | least one interpretation of \lstinline$s$ whose type is a structure type or union type containing a
|
---|
| 1123 | member named \lstinline$m$. If two or more interpretations of \lstinline$s$ have members named
|
---|
[2fc0e5c] | 1124 | \lstinline$m$ with mutually compatible types, then the expression has an \Index{ambiguous
|
---|
| 1125 | interpretation} whose type is the composite type of the types of the members. If an interpretation
|
---|
| 1126 | of \lstinline$s$ has a member \lstinline$m$ whose type is not compatible with any other
|
---|
| 1127 | \lstinline$s$'s \lstinline$m$, then the expression has an interpretation with the member's type. The
|
---|
| 1128 | expression has no other interpretations.
|
---|
[f60d997] | 1129 |
|
---|
| 1130 | The expression ``\lstinline$p->m$'' has the same interpretations as the expression
|
---|
| 1131 | ``\lstinline$(*p).m$''.
|
---|
| 1132 |
|
---|
| 1133 |
|
---|
| 1134 | \subsubsection{Postfix increment and decrement operators}
|
---|
| 1135 |
|
---|
[bfee448] | 1136 | \predefined
|
---|
[f60d997] | 1137 | \begin{lstlisting}
|
---|
| 1138 | _Bool ?++( volatile _Bool * ),
|
---|
| 1139 | ?++( _Atomic volatile _Bool * );
|
---|
| 1140 | char ?++( volatile char * ),
|
---|
| 1141 | ?++( _Atomic volatile char * );
|
---|
| 1142 | signed char ?++( volatile signed char * ),
|
---|
| 1143 | ?++( _Atomic volatile signed char * );
|
---|
| 1144 | unsigned char ?++( volatile signed char * ),
|
---|
| 1145 | ?++( _Atomic volatile signed char * );
|
---|
| 1146 | short int ?++( volatile short int * ),
|
---|
| 1147 | ?++( _Atomic volatile short int * );
|
---|
| 1148 | unsigned short int ?++( volatile unsigned short int * ),
|
---|
| 1149 | ?++( _Atomic volatile unsigned short int * );
|
---|
| 1150 | int ?++( volatile int * ),
|
---|
| 1151 | ?++( _Atomic volatile int * );
|
---|
| 1152 | unsigned int ?++( volatile unsigned int * ),
|
---|
| 1153 | ?++( _Atomic volatile unsigned int * );
|
---|
| 1154 | long int ?++( volatile long int * ),
|
---|
| 1155 | ?++( _Atomic volatile long int * );
|
---|
| 1156 | long unsigned int ?++( volatile long unsigned int * ),
|
---|
| 1157 | ?++( _Atomic volatile long unsigned int * );
|
---|
| 1158 | long long int ?++( volatile long long int * ),
|
---|
| 1159 | ?++( _Atomic volatile long long int * );
|
---|
| 1160 | long long unsigned ?++( volatile long long unsigned int * ),
|
---|
| 1161 | ?++( _Atomic volatile long long unsigned int * );
|
---|
| 1162 | float ?++( volatile float * ),
|
---|
| 1163 | ?++( _Atomic volatile float * );
|
---|
| 1164 | double ?++( volatile double * ),
|
---|
| 1165 | ?++( _Atomic volatile double * );
|
---|
| 1166 | long double ?++( volatile long double * ),
|
---|
| 1167 | ?++( _Atomic volatile long double * );
|
---|
| 1168 |
|
---|
| 1169 | forall( type T ) T * ?++( T * restrict volatile * ),
|
---|
| 1170 | * ?++( T * _Atomic restrict volatile * );
|
---|
| 1171 |
|
---|
| 1172 | forall( type T ) _Atomic T * ?++( _Atomic T * restrict volatile * ),
|
---|
| 1173 | * ?++( _Atomic T * _Atomic restrict volatile * );
|
---|
| 1174 |
|
---|
| 1175 | forall( type T ) const T * ?++( const T * restrict volatile * ),
|
---|
| 1176 | * ?++( const T * _Atomic restrict volatile * );
|
---|
| 1177 |
|
---|
| 1178 | forall( type T ) volatile T * ?++( volatile T * restrict volatile * ),
|
---|
| 1179 | * ?++( volatile T * _Atomic restrict volatile * );
|
---|
| 1180 |
|
---|
| 1181 | forall( type T ) restrict T * ?++( restrict T * restrict volatile * ),
|
---|
| 1182 | * ?++( restrict T * _Atomic restrict volatile * );
|
---|
| 1183 |
|
---|
| 1184 | forall( type T ) _Atomic const T * ?++( _Atomic const T * restrict volatile * ),
|
---|
| 1185 | * ?++( _Atomic const T * _Atomic restrict volatile * );
|
---|
| 1186 |
|
---|
| 1187 | forall( type T ) _Atomic restrict T * ?++( _Atomic restrict T * restrict volatile * ),
|
---|
| 1188 | * ?++( _Atomic restrict T * _Atomic restrict volatile * );
|
---|
| 1189 |
|
---|
| 1190 | forall( type T ) _Atomic volatile T * ?++( _Atomic volatile T * restrict volatile * ),
|
---|
| 1191 | * ?++( _Atomic volatile T * _Atomic restrict volatile * );
|
---|
| 1192 |
|
---|
| 1193 | forall( type T ) const restrict T * ?++( const restrict T * restrict volatile * ),
|
---|
| 1194 | * ?++( const restrict T * _Atomic restrict volatile * );
|
---|
| 1195 |
|
---|
| 1196 | forall( type T ) const volatile T * ?++( const volatile T * restrict volatile * ),
|
---|
| 1197 | * ?++( const volatile T * _Atomic restrict volatile * );
|
---|
| 1198 |
|
---|
| 1199 | forall( type T ) restrict volatile T * ?++( restrict volatile T * restrict volatile * ),
|
---|
| 1200 | * ?++( restrict volatile T * _Atomic restrict volatile * );
|
---|
| 1201 |
|
---|
| 1202 | forall( type T ) _Atomic const restrict T * ?++( _Atomic const restrict T * restrict volatile * ),
|
---|
| 1203 | * ?++( _Atomic const restrict T * _Atomic restrict volatile * );
|
---|
| 1204 |
|
---|
| 1205 | forall( type T ) _Atomic const volatile T * ?++( _Atomic const volatile T * restrict volatile * ),
|
---|
| 1206 | * ?++( _Atomic const volatile T * _Atomic restrict volatile * );
|
---|
| 1207 |
|
---|
| 1208 | forall( type T ) _Atomic restrict volatile T * ?++( _Atomic restrict volatile T * restrict volatile * ),
|
---|
| 1209 | * ?++( _Atomic restrict volatile T * _Atomic restrict volatile * );
|
---|
| 1210 |
|
---|
| 1211 | forall( type T ) const restrict volatile T * ?++( const restrict volatile T * restrict volatile * ),
|
---|
| 1212 | * ?++( const restrict volatile T * _Atomic restrict volatile * );
|
---|
| 1213 |
|
---|
| 1214 | forall( type T ) _Atomic const restrict volatile T * ?++( _Atomic const restrict volatile T * restrict volatile * ),
|
---|
| 1215 | * ?++( _Atomic const restrict volatile T * _Atomic restrict volatile * );
|
---|
| 1216 |
|
---|
| 1217 | _Bool ?--( volatile _Bool * ),
|
---|
| 1218 | ?--( _Atomic volatile _Bool * );
|
---|
| 1219 | char ?--( volatile char * ),
|
---|
| 1220 | ?--( _Atomic volatile char * );
|
---|
| 1221 | signed char ?--( volatile signed char * ),
|
---|
| 1222 | ?--( _Atomic volatile signed char * );
|
---|
| 1223 | unsigned char ?--( volatile signed char * ),
|
---|
| 1224 | ?--( _Atomic volatile signed char * );
|
---|
| 1225 | short int ?--( volatile short int * ),
|
---|
| 1226 | ?--( _Atomic volatile short int * );
|
---|
| 1227 | unsigned short int ?--( volatile unsigned short int * ),
|
---|
| 1228 | ?--( _Atomic volatile unsigned short int * );
|
---|
| 1229 | int ?--( volatile int * ),
|
---|
| 1230 | ?--( _Atomic volatile int * );
|
---|
| 1231 | unsigned int ?--( volatile unsigned int * ),
|
---|
| 1232 | ?--( _Atomic volatile unsigned int * );
|
---|
| 1233 | long int ?--( volatile long int * ),
|
---|
| 1234 | ?--( _Atomic volatile long int * );
|
---|
| 1235 | long unsigned int ?--( volatile long unsigned int * ),
|
---|
| 1236 | ?--( _Atomic volatile long unsigned int * );
|
---|
| 1237 | long long int ?--( volatile long long int * ),
|
---|
| 1238 | ?--( _Atomic volatile long long int * );
|
---|
| 1239 | long long unsigned ?--( volatile long long unsigned int * ),
|
---|
| 1240 | ?--( _Atomic volatile long long unsigned int * );
|
---|
| 1241 | float ?--( volatile float * ),
|
---|
| 1242 | ?--( _Atomic volatile float * );
|
---|
| 1243 | double ?--( volatile double * ),
|
---|
| 1244 | ?--( _Atomic volatile double * );
|
---|
| 1245 | long double ?--( volatile long double * ),
|
---|
| 1246 | ?--( _Atomic volatile long double * );
|
---|
| 1247 |
|
---|
| 1248 | forall( type T ) T * ?--( T * restrict volatile * ),
|
---|
| 1249 | * ?--( T * _Atomic restrict volatile * );
|
---|
| 1250 |
|
---|
| 1251 | forall( type T ) _Atomic T * ?--( _Atomic T * restrict volatile * ),
|
---|
| 1252 | * ?--( _Atomic T * _Atomic restrict volatile * );
|
---|
| 1253 |
|
---|
| 1254 | forall( type T ) const T * ?--( const T * restrict volatile * ),
|
---|
| 1255 | * ?--( const T * _Atomic restrict volatile * );
|
---|
| 1256 |
|
---|
| 1257 | forall( type T ) volatile T * ?--( volatile T * restrict volatile * ),
|
---|
| 1258 | * ?--( volatile T * _Atomic restrict volatile * );
|
---|
| 1259 |
|
---|
| 1260 | forall( type T ) restrict T * ?--( restrict T * restrict volatile * ),
|
---|
| 1261 | * ?--( restrict T * _Atomic restrict volatile * );
|
---|
| 1262 |
|
---|
| 1263 | forall( type T ) _Atomic const T * ?--( _Atomic const T * restrict volatile * ),
|
---|
| 1264 | * ?--( _Atomic const T * _Atomic restrict volatile * );
|
---|
| 1265 |
|
---|
| 1266 | forall( type T ) _Atomic restrict T * ?--( _Atomic restrict T * restrict volatile * ),
|
---|
| 1267 | * ?--( _Atomic restrict T * _Atomic restrict volatile * );
|
---|
| 1268 |
|
---|
| 1269 | forall( type T ) _Atomic volatile T * ?--( _Atomic volatile T * restrict volatile * ),
|
---|
| 1270 | * ?--( _Atomic volatile T * _Atomic restrict volatile * );
|
---|
| 1271 |
|
---|
| 1272 | forall( type T ) const restrict T * ?--( const restrict T * restrict volatile * ),
|
---|
| 1273 | * ?--( const restrict T * _Atomic restrict volatile * );
|
---|
| 1274 |
|
---|
| 1275 | forall( type T ) const volatile T * ?--( const volatile T * restrict volatile * ),
|
---|
| 1276 | * ?--( const volatile T * _Atomic restrict volatile * );
|
---|
| 1277 |
|
---|
| 1278 | forall( type T ) restrict volatile T * ?--( restrict volatile T * restrict volatile * ),
|
---|
| 1279 | * ?--( restrict volatile T * _Atomic restrict volatile * );
|
---|
| 1280 |
|
---|
| 1281 | forall( type T ) _Atomic const restrict T * ?--( _Atomic const restrict T * restrict volatile * ),
|
---|
| 1282 | * ?--( _Atomic const restrict T * _Atomic restrict volatile * );
|
---|
| 1283 |
|
---|
| 1284 | forall( type T ) _Atomic const volatile T * ?--( _Atomic const volatile T * restrict volatile * ),
|
---|
| 1285 | * ?--( _Atomic const volatile T * _Atomic restrict volatile * );
|
---|
| 1286 |
|
---|
| 1287 | forall( type T ) _Atomic restrict volatile T * ?--( _Atomic restrict volatile T * restrict volatile * ),
|
---|
| 1288 | * ?--( _Atomic restrict volatile T * _Atomic restrict volatile * );
|
---|
| 1289 |
|
---|
| 1290 | forall( type T ) const restrict volatile T * ?--( const restrict volatile T * restrict volatile * ),
|
---|
| 1291 | * ?--( const restrict volatile T * _Atomic restrict volatile * );
|
---|
| 1292 |
|
---|
| 1293 | forall( type T ) _Atomic const restrict volatile T * ?--( _Atomic const restrict volatile T * restrict volatile * ),
|
---|
| 1294 | * ?--( _Atomic const restrict volatile T * _Atomic restrict volatile * );
|
---|
| 1295 | \end{lstlisting}
|
---|
| 1296 | For every extended integer type \lstinline$X$ there exist
|
---|
| 1297 | % Don't use predefined: keep this out of prelude.cf.
|
---|
| 1298 | \begin{lstlisting}
|
---|
| 1299 | X ?++( volatile X * ), ?++( _Atomic volatile X * ),
|
---|
[2fc0e5c] | 1300 | ?--( volatile X * ), ?--( _Atomic volatile X * );
|
---|
[f60d997] | 1301 | \end{lstlisting}
|
---|
| 1302 | For every complete enumerated type \lstinline$E$ there exist
|
---|
| 1303 | % Don't use predefined: keep this out of prelude.cf.
|
---|
| 1304 | \begin{lstlisting}
|
---|
| 1305 | E ?++( volatile E * ), ?++( _Atomic volatile E * ),
|
---|
[2fc0e5c] | 1306 | ?--( volatile E * ), ?--( _Atomic volatile E * );
|
---|
[f60d997] | 1307 | \end{lstlisting}
|
---|
| 1308 |
|
---|
| 1309 | \begin{rationale}
|
---|
| 1310 | Note that ``\lstinline$++$'' and ``\lstinline$--$'' are rewritten as function calls that are given a
|
---|
| 1311 | pointer to that operand. (This is true of all operators that modify an operand.) As Hamish Macdonald
|
---|
| 1312 | has pointed out, this forces the modified operand of such expressions to be an lvalue. This
|
---|
| 1313 | partially enforces the C semantic rule that such operands must be \emph{modifiable} lvalues.
|
---|
| 1314 | \end{rationale}
|
---|
| 1315 |
|
---|
| 1316 | \begin{rationale}
|
---|
| 1317 | In C, a semantic rule requires that pointer operands of increment and decrement be pointers to
|
---|
| 1318 | object types. Hence, \lstinline$void *$ objects cannot be incremented. In \CFA, the restriction
|
---|
| 1319 | follows from the use of a \lstinline$type$ parameter in the predefined function definitions, as
|
---|
| 1320 | opposed to \lstinline$dtype$, since only object types can be inferred arguments corresponding to the
|
---|
| 1321 | type parameter \lstinline$T$.
|
---|
| 1322 | \end{rationale}
|
---|
| 1323 |
|
---|
| 1324 | \semantics
|
---|
| 1325 | First, each interpretation of the operand of an increment or decrement expression is considered
|
---|
| 1326 | separately. For each interpretation that is a bit-field or is declared with the
|
---|
[2fc0e5c] | 1327 | \lstinline$register$\index{register@{\lstinline$register$}} \index{Itorage-class specifier}, the
|
---|
| 1328 | expression has one valid interpretation, with the type of the operand, and the expression is
|
---|
| 1329 | ambiguous if the operand is.
|
---|
[f60d997] | 1330 |
|
---|
| 1331 | For the remaining interpretations, the expression is rewritten, and the interpretations of the
|
---|
| 1332 | expression are the interpretations of the corresponding function call. Finally, all interpretations
|
---|
| 1333 | of the expression produced for the different interpretations of the operand are combined to produce
|
---|
| 1334 | the interpretations of the expression as a whole; where interpretations have compatible result
|
---|
| 1335 | types, the best interpretations are selected in the manner described for function call expressions.
|
---|
| 1336 |
|
---|
| 1337 | \examples
|
---|
| 1338 | \begin{lstlisting}
|
---|
| 1339 | volatile short int vs; vs++; // rewritten as ?++( &(vs) )
|
---|
| 1340 | short int s; s++;
|
---|
| 1341 | const short int cs; cs++;
|
---|
| 1342 | _Atomic short int as; as++;
|
---|
| 1343 | \end{lstlisting}
|
---|
| 1344 | \begin{sloppypar}
|
---|
| 1345 | Since \lstinline$&(vs)$ has type \lstinline$volatile short int *$, the best valid interpretation of
|
---|
| 1346 | \lstinline$vs++$ calls the \lstinline$?++$ function with the \lstinline$volatile short *$ parameter.
|
---|
| 1347 | \lstinline$s++$ does the same, applying the safe conversion from \lstinline$short int *$ to
|
---|
| 1348 | \lstinline$volatile short int *$. Note that there is no conversion that adds an \lstinline$_Atomic$
|
---|
| 1349 | qualifier, so the \lstinline$_Atomic volatile short int$ overloading does not provide a valid
|
---|
| 1350 | interpretation.
|
---|
| 1351 | \end{sloppypar}
|
---|
| 1352 |
|
---|
| 1353 | There is no safe conversion from \lstinline$const short int *$ to \lstinline$volatile short int *$,
|
---|
| 1354 | and no \lstinline$?++$ function that accepts a \lstinline$const *$ parameter, so \lstinline$cs++$
|
---|
| 1355 | has no valid interpretations.
|
---|
| 1356 |
|
---|
| 1357 | The best valid interpretation of \lstinline$as++$ calls the \lstinline$short ?++$ function with the
|
---|
| 1358 | \lstinline$_Atomic volatile short int *$ parameter, applying a safe conversion to add the
|
---|
| 1359 | \lstinline$volatile$ qualifier.
|
---|
| 1360 |
|
---|
| 1361 | \begin{lstlisting}
|
---|
| 1362 | char * const restrict volatile * restrict volatile pqpc; pqpc++
|
---|
| 1363 | char * * restrict volatile ppc; ppc++;
|
---|
| 1364 | \end{lstlisting}
|
---|
| 1365 | Since \lstinline$&(pqpc)$ has type \lstinline$char * const restrict volatile * restrict volatile *$,
|
---|
| 1366 | the best valid interpretation of \lstinline$pqpc++$ calls the polymorphic \lstinline$?++$ function
|
---|
| 1367 | with the \lstinline$const restrict volatile T * restrict volatile *$ parameter, inferring
|
---|
| 1368 | \lstinline$T$ to be \lstinline$char *$.
|
---|
| 1369 |
|
---|
| 1370 | \begin{sloppypar}
|
---|
| 1371 | \lstinline$ppc++$ calls the same function, again inferring \lstinline$T$ to be \lstinline$char *$,
|
---|
| 1372 | and using the safe conversions from \lstinline$T$ to \lstinline$T const restrict volatile$.
|
---|
| 1373 | \end{sloppypar}
|
---|
| 1374 |
|
---|
| 1375 | \begin{rationale}
|
---|
| 1376 | Increment and decrement expressions show up a deficiency of \CFA's type system. There is no such
|
---|
| 1377 | thing as a pointer to a register object or bit-field\index{deficiencies!pointers to bit-fields}.
|
---|
| 1378 | Therefore, there is no way to define a function that alters them, and hence no way to define
|
---|
| 1379 | increment and decrement functions for them. As a result, the semantics of increment and decrement
|
---|
| 1380 | expressions must treat them specially. This holds true for all of the operators that may modify
|
---|
| 1381 | such objects.
|
---|
| 1382 | \end{rationale}
|
---|
| 1383 |
|
---|
| 1384 | \begin{rationale}
|
---|
| 1385 | The polymorphic overloadings for pointer increment and decrement can be understood by considering
|
---|
| 1386 | increasingly complex types.
|
---|
| 1387 | \begin{enumerate}
|
---|
| 1388 | \item
|
---|
| 1389 | ``\lstinline$char * p; p++;$''. The argument to \lstinline$?++$ has type \lstinline$char * *$, and
|
---|
| 1390 | the result has type \lstinline$char *$. The expression would be valid if \lstinline$?++$ were
|
---|
| 1391 | declared by
|
---|
| 1392 | \begin{lstlisting}
|
---|
| 1393 | forall( type T ) T * ?++( T * * );
|
---|
| 1394 | \end{lstlisting}
|
---|
| 1395 | with \lstinline$T$ inferred to be \lstinline$char$.
|
---|
| 1396 |
|
---|
| 1397 | \item
|
---|
| 1398 | ``\lstinline$char *restrict volatile qp; qp++$''. The result again has type \lstinline$char *$, but
|
---|
| 1399 | the argument now has type \lstinline$char *restrict volatile *$, so it cannot be passed to the
|
---|
| 1400 | hypothetical function declared in point 1. Hence the actual predefined function is
|
---|
| 1401 | \begin{lstlisting}
|
---|
| 1402 | forall( type T ) T * ?++( T * restrict volatile * );
|
---|
| 1403 | \end{lstlisting}
|
---|
| 1404 | which also accepts a \lstinline$char * *$ argument, because of the safe conversions that add
|
---|
| 1405 | \lstinline$volatile$ and \lstinline$restrict$ qualifiers. (The parameter is not const-qualified, so
|
---|
| 1406 | constant pointers cannot be incremented.)
|
---|
| 1407 |
|
---|
| 1408 | \item
|
---|
| 1409 | ``\lstinline$char *_Atomic ap; ap++$''. The result again has type \lstinline$char *$, but no safe
|
---|
| 1410 | conversion adds an \lstinline$_Atomic$ qualifier, so the function in point 2 is not applicable. A
|
---|
| 1411 | separate overloading of \lstinline$?++$ is required.
|
---|
| 1412 |
|
---|
| 1413 | \item
|
---|
| 1414 | ``\lstinline$char const volatile * pq; pq++$''. Here the result has type
|
---|
| 1415 | \lstinline$char const volatile *$, so a new overloading is needed:
|
---|
| 1416 | \begin{lstlisting}
|
---|
| 1417 | forall( type T ) T const volatile * ?++( T const volatile *restrict volatile * );
|
---|
| 1418 | \end{lstlisting}
|
---|
| 1419 | One overloading is needed for each combination of qualifiers in the pointed-at
|
---|
| 1420 | type\index{deficiencies!pointers to qualified types}.
|
---|
| 1421 |
|
---|
| 1422 | \item
|
---|
| 1423 | ``\lstinline$float *restrict * prp; prp++$''. The \lstinline$restrict$ qualifier is handled just
|
---|
| 1424 | like \lstinline$const$ and \lstinline$volatile$ in the previous case:
|
---|
| 1425 | \begin{lstlisting}
|
---|
| 1426 | forall( type T ) T restrict * ?++( T restrict *restrict volatile * );
|
---|
| 1427 | \end{lstlisting}
|
---|
| 1428 | with \lstinline$T$ inferred to be \lstinline$float *$. This looks odd, because {\c11} contains a
|
---|
| 1429 | constraint that requires restrict-qualified types to be pointer-to-object types, and \lstinline$T$
|
---|
| 1430 | is not syntactically a pointer type. \CFA loosens the constraint.
|
---|
| 1431 | \end{enumerate}
|
---|
| 1432 | \end{rationale}
|
---|
| 1433 |
|
---|
| 1434 |
|
---|
| 1435 | \subsubsection{Compound literals}
|
---|
| 1436 |
|
---|
| 1437 | \semantics
|
---|
| 1438 | A compound literal has one interpretation, with the type given by the \nonterm{type-name} of the
|
---|
| 1439 | compound literal.
|
---|
| 1440 |
|
---|
| 1441 |
|
---|
| 1442 | \subsection{Unary operators}
|
---|
| 1443 |
|
---|
| 1444 | \begin{syntax}
|
---|
| 1445 | \lhs{unary-expression}
|
---|
| 1446 | \rhs \nonterm{postfix-expression}
|
---|
| 1447 | \rhs \lstinline$++$ \nonterm{unary-expression}
|
---|
| 1448 | \rhs \lstinline$--$ \nonterm{unary-expression}
|
---|
| 1449 | \rhs \nonterm{unary-operator} \nonterm{cast-expression}
|
---|
| 1450 | \rhs \lstinline$sizeof$ \nonterm{unary-expression}
|
---|
| 1451 | \rhs \lstinline$sizeof$ \lstinline$($ \nonterm{type-name} \lstinline$)$
|
---|
| 1452 | \lhs{unary-operator} one of \rhs \lstinline$&$ \lstinline$*$ \lstinline$+$ \lstinline$-$ \lstinline$~$ \lstinline$!$
|
---|
| 1453 | \end{syntax}
|
---|
| 1454 |
|
---|
| 1455 | \rewriterules
|
---|
| 1456 | \begin{lstlisting}
|
---|
| 1457 | *a @\rewrite@ *?(a) @\use{*?}@
|
---|
| 1458 | +a @\rewrite@ +?(a) @\use{+?}@
|
---|
| 1459 | -a @\rewrite@ -?(a) @\use{-?}@
|
---|
| 1460 | ~a @\rewrite@ ~?(a) @\use{~?}@
|
---|
| 1461 | !a @\rewrite@ !?(a) @\use{"!?}@
|
---|
| 1462 | ++a @\rewrite@ ++?(&(a)) @\use{++?}@
|
---|
| 1463 | --a @\rewrite@ --?(&(a)) @\use{--?}@
|
---|
| 1464 | \end{lstlisting}
|
---|
| 1465 |
|
---|
| 1466 |
|
---|
| 1467 | \subsubsection{Prefix increment and decrement operators}
|
---|
| 1468 |
|
---|
[bfee448] | 1469 | \predefined
|
---|
[f60d997] | 1470 | \begin{lstlisting}
|
---|
| 1471 | _Bool ++?( volatile _Bool * ),
|
---|
| 1472 | ++?( _Atomic volatile _Bool * );
|
---|
| 1473 | char ++?( volatile char * ),
|
---|
| 1474 | ++?( _Atomic volatile char * );
|
---|
| 1475 | signed char ++?( volatile signed char * ),
|
---|
| 1476 | ++?( _Atomic volatile signed char * );
|
---|
| 1477 | unsigned char ++?( volatile signed char * ),
|
---|
| 1478 | ++?( _Atomic volatile signed char * );
|
---|
| 1479 | short int ++?( volatile short int * ),
|
---|
| 1480 | ++?( _Atomic volatile short int * );
|
---|
| 1481 | unsigned short int ++?( volatile unsigned short int * ),
|
---|
| 1482 | ++?( _Atomic volatile unsigned short int * );
|
---|
| 1483 | int ++?( volatile int * ),
|
---|
| 1484 | ++?( _Atomic volatile int * );
|
---|
| 1485 | unsigned int ++?( volatile unsigned int * ),
|
---|
| 1486 | ++?( _Atomic volatile unsigned int * );
|
---|
| 1487 | long int ++?( volatile long int * ),
|
---|
| 1488 | ++?( _Atomic volatile long int * );
|
---|
| 1489 | long unsigned int ++?( volatile long unsigned int * ),
|
---|
| 1490 | ++?( _Atomic volatile long unsigned int * );
|
---|
| 1491 | long long int ++?( volatile long long int * ),
|
---|
| 1492 | ++?( _Atomic volatile long long int * );
|
---|
| 1493 | long long unsigned ++?( volatile long long unsigned int * ),
|
---|
| 1494 | ++?( _Atomic volatile long long unsigned int * );
|
---|
| 1495 | float ++?( volatile float * ),
|
---|
| 1496 | ++?( _Atomic volatile float * );
|
---|
| 1497 | double ++?( volatile double * ),
|
---|
| 1498 | ++?( _Atomic volatile double * );
|
---|
| 1499 | long double ++?( volatile long double * ),
|
---|
| 1500 | ++?( _Atomic volatile long double * );
|
---|
| 1501 |
|
---|
| 1502 | forall( type T ) T * ++?( T * restrict volatile * ),
|
---|
| 1503 | * ++?( T * _Atomic restrict volatile * );
|
---|
| 1504 |
|
---|
| 1505 | forall( type T ) _Atomic T * ++?( _Atomic T * restrict volatile * ),
|
---|
| 1506 | * ++?( _Atomic T * _Atomic restrict volatile * );
|
---|
| 1507 |
|
---|
| 1508 | forall( type T ) const T * ++?( const T * restrict volatile * ),
|
---|
| 1509 | * ++?( const T * _Atomic restrict volatile * );
|
---|
| 1510 |
|
---|
| 1511 | forall( type T ) volatile T * ++?( volatile T * restrict volatile * ),
|
---|
| 1512 | * ++?( volatile T * _Atomic restrict volatile * );
|
---|
| 1513 |
|
---|
| 1514 | forall( type T ) restrict T * ++?( restrict T * restrict volatile * ),
|
---|
| 1515 | * ++?( restrict T * _Atomic restrict volatile * );
|
---|
| 1516 |
|
---|
| 1517 | forall( type T ) _Atomic const T * ++?( _Atomic const T * restrict volatile * ),
|
---|
| 1518 | * ++?( _Atomic const T * _Atomic restrict volatile * );
|
---|
| 1519 |
|
---|
| 1520 | forall( type T ) _Atomic volatile T * ++?( _Atomic volatile T * restrict volatile * ),
|
---|
| 1521 | * ++?( _Atomic volatile T * _Atomic restrict volatile * );
|
---|
| 1522 |
|
---|
| 1523 | forall( type T ) _Atomic restrict T * ++?( _Atomic restrict T * restrict volatile * ),
|
---|
| 1524 | * ++?( _Atomic restrict T * _Atomic restrict volatile * );
|
---|
| 1525 |
|
---|
| 1526 | forall( type T ) const volatile T * ++?( const volatile T * restrict volatile * ),
|
---|
| 1527 | * ++?( const volatile T * _Atomic restrict volatile * );
|
---|
| 1528 |
|
---|
| 1529 | forall( type T ) const restrict T * ++?( const restrict T * restrict volatile * ),
|
---|
| 1530 | * ++?( const restrict T * _Atomic restrict volatile * );
|
---|
| 1531 |
|
---|
| 1532 | forall( type T ) restrict volatile T * ++?( restrict volatile T * restrict volatile * ),
|
---|
| 1533 | * ++?( restrict volatile T * _Atomic restrict volatile * );
|
---|
| 1534 |
|
---|
| 1535 | forall( type T ) _Atomic const volatile T * ++?( _Atomic const volatile T * restrict volatile * ),
|
---|
| 1536 | * ++?( _Atomic const volatile T * _Atomic restrict volatile * );
|
---|
| 1537 |
|
---|
| 1538 | forall( type T ) _Atomic const restrict T * ++?( _Atomic const restrict T * restrict volatile * ),
|
---|
| 1539 | * ++?( _Atomic const restrict T * _Atomic restrict volatile * );
|
---|
| 1540 |
|
---|
| 1541 | forall( type T ) _Atomic restrict volatile T * ++?( _Atomic restrict volatile T * restrict volatile * ),
|
---|
| 1542 | * ++?( _Atomic restrict volatile T * _Atomic restrict volatile * );
|
---|
| 1543 |
|
---|
| 1544 | forall( type T ) const restrict volatile T * ++?( const restrict volatile T * restrict volatile * ),
|
---|
| 1545 | * ++?( const restrict volatile T * _Atomic restrict volatile * );
|
---|
| 1546 |
|
---|
| 1547 | forall( type T ) _Atomic const restrict volatile T * ++?( _Atomic const restrict volatile T * restrict volatile * ),
|
---|
| 1548 | * ++?( _Atomic const restrict volatile T * _Atomic restrict volatile * );
|
---|
| 1549 |
|
---|
| 1550 | _Bool --?( volatile _Bool * ),
|
---|
| 1551 | --?( _Atomic volatile _Bool * );
|
---|
| 1552 | char --?( volatile char * ),
|
---|
| 1553 | --?( _Atomic volatile char * );
|
---|
| 1554 | signed char --?( volatile signed char * ),
|
---|
| 1555 | --?( _Atomic volatile signed char * );
|
---|
| 1556 | unsigned char --?( volatile signed char * ),
|
---|
| 1557 | --?( _Atomic volatile signed char * );
|
---|
| 1558 | short int --?( volatile short int * ),
|
---|
| 1559 | --?( _Atomic volatile short int * );
|
---|
| 1560 | unsigned short int --?( volatile unsigned short int * ),
|
---|
| 1561 | --?( _Atomic volatile unsigned short int * );
|
---|
| 1562 | int --?( volatile int * ),
|
---|
| 1563 | --?( _Atomic volatile int * );
|
---|
| 1564 | unsigned int --?( volatile unsigned int * ),
|
---|
| 1565 | --?( _Atomic volatile unsigned int * );
|
---|
| 1566 | long int --?( volatile long int * ),
|
---|
| 1567 | --?( _Atomic volatile long int * );
|
---|
| 1568 | long unsigned int --?( volatile long unsigned int * ),
|
---|
| 1569 | --?( _Atomic volatile long unsigned int * );
|
---|
| 1570 | long long int --?( volatile long long int * ),
|
---|
| 1571 | --?( _Atomic volatile long long int * );
|
---|
| 1572 | long long unsigned --?( volatile long long unsigned int * ),
|
---|
| 1573 | --?( _Atomic volatile long long unsigned int * );
|
---|
| 1574 | float --?( volatile float * ),
|
---|
| 1575 | --?( _Atomic volatile float * );
|
---|
| 1576 | double --?( volatile double * ),
|
---|
| 1577 | --?( _Atomic volatile double * );
|
---|
| 1578 | long double --?( volatile long double * ),
|
---|
| 1579 | --?( _Atomic volatile long double * );
|
---|
| 1580 |
|
---|
| 1581 | forall( type T ) T * --?( T * restrict volatile * ),
|
---|
| 1582 | * --?( T * _Atomic restrict volatile * );
|
---|
| 1583 |
|
---|
| 1584 | forall( type T ) _Atomic T * --?( _Atomic T * restrict volatile * ),
|
---|
| 1585 | * --?( _Atomic T * _Atomic restrict volatile * );
|
---|
| 1586 |
|
---|
| 1587 | forall( type T ) const T * --?( const T * restrict volatile * ),
|
---|
| 1588 | * --?( const T * _Atomic restrict volatile * );
|
---|
| 1589 |
|
---|
| 1590 | forall( type T ) volatile T * --?( volatile T * restrict volatile * ),
|
---|
| 1591 | * --?( volatile T * _Atomic restrict volatile * );
|
---|
| 1592 |
|
---|
| 1593 | forall( type T ) restrict T * --?( restrict T * restrict volatile * ),
|
---|
| 1594 | * --?( restrict T * _Atomic restrict volatile * );
|
---|
| 1595 |
|
---|
| 1596 | forall( type T ) _Atomic const T * --?( _Atomic const T * restrict volatile * ),
|
---|
| 1597 | * --?( _Atomic const T * _Atomic restrict volatile * );
|
---|
| 1598 |
|
---|
| 1599 | forall( type T ) _Atomic volatile T * --?( _Atomic volatile T * restrict volatile * ),
|
---|
| 1600 | * --?( _Atomic volatile T * _Atomic restrict volatile * );
|
---|
| 1601 |
|
---|
| 1602 | forall( type T ) _Atomic restrict T * --?( _Atomic restrict T * restrict volatile * ),
|
---|
| 1603 | * --?( _Atomic restrict T * _Atomic restrict volatile * );
|
---|
| 1604 |
|
---|
| 1605 | forall( type T ) const volatile T * --?( const volatile T * restrict volatile * ),
|
---|
| 1606 | * --?( const volatile T * _Atomic restrict volatile * );
|
---|
| 1607 |
|
---|
| 1608 | forall( type T ) const restrict T * --?( const restrict T * restrict volatile * ),
|
---|
| 1609 | * --?( const restrict T * _Atomic restrict volatile * );
|
---|
| 1610 |
|
---|
| 1611 | forall( type T ) restrict volatile T * --?( restrict volatile T * restrict volatile * ),
|
---|
| 1612 | * --?( restrict volatile T * _Atomic restrict volatile * );
|
---|
| 1613 |
|
---|
| 1614 | forall( type T ) _Atomic const volatile T * --?( _Atomic const volatile T * restrict volatile * ),
|
---|
| 1615 | * --?( _Atomic const volatile T * _Atomic restrict volatile * );
|
---|
| 1616 |
|
---|
| 1617 | forall( type T ) _Atomic const restrict T * --?( _Atomic const restrict T * restrict volatile * ),
|
---|
| 1618 | * --?( _Atomic const restrict T * _Atomic restrict volatile * );
|
---|
| 1619 |
|
---|
| 1620 | forall( type T ) _Atomic restrict volatile T * --?( _Atomic restrict volatile T * restrict volatile * ),
|
---|
| 1621 | * --?( _Atomic restrict volatile T * _Atomic restrict volatile * );
|
---|
| 1622 |
|
---|
| 1623 | forall( type T ) const restrict volatile T * --?( const restrict volatile T * restrict volatile * ),
|
---|
| 1624 | * --?( const restrict volatile T * _Atomic restrict volatile * );
|
---|
| 1625 |
|
---|
| 1626 | forall( type T ) _Atomic const restrict volatile T * --?( _Atomic const restrict volatile T * restrict volatile * ),
|
---|
| 1627 | * --?( _Atomic const restrict volatile T * _Atomic restrict volatile * );
|
---|
| 1628 | \end{lstlisting}
|
---|
| 1629 | For every extended integer type \lstinline$X$ there exist
|
---|
| 1630 | % Don't use predefined: keep this out of prelude.cf.
|
---|
| 1631 | \begin{lstlisting}
|
---|
| 1632 | X ++?( volatile X * ),
|
---|
| 1633 | ++?( _Atomic volatile X * ),
|
---|
| 1634 | --?( volatile X * ),
|
---|
| 1635 | --?( _Atomic volatile X * );
|
---|
| 1636 | \end{lstlisting}
|
---|
| 1637 | For every complete enumerated type \lstinline$E$ there exist
|
---|
| 1638 | % Don't use predefined: keep this out of prelude.cf.
|
---|
| 1639 | \begin{lstlisting}
|
---|
| 1640 | E ++?( volatile E * ),
|
---|
| 1641 | ++?( _Atomic volatile E * ),
|
---|
| 1642 | ?--( volatile E * ),
|
---|
| 1643 | ?--( _Atomic volatile E * );
|
---|
| 1644 | \end{lstlisting}
|
---|
| 1645 |
|
---|
| 1646 | \semantics
|
---|
| 1647 | The interpretations of prefix increment and decrement expressions are
|
---|
| 1648 | determined in the same way as the interpretations of postfix increment and
|
---|
| 1649 | decrement expressions.
|
---|
| 1650 |
|
---|
| 1651 |
|
---|
| 1652 | \subsubsection{Address and indirection operators}
|
---|
| 1653 |
|
---|
[bfee448] | 1654 | \predefined
|
---|
[f60d997] | 1655 | \begin{lstlisting}
|
---|
| 1656 | forall( type T ) lvalue T *?( T * );
|
---|
| 1657 | forall( type T ) _Atomic lvalue T *?( _Atomic T * );
|
---|
| 1658 | forall( type T ) const lvalue T *?( const T * );
|
---|
| 1659 | forall( type T ) volatile lvalue T *?( volatile T * );
|
---|
| 1660 | forall( type T ) restrict lvalue T *?( restrict T * );
|
---|
| 1661 | forall( type T ) _Atomic const lvalue T *?( _Atomic const T * );
|
---|
| 1662 | forall( type T ) _Atomic volatile lvalue T *?( _Atomic volatile T * );
|
---|
| 1663 | forall( type T ) _Atomic restrict lvalue T *?( _Atomic restrict T * );
|
---|
| 1664 | forall( type T ) const volatile lvalue T *?( const volatile T * );
|
---|
| 1665 | forall( type T ) const restrict lvalue T *?( const restrict T * );
|
---|
| 1666 | forall( type T ) restrict volatile lvalue T *?( restrict volatile T * );
|
---|
| 1667 | forall( type T ) _Atomic const volatile lvalue T *?( _Atomic const volatile T * );
|
---|
| 1668 | forall( type T ) _Atomic const restrict lvalue T *?( _Atomic const restrict T * );
|
---|
| 1669 | forall( type T ) _Atomic restrict volatile lvalue T *?( _Atomic restrict volatile T * );
|
---|
| 1670 | forall( type T ) const restrict volatile lvalue T *?( const restrict volatile T * );
|
---|
| 1671 | forall( type T ) _Atomic const restrict volatile lvalue T *?( _Atomic const restrict volatile T * );
|
---|
| 1672 |
|
---|
| 1673 | forall( ftype FT ) FT *?( FT * );
|
---|
| 1674 | \end{lstlisting}
|
---|
| 1675 |
|
---|
| 1676 | \constraints
|
---|
| 1677 | The operand of the unary ``\lstinline$&$'' operator shall have exactly one
|
---|
[2fc0e5c] | 1678 | \Index{interpretation}\index{ambiguous interpretation}, which shall be unambiguous.
|
---|
[f60d997] | 1679 |
|
---|
| 1680 | \semantics
|
---|
| 1681 | The ``\lstinline$&$'' expression has one interpretation which is of type \lstinline$T *$, where
|
---|
| 1682 | \lstinline$T$ is the type of the operand.
|
---|
| 1683 |
|
---|
| 1684 | The interpretations of an indirection expression are the interpretations of the corresponding
|
---|
| 1685 | function call.
|
---|
| 1686 |
|
---|
| 1687 |
|
---|
| 1688 | \subsubsection{Unary arithmetic operators}
|
---|
| 1689 |
|
---|
[bfee448] | 1690 | \predefined
|
---|
[f60d997] | 1691 | \begin{lstlisting}
|
---|
| 1692 | int
|
---|
| 1693 | +?( int ),
|
---|
| 1694 | -?( int ),
|
---|
| 1695 | ~?( int );
|
---|
| 1696 | unsigned int
|
---|
| 1697 | +?( unsigned int ),
|
---|
| 1698 | -?( unsigned int ),
|
---|
| 1699 | ~?( unsigned int );
|
---|
| 1700 | long int
|
---|
| 1701 | +?( long int ),
|
---|
| 1702 | -?( long int ),
|
---|
| 1703 | ~?( long int );
|
---|
| 1704 | long unsigned int
|
---|
| 1705 | +?( long unsigned int ),
|
---|
| 1706 | -?( long unsigned int ),
|
---|
| 1707 | ~?( long unsigned int );
|
---|
| 1708 | long long int
|
---|
| 1709 | +?( long long int ),
|
---|
| 1710 | -?( long long int ),
|
---|
| 1711 | ~?( long long int );
|
---|
| 1712 | long long unsigned int
|
---|
| 1713 | +?( long long unsigned int ),
|
---|
| 1714 | -?( long long unsigned int ),
|
---|
| 1715 | ~?( long long unsigned int );
|
---|
| 1716 | float
|
---|
| 1717 | +?( float ),
|
---|
| 1718 | -?( float );
|
---|
| 1719 | double
|
---|
| 1720 | +?( double ),
|
---|
| 1721 | -?( double );
|
---|
| 1722 | long double
|
---|
| 1723 | +?( long double ),
|
---|
| 1724 | -?( long double );
|
---|
| 1725 | _Complex float
|
---|
| 1726 | +?( _Complex float ),
|
---|
| 1727 | -?( _Complex float );
|
---|
| 1728 | _Complex double
|
---|
| 1729 | +?( _Complex double ),
|
---|
| 1730 | -?( _Complex double );
|
---|
| 1731 | _Complex long double
|
---|
| 1732 | +?( _Complex long double ),
|
---|
| 1733 | -?( _Complex long double );
|
---|
| 1734 |
|
---|
| 1735 | int !?( int ),
|
---|
| 1736 | !?( unsigned int ),
|
---|
| 1737 | !?( long ),
|
---|
| 1738 | !?( long unsigned int ),
|
---|
| 1739 | !?( long long int ),
|
---|
| 1740 | !?( long long unsigned int ),
|
---|
| 1741 | !?( float ),
|
---|
| 1742 | !?( double ),
|
---|
| 1743 | !?( long double ),
|
---|
| 1744 | !?( _Complex float ),
|
---|
| 1745 | !?( _Complex double ),
|
---|
| 1746 | !?( _Complex long double );
|
---|
| 1747 |
|
---|
| 1748 | forall( dtype DT ) int !?( const restrict volatile DT * );
|
---|
| 1749 | forall( dtype DT ) int !?( _Atomic const restrict volatile DT * );
|
---|
| 1750 | forall( ftype FT ) int !?( FT * );
|
---|
| 1751 | \end{lstlisting}
|
---|
[2fc0e5c] | 1752 | For every extended integer type \lstinline$X$ with \Index{integer conversion rank} greater than the
|
---|
| 1753 | rank of \lstinline$int$ there exist
|
---|
[f60d997] | 1754 | % Don't use predefined: keep this out of prelude.cf.
|
---|
| 1755 | \begin{lstlisting}
|
---|
| 1756 | X +?( X ), -?( X ), ~?( X );
|
---|
| 1757 | int !?( X );
|
---|
| 1758 | \end{lstlisting}
|
---|
| 1759 |
|
---|
| 1760 | \semantics
|
---|
| 1761 | The interpretations of a unary arithmetic expression are the interpretations of the corresponding
|
---|
| 1762 | function call.
|
---|
| 1763 |
|
---|
| 1764 | \examples
|
---|
| 1765 | \begin{lstlisting}
|
---|
| 1766 | long int li;
|
---|
| 1767 | void eat_double( double );@\use{eat_double}@
|
---|
| 1768 |
|
---|
| 1769 | eat_double(-li ); // @\rewrite@ eat_double( -?( li ) );
|
---|
| 1770 | \end{lstlisting}
|
---|
| 1771 | The valid interpretations of ``\lstinline$-li$'' (assuming no extended integer types exist) are
|
---|
| 1772 | \begin{center}
|
---|
| 1773 | \begin{tabular}{llc}
|
---|
| 1774 | interpretation & result type & expression conversion cost \\
|
---|
| 1775 | \hline
|
---|
| 1776 | \lstinline$-?( (int)li )$ & \lstinline$int$ & (unsafe) \\
|
---|
| 1777 | \lstinline$-?( (unsigned)li)$ & \lstinline$unsigned int$ & (unsafe) \\
|
---|
| 1778 | \lstinline$-?( (long)li)$ & \lstinline$long$ & 0 \\
|
---|
| 1779 | \lstinline$-?( (long unsigned int)li)$ & \lstinline$long unsigned int$ & 1 \\
|
---|
| 1780 | \lstinline$-?( (long long int)li)$ & \lstinline$long long int$ & 2 \\
|
---|
| 1781 | \lstinline$-?( (long long unsigned int)li)$ & \lstinline$long long unsigned int$& 3 \\
|
---|
| 1782 | \lstinline$-?( (float)li)$ & \lstinline$float$ & 4 \\
|
---|
| 1783 | \lstinline$-?( (double)li)$ & \lstinline$double$ & 5 \\
|
---|
| 1784 | \lstinline$-?( (long double)li)$ & \lstinline$long double$ & 6 \\
|
---|
| 1785 | \lstinline$-?( (_Complex float)li)$ & \lstinline$float$ & (unsafe) \\
|
---|
| 1786 | \lstinline$-?( (_Complex double)li)$ & \lstinline$double$ & (unsafe) \\
|
---|
| 1787 | \lstinline$-?( (_Complex long double)li)$ & \lstinline$long double$ & (unsafe) \\
|
---|
| 1788 | \end{tabular}
|
---|
| 1789 | \end{center}
|
---|
| 1790 | The valid interpretations of the \lstinline$eat_double$ call, with the cost of the argument
|
---|
| 1791 | conversion and the cost of the entire expression, are
|
---|
| 1792 | \begin{center}
|
---|
| 1793 | \begin{tabular}{lcc}
|
---|
| 1794 | interpretation & argument cost & expression cost \\
|
---|
| 1795 | \hline
|
---|
| 1796 | \lstinline$eat_double( (double)-?( (int)li) )$ & 7 & (unsafe) \\
|
---|
| 1797 | \lstinline$eat_double( (double)-?( (unsigned)li) )$ & 6 & (unsafe) \\
|
---|
| 1798 | \lstinline$eat_double( (double)-?(li) )$ & 5 & \(0+5=5\) \\
|
---|
| 1799 | \lstinline$eat_double( (double)-?( (long unsigned int)li) )$ & 4 & \(1+4=5\) \\
|
---|
| 1800 | \lstinline$eat_double( (double)-?( (long long int)li) )$ & 3 & \(2+3=5\) \\
|
---|
| 1801 | \lstinline$eat_double( (double)-?( (long long unsigned int)li) )$& 2 & \(3+2=5\) \\
|
---|
| 1802 | \lstinline$eat_double( (double)-?( (float)li) )$ & 1 & \(4+1=5\) \\
|
---|
| 1803 | \lstinline$eat_double( (double)-?( (double)li) )$ & 0 & \(5+0=5\) \\
|
---|
| 1804 | \lstinline$eat_double( (double)-?( (long double)li) )$ & (unsafe) & (unsafe) \\
|
---|
| 1805 | \lstinline$eat_double( (double)-?( (_Complex float)li) )$ & (unsafe) & (unsafe) \\
|
---|
| 1806 | \lstinline$eat_double( (double)-?( (_Complex double)li) )$ & (unsafe) & (unsafe) \\
|
---|
| 1807 | \lstinline$eat_double( (double)-?( (_Complex long double)li) )$ & (unsafe) & (unsafe) \\
|
---|
| 1808 | \end{tabular}
|
---|
| 1809 | \end{center}
|
---|
| 1810 | Each has result type \lstinline$void$, so the best must be selected. The interpretations involving
|
---|
| 1811 | unsafe conversions are discarded. The remainder have equal expression conversion costs, so the
|
---|
| 1812 | ``highest argument conversion cost'' rule is invoked, and the chosen interpretation is
|
---|
| 1813 | \lstinline$eat_double( (double)-?(li) )$.
|
---|
| 1814 |
|
---|
| 1815 |
|
---|
[2fc0e5c] | 1816 | \subsubsection{The \lstinline$sizeof$ and \lstinline$_Alignof$ operators}
|
---|
[f60d997] | 1817 |
|
---|
| 1818 | \constraints
|
---|
| 1819 | The operand of \lstinline$sizeof$ or \lstinline$_Alignof$ shall not be \lstinline$type$,
|
---|
| 1820 | \lstinline$dtype$, or \lstinline$ftype$.
|
---|
| 1821 |
|
---|
| 1822 | When the \lstinline$sizeof$\use{sizeof} operator is applied to an expression, the expression shall
|
---|
[2fc0e5c] | 1823 | have exactly one \Index{interpretation}\index{ambiguous interpretation}, which shall
|
---|
[f60d997] | 1824 | be unambiguous. \semantics A \lstinline$sizeof$ or \lstinline$_Alignof$ expression has one
|
---|
| 1825 | interpretation, of type \lstinline$size_t$.
|
---|
| 1826 |
|
---|
| 1827 | When \lstinline$sizeof$ is applied to an identifier declared by a \nonterm{type-declaration} or a
|
---|
| 1828 | \nonterm{type-parameter}, it yields the size in bytes of the type that implements the operand. When
|
---|
| 1829 | the operand is an opaque type or an inferred type parameter\index{inferred parameter}, the
|
---|
| 1830 | expression is not a constant expression.
|
---|
| 1831 |
|
---|
| 1832 | When \lstinline$_Alignof$ is applied to an identifier declared by a \nonterm{type-declaration} or a
|
---|
| 1833 | \nonterm{type-parameter}, it yields the alignment requirement of the type that implements the
|
---|
| 1834 | operand. When the operand is an opaque type or an inferred type parameter\index{inferred
|
---|
| 1835 | parameter}, the expression is not a constant expression.
|
---|
| 1836 | \begin{rationale}
|
---|
| 1837 | \begin{lstlisting}
|
---|
| 1838 | type Pair = struct { int first, second; };
|
---|
| 1839 | size_t p_size = sizeof(Pair); // constant expression
|
---|
| 1840 |
|
---|
| 1841 | extern type Rational;@\use{Rational}@
|
---|
| 1842 | size_t c_size = sizeof(Rational); // non-constant expression
|
---|
| 1843 |
|
---|
| 1844 | forall(type T) T f(T p1, T p2) {
|
---|
| 1845 | size_t t_size = sizeof(T); // non-constant expression
|
---|
| 1846 | ...
|
---|
| 1847 | }
|
---|
| 1848 | \end{lstlisting}
|
---|
| 1849 | ``\lstinline$sizeof Rational$'', although not statically known, is fixed. Within \lstinline$f()$,
|
---|
| 1850 | ``\lstinline$sizeof(T)$'' is fixed for each call of \lstinline$f()$, but may vary from call to call.
|
---|
| 1851 | \end{rationale}
|
---|
| 1852 |
|
---|
[2fc0e5c] | 1853 |
|
---|
[f60d997] | 1854 | \subsection{Cast operators}
|
---|
[2fc0e5c] | 1855 |
|
---|
[f60d997] | 1856 | \begin{syntax}
|
---|
| 1857 | \lhs{cast-expression}
|
---|
| 1858 | \rhs \nonterm{unary-expression}
|
---|
| 1859 | \rhs \lstinline$($ \nonterm{type-name} \lstinline$)$ \nonterm{cast-expression}
|
---|
| 1860 | \end{syntax}
|
---|
| 1861 |
|
---|
| 1862 | \constraints
|
---|
| 1863 | The \nonterm{type-name} in a \nonterm{cast-expression} shall not be \lstinline$type$,
|
---|
| 1864 | \lstinline$dtype$, or \lstinline$ftype$.
|
---|
| 1865 |
|
---|
| 1866 | \semantics
|
---|
| 1867 |
|
---|
[2fc0e5c] | 1868 | In a \Index{cast expression} ``\lstinline$($\nonterm{type-name}\lstinline$)e$'', if
|
---|
| 1869 | \nonterm{type-name} is the type of an interpretation of \lstinline$e$, then that interpretation is
|
---|
| 1870 | the only interpretation of the cast expression; otherwise, \lstinline$e$ shall have some
|
---|
| 1871 | interpretation that can be converted to \nonterm{type-name}, and the interpretation of the cast
|
---|
| 1872 | expression is the cast of the interpretation that can be converted at the lowest cost. The cast
|
---|
| 1873 | expression's interpretation is ambiguous\index{ambiguous interpretation} if more than one
|
---|
| 1874 | interpretation can be converted at the lowest cost or if the selected interpretation is ambiguous.
|
---|
[f60d997] | 1875 |
|
---|
| 1876 | \begin{rationale}
|
---|
| 1877 | Casts can be used to eliminate ambiguity in expressions by selecting interpretations of
|
---|
| 1878 | subexpressions, and to specialize polymorphic functions and values.
|
---|
| 1879 | \end{rationale}
|
---|
| 1880 |
|
---|
[2fc0e5c] | 1881 |
|
---|
[f60d997] | 1882 | \subsection{Multiplicative operators}
|
---|
[2fc0e5c] | 1883 |
|
---|
[f60d997] | 1884 | \begin{syntax}
|
---|
| 1885 | \lhs{multiplicative-expression}
|
---|
| 1886 | \rhs \nonterm{cast-expression}
|
---|
| 1887 | \rhs \nonterm{multiplicative-expression} \lstinline$*$ \nonterm{cast-expression}
|
---|
| 1888 | \rhs \nonterm{multiplicative-expression} \lstinline$/$ \nonterm{cast-expression}
|
---|
| 1889 | \rhs \nonterm{multiplicative-expression} \lstinline$%$ \nonterm{cast-expression}
|
---|
| 1890 | \end{syntax}
|
---|
| 1891 |
|
---|
| 1892 | \rewriterules
|
---|
| 1893 | \begin{lstlisting}
|
---|
| 1894 | a * b @\rewrite@ ?*?( a, b )@\use{?*?}@
|
---|
| 1895 | a / b @\rewrite@ ?/?( a, b )@\use{?/?}@
|
---|
| 1896 | a % b @\rewrite@ ?%?( a, b )@\use{?%?}@
|
---|
| 1897 | \end{lstlisting}
|
---|
| 1898 |
|
---|
[bfee448] | 1899 | \predefined
|
---|
[f60d997] | 1900 | \begin{lstlisting}
|
---|
| 1901 | int?*?( int, int ),
|
---|
| 1902 | ?/?( int, int ),
|
---|
| 1903 | ?%?( int, int );
|
---|
| 1904 | unsigned int?*?( unsigned int, unsigned int ),
|
---|
| 1905 | ?/?( unsigned int, unsigned int ),
|
---|
| 1906 | ?%?( unsigned int, unsigned int );
|
---|
| 1907 | long int?*?( long int, long int ),
|
---|
| 1908 | ?/?( long, long ),
|
---|
| 1909 | ?%?( long, long );
|
---|
| 1910 | long unsigned int?*?( long unsigned int, long unsigned int ),
|
---|
| 1911 | ?/?( long unsigned int, long unsigned int ),
|
---|
| 1912 | ?%?( long unsigned int, long unsigned int );
|
---|
| 1913 | long long int?*?( long long int, long long int ),
|
---|
| 1914 | ?/?( long long int, long long int ),
|
---|
| 1915 | ?%?( long long int, long long int );
|
---|
| 1916 | long long unsigned int ?*?( long long unsigned int, long long unsigned int ),
|
---|
| 1917 | ?/?( long long unsigned int, long long unsigned int ),
|
---|
| 1918 | ?%?( long long unsigned int, long long unsigned int );
|
---|
| 1919 | float?*?( float, float ),
|
---|
| 1920 | ?/?( float, float );
|
---|
| 1921 | double?*?( double, double ),
|
---|
| 1922 | ?/?( double, double );
|
---|
| 1923 | long double?*?( long double, long double ),
|
---|
| 1924 | ?/?( long double, long double );
|
---|
| 1925 | _Complex float?*?( float, _Complex float ),
|
---|
| 1926 | ?/?( float, _Complex float ),
|
---|
| 1927 | ?*?( _Complex float, float ),
|
---|
| 1928 | ?/?( _Complex float, float ),
|
---|
| 1929 | ?*?( _Complex float, _Complex float ),
|
---|
| 1930 | ?/?( _Complex float, _Complex float );
|
---|
| 1931 | _Complex double?*?( double, _Complex double ),
|
---|
| 1932 | ?/?( double, _Complex double ),
|
---|
| 1933 | ?*?( _Complex double, double ),
|
---|
| 1934 | ?/?( _Complex double, double ),
|
---|
| 1935 | ?*?( _Complex double, _Complex double ),
|
---|
| 1936 | ?/?( _Complex double, _Complex double );
|
---|
| 1937 | _Complex long double?*?( long double, _Complex long double ),
|
---|
| 1938 | ?/?( long double, _Complex long double ),
|
---|
| 1939 | ?*?( _Complex long double, long double ),
|
---|
| 1940 | ?/?( _Complex long double, long double ),
|
---|
| 1941 | ?*?( _Complex long double, _Complex long double ),
|
---|
| 1942 | ?/?( _Complex long double, _Complex long double );
|
---|
| 1943 | \end{lstlisting}
|
---|
[2fc0e5c] | 1944 | For every extended integer type \lstinline$X$ with \Index{integer conversion rank} greater than the
|
---|
| 1945 | rank of \lstinline$int$ there exist
|
---|
[f60d997] | 1946 | % Don't use predefined: keep this out of prelude.cf.
|
---|
| 1947 | \begin{lstlisting}
|
---|
| 1948 | X ?*?( X ), ?/?( X ), ?%?( X );
|
---|
| 1949 | \end{lstlisting}
|
---|
| 1950 |
|
---|
| 1951 | \begin{rationale}
|
---|
[2fc0e5c] | 1952 | {\c11} does not include conversions from the \Index{real type}s to \Index{complex type}s in the
|
---|
| 1953 | \Index{usual arithmetic conversion}s. Instead it specifies conversion of the result of binary
|
---|
| 1954 | operations on arguments from mixed type domains. \CFA's predefined operators match that pattern.
|
---|
[f60d997] | 1955 | \end{rationale}
|
---|
| 1956 |
|
---|
| 1957 | \semantics
|
---|
| 1958 | The interpretations of multiplicative expressions are the interpretations of the corresponding
|
---|
| 1959 | function call.
|
---|
| 1960 |
|
---|
| 1961 | \examples
|
---|
| 1962 | \begin{lstlisting}
|
---|
| 1963 | int i;
|
---|
| 1964 | long li;
|
---|
| 1965 | void eat_double( double );@\use{eat_double}@
|
---|
| 1966 | eat_double( li % i );
|
---|
| 1967 | \end{lstlisting}
|
---|
| 1968 | ``\lstinline$li % i$'' is rewritten as ``\lstinline$?%?(li, i )$''. The valid interpretations
|
---|
| 1969 | of \lstinline$?%?(li, i )$, the cost\index{conversion cost} of converting their arguments, and
|
---|
| 1970 | the cost of converting the result to \lstinline$double$ (assuming no extended integer types are
|
---|
| 1971 | present ) are
|
---|
| 1972 | \begin{center}
|
---|
| 1973 | \begin{tabular}{lcc}
|
---|
| 1974 | interpretation & argument cost & result cost \\
|
---|
| 1975 | \hline
|
---|
| 1976 | \lstinline$ ?%?( (int)li, i )$ & (unsafe) & 6 \\
|
---|
| 1977 | \lstinline$ ?%?( (unsigned)li,(unsigned)i )$ & (unsafe) & 5 \\
|
---|
| 1978 | \lstinline$ ?%?(li,(long)i )$ & 1 & 4 \\
|
---|
| 1979 | \lstinline$ ?%?( (long unsigned)li,(long unsigned)i )$ & 3 & 3 \\
|
---|
| 1980 | \lstinline$ ?%?( (long long)li,(long long)i )$ & 5 & 2 \\
|
---|
| 1981 | \lstinline$ ?%?( (long long unsigned)li, (long long unsigned)i )$ & 7 & 1 \\
|
---|
| 1982 | \end{tabular}
|
---|
| 1983 | \end{center}
|
---|
| 1984 | The best interpretation of \lstinline$eat_double( li, i )$ is
|
---|
| 1985 | \lstinline$eat_double( (double)?%?(li, (long)i ))$, which has no unsafe conversions and the
|
---|
| 1986 | lowest total cost.
|
---|
| 1987 |
|
---|
| 1988 | \begin{rationale}
|
---|
[2fc0e5c] | 1989 | {\c11} defines most arithmetic operations to apply an \Index{integer promotion} to any argument that
|
---|
| 1990 | belongs to a type that has an \Index{integer conversion rank} less than that of \lstinline$int$.If
|
---|
| 1991 | \lstinline$s$ is a \lstinline$short int$, ``\lstinline$s *s$'' does not have type \lstinline$short int$;
|
---|
| 1992 | it is treated as ``\lstinline$( (int)s ) * ( (int)s )$'', and has type \lstinline$int$. \CFA matches
|
---|
| 1993 | that pattern; it does not predefine ``\lstinline$short ?*?( short, short )$''.
|
---|
[f60d997] | 1994 |
|
---|
| 1995 | These ``missing'' operators limit polymorphism. Consider
|
---|
| 1996 | \begin{lstlisting}
|
---|
| 1997 | forall( type T | T ?*?( T, T ) ) T square( T );
|
---|
| 1998 | short s;
|
---|
| 1999 | square( s );
|
---|
| 2000 | \end{lstlisting}
|
---|
| 2001 | Since \CFA does not define a multiplication operator for \lstinline$short int$,
|
---|
| 2002 | \lstinline$square( s )$ is treated as \lstinline$square( (int)s )$, and the result has type
|
---|
| 2003 | \lstinline$int$. This is mildly surprising, but it follows the {\c11} operator pattern.
|
---|
| 2004 |
|
---|
| 2005 | A more troubling example is
|
---|
| 2006 | \begin{lstlisting}
|
---|
| 2007 | forall( type T | ?*?( T, T ) ) T product( T[], int n );
|
---|
| 2008 | short sa[5];
|
---|
| 2009 | product( sa, 5);
|
---|
| 2010 | \end{lstlisting}
|
---|
| 2011 | This has no valid interpretations, because \CFA has no conversion from ``array of
|
---|
| 2012 | \lstinline$short int$'' to ``array of \lstinline$int$''. The alternatives in such situations
|
---|
| 2013 | include
|
---|
| 2014 | \begin{itemize}
|
---|
| 2015 | \item
|
---|
| 2016 | Defining monomorphic overloadings of \lstinline$product$ for \lstinline$short$ and the other
|
---|
| 2017 | ``small'' types.
|
---|
| 2018 | \item
|
---|
| 2019 | Defining ``\lstinline$short ?*?( short, short )$'' within the scope containing the call to
|
---|
| 2020 | \lstinline$product$.
|
---|
| 2021 | \item
|
---|
| 2022 | Defining \lstinline$product$ to take as an argument a conversion function from the ``small'' type to
|
---|
| 2023 | the operator's argument type.
|
---|
| 2024 | \end{itemize}
|
---|
| 2025 | \end{rationale}
|
---|
| 2026 |
|
---|
| 2027 |
|
---|
| 2028 | \subsection{Additive operators}
|
---|
| 2029 |
|
---|
| 2030 | \begin{syntax}
|
---|
| 2031 | \lhs{additive-expression}
|
---|
| 2032 | \rhs \nonterm{multiplicative-expression}
|
---|
| 2033 | \rhs \nonterm{additive-expression} \lstinline$+$ \nonterm{multiplicative-expression}
|
---|
| 2034 | \rhs \nonterm{additive-expression} \lstinline$-$ \nonterm{multiplicative-expression}
|
---|
| 2035 | \end{syntax}
|
---|
| 2036 |
|
---|
| 2037 | \rewriterules
|
---|
| 2038 | \begin{lstlisting}
|
---|
| 2039 | a + b @\rewrite@ ?+?( a, b )@\use{?+?}@
|
---|
| 2040 | a - b @\rewrite@ ?-?( a, b )@\use{?-?}@
|
---|
| 2041 | \end{lstlisting}
|
---|
| 2042 |
|
---|
[bfee448] | 2043 | \predefined
|
---|
[f60d997] | 2044 | \begin{lstlisting}
|
---|
| 2045 | int?+?( int, int ),
|
---|
| 2046 | ?-?( int, int );
|
---|
| 2047 | unsigned int?+?( unsigned int, unsigned int ),
|
---|
| 2048 | ?-?( unsigned int, unsigned int );
|
---|
| 2049 | long int?+?( long int, long int ),
|
---|
| 2050 | ?-?( long int, long int );
|
---|
| 2051 | long unsigned int?+?( long unsigned int, long unsigned int ),
|
---|
| 2052 | ?-?( long unsigned int, long unsigned int );
|
---|
| 2053 | long long int?+?( long long int, long long int ),
|
---|
| 2054 | ?-?( long long int, long long int );
|
---|
| 2055 | long long unsigned int ?+?( long long unsigned int, long long unsigned int ),
|
---|
| 2056 | ?-?( long long unsigned int, long long unsigned int );
|
---|
| 2057 | float?+?( float, float ),
|
---|
| 2058 | ?-?( float, float );
|
---|
| 2059 | double?+?( double, double ),
|
---|
| 2060 | ?-?( double, double );
|
---|
| 2061 | long double?+?( long double, long double ),
|
---|
| 2062 | ?-?( long double, long double );
|
---|
| 2063 | _Complex float?+?( _Complex float, float ),
|
---|
| 2064 | ?-?( _Complex float, float ),
|
---|
| 2065 | ?+?( float, _Complex float ),
|
---|
| 2066 | ?-?( float, _Complex float ),
|
---|
| 2067 | ?+?( _Complex float, _Complex float ),
|
---|
| 2068 | ?-?( _Complex float, _Complex float );
|
---|
| 2069 | _Complex double?+?( _Complex double, double ),
|
---|
| 2070 | ?-?( _Complex double, double ),
|
---|
| 2071 | ?+?( double, _Complex double ),
|
---|
| 2072 | ?-?( double, _Complex double ),
|
---|
| 2073 | ?+?( _Complex double, _Complex double ),
|
---|
| 2074 | ?-?( _Complex double, _Complex double );
|
---|
| 2075 | _Complex long double?+?( _Complex long double, long double ),
|
---|
| 2076 | ?-?( _Complex long double, long double ),
|
---|
| 2077 | ?+?( long double, _Complex long double ),
|
---|
| 2078 | ?-?( long double, _Complex long double ),
|
---|
| 2079 | ?+?( _Complex long double, _Complex long double ),
|
---|
| 2080 | ?-?( _Complex long double, _Complex long double );
|
---|
| 2081 |
|
---|
| 2082 | forall( type T ) T
|
---|
| 2083 | * ?+?( T *, ptrdiff_t ),
|
---|
| 2084 | * ?+?( ptrdiff_t, T * ),
|
---|
| 2085 | * ?-?( T *, ptrdiff_t );
|
---|
| 2086 |
|
---|
| 2087 | forall( type T ) _Atomic T
|
---|
| 2088 | * ?+?( _Atomic T *, ptrdiff_t ),
|
---|
| 2089 | * ?+?( ptrdiff_t, _Atomic T * ),
|
---|
| 2090 | * ?-?( _Atomic T *, ptrdiff_t );
|
---|
| 2091 |
|
---|
| 2092 | forall( type T ) const T
|
---|
| 2093 | * ?+?( const T *, ptrdiff_t ),
|
---|
| 2094 | * ?+?( ptrdiff_t, const T * ),
|
---|
| 2095 | * ?-?( const T *, ptrdiff_t );
|
---|
| 2096 |
|
---|
| 2097 | forall( type T ) restrict T
|
---|
| 2098 | * ?+?( restrict T *, ptrdiff_t ),
|
---|
| 2099 | * ?+?( ptrdiff_t, restrict T * ),
|
---|
| 2100 | * ?-?( restrict T *, ptrdiff_t );
|
---|
| 2101 |
|
---|
| 2102 | forall( type T ) volatile T
|
---|
| 2103 | * ?+?( volatile T *, ptrdiff_t ),
|
---|
| 2104 | * ?+?( ptrdiff_t, volatile T * ),
|
---|
| 2105 | * ?-?( volatile T *, ptrdiff_t );
|
---|
| 2106 |
|
---|
| 2107 | forall( type T ) _Atomic const T
|
---|
| 2108 | * ?+?( _Atomic const T *, ptrdiff_t ),
|
---|
| 2109 | * ?+?( ptrdiff_t, _Atomic const T * ),
|
---|
| 2110 | * ?-?( _Atomic const T *, ptrdiff_t );
|
---|
| 2111 |
|
---|
| 2112 | forall( type T ) _Atomic restrict T
|
---|
| 2113 | * ?+?( _Atomic restrict T *, ptrdiff_t ),
|
---|
| 2114 | * ?+?( ptrdiff_t, _Atomic restrict T * ),
|
---|
| 2115 | * ?-?( _Atomic restrict T *, ptrdiff_t );
|
---|
| 2116 |
|
---|
| 2117 | forall( type T ) _Atomic volatile T
|
---|
| 2118 | * ?+?( _Atomic volatile T *, ptrdiff_t ),
|
---|
| 2119 | * ?+?( ptrdiff_t, _Atomic volatile T * ),
|
---|
| 2120 | * ?-?( _Atomic volatile T *, ptrdiff_t );
|
---|
| 2121 |
|
---|
| 2122 | forall( type T ) const restrict T
|
---|
| 2123 | * ?+?( const restrict T *, ptrdiff_t ),
|
---|
| 2124 | * ?+?( ptrdiff_t, const restrict T * ),
|
---|
| 2125 | * ?-?( const restrict T *, ptrdiff_t );
|
---|
| 2126 |
|
---|
| 2127 | forall( type T ) const volatile T
|
---|
| 2128 | * ?+?( const volatile T *, ptrdiff_t ),
|
---|
| 2129 | * ?+?( ptrdiff_t, const volatile T * ),
|
---|
| 2130 | * ?-?( const volatile T *, ptrdiff_t );
|
---|
| 2131 |
|
---|
| 2132 | forall( type T ) restrict volatile T
|
---|
| 2133 | * ?+?( restrict volatile T *, ptrdiff_t ),
|
---|
| 2134 | * ?+?( ptrdiff_t, restrict volatile T * ),
|
---|
| 2135 | * ?-?( restrict volatile T *, ptrdiff_t );
|
---|
| 2136 |
|
---|
| 2137 | forall( type T ) _Atomic const restrict T
|
---|
| 2138 | * ?+?( _Atomic const restrict T *, ptrdiff_t ),
|
---|
| 2139 | * ?+?( ptrdiff_t, _Atomic const restrict T * ),
|
---|
| 2140 | * ?-?( _Atomic const restrict T *, ptrdiff_t );
|
---|
| 2141 |
|
---|
| 2142 | forall( type T ) ptrdiff_t
|
---|
| 2143 | * ?-?( const restrict volatile T *, const restrict volatile T * ),
|
---|
| 2144 | * ?-?( _Atomic const restrict volatile T *, _Atomic const restrict volatile T * );
|
---|
| 2145 | \end{lstlisting}
|
---|
[2fc0e5c] | 2146 | For every extended integer type \lstinline$X$ with \Index{integer conversion rank} greater than the
|
---|
| 2147 | rank of \lstinline$int$ there exist
|
---|
[f60d997] | 2148 | % Don't use predefined: keep this out of prelude.cf.
|
---|
| 2149 | \begin{lstlisting}
|
---|
| 2150 | X ?+?( X ), ?-?( X );
|
---|
| 2151 | \end{lstlisting}
|
---|
| 2152 |
|
---|
| 2153 | \semantics
|
---|
| 2154 | The interpretations of additive expressions are the interpretations of the corresponding function
|
---|
| 2155 | calls.
|
---|
| 2156 |
|
---|
| 2157 | \begin{rationale}
|
---|
| 2158 | \lstinline$ptrdiff_t$ is an implementation-defined identifier defined in \lstinline$<stddef.h>$ that
|
---|
| 2159 | is synonymous with a signed integral type that is large enough to hold the difference between two
|
---|
| 2160 | pointers. It seems reasonable to use it for pointer addition as well. (This is technically a
|
---|
| 2161 | difference between \CFA and C, which only specifies that pointer addition uses an \emph{integral}
|
---|
| 2162 | argument.) Hence it is also used for subscripting, which is defined in terms of pointer addition.
|
---|
| 2163 | The {\c11} standard uses \lstinline$size_t$ in several cases where a library function takes an
|
---|
| 2164 | argument that is used as a subscript, but \lstinline$size_t$ is unsuitable here because it is an
|
---|
| 2165 | unsigned type.
|
---|
| 2166 | \end{rationale}
|
---|
| 2167 |
|
---|
| 2168 |
|
---|
| 2169 | \subsection{Bitwise shift operators}
|
---|
| 2170 |
|
---|
| 2171 | \begin{syntax}
|
---|
| 2172 | \lhs{shift-expression}
|
---|
| 2173 | \rhs \nonterm{additive-expression}
|
---|
| 2174 | \rhs \nonterm{shift-expression} \lstinline$<<$ \nonterm{additive-expression}
|
---|
| 2175 | \rhs \nonterm{shift-expression} \lstinline$>>$ \nonterm{additive-expression}
|
---|
| 2176 | \end{syntax}
|
---|
| 2177 |
|
---|
| 2178 | \rewriterules \use{?>>?}%use{?<<?}
|
---|
| 2179 | \begin{lstlisting}
|
---|
| 2180 | a << b @\rewrite@ ?<<?( a, b )
|
---|
| 2181 | a >> b @\rewrite@ ?>>?( a, b )
|
---|
| 2182 | \end{lstlisting}
|
---|
| 2183 |
|
---|
[bfee448] | 2184 | \predefined
|
---|
[f60d997] | 2185 | \begin{lstlisting}
|
---|
| 2186 | int ?<<?( int, int ),
|
---|
| 2187 | ?>>?( int, int );
|
---|
| 2188 | unsigned int ?<<?( unsigned int, int ),
|
---|
| 2189 | ?>>?( unsigned int, int );
|
---|
| 2190 | long int ?<<?( long int, int ),
|
---|
| 2191 | ?>>?( long int, int );
|
---|
| 2192 | long unsigned int ?<<?( long unsigned int, int ),
|
---|
| 2193 | ?>>?( long unsigned int, int );
|
---|
| 2194 | long long int ?<<?( long long int, int ),
|
---|
| 2195 | ?>>?( long long int, int );
|
---|
| 2196 | long long unsigned int ?<<?( long long unsigned int, int ),
|
---|
| 2197 | ?>>?( long long unsigned int, int);
|
---|
| 2198 | \end{lstlisting}
|
---|
[2fc0e5c] | 2199 | For every extended integer type \lstinline$X$ with \Index{integer conversion rank} greater than the
|
---|
| 2200 | rank of \lstinline$int$ there exist
|
---|
[f60d997] | 2201 | % Don't use predefined: keep this out of prelude.cf.
|
---|
| 2202 | \begin{lstlisting}
|
---|
| 2203 | X ?<<?( X, int ), ?>>?( X, int );
|
---|
| 2204 | \end{lstlisting}
|
---|
| 2205 |
|
---|
| 2206 | \begin{rationale}
|
---|
| 2207 | The bitwise shift operators break the usual pattern: they do not convert both operands to a common
|
---|
[2fc0e5c] | 2208 | type. The right operand only undergoes \Index{integer promotion}.
|
---|
[f60d997] | 2209 | \end{rationale}
|
---|
| 2210 |
|
---|
| 2211 | \semantics
|
---|
| 2212 | The interpretations of a bitwise shift expression are the interpretations of the corresponding
|
---|
| 2213 | function calls.
|
---|
| 2214 |
|
---|
| 2215 |
|
---|
| 2216 | \subsection{Relational operators}
|
---|
| 2217 |
|
---|
| 2218 | \begin{syntax}
|
---|
| 2219 | \lhs{relational-expression}
|
---|
| 2220 | \rhs \nonterm{shift-expression}
|
---|
| 2221 | \rhs \nonterm{relational-expression} \lstinline$< $ \nonterm{shift-expression}
|
---|
| 2222 | \rhs \nonterm{relational-expression} \lstinline$> $ \nonterm{shift-expression}
|
---|
| 2223 | \rhs \nonterm{relational-expression} \lstinline$<=$ \nonterm{shift-expression}
|
---|
| 2224 | \rhs \nonterm{relational-expression} \lstinline$>=$ \nonterm{shift-expression}
|
---|
| 2225 | \end{syntax}
|
---|
| 2226 |
|
---|
| 2227 | \rewriterules\use{?>?}\use{?>=?}%use{?<?}%use{?<=?}
|
---|
| 2228 | \begin{lstlisting}
|
---|
| 2229 | a < b @\rewrite@ ?<?( a, b )
|
---|
| 2230 | a > b @\rewrite@ ?>?( a, b )
|
---|
| 2231 | a <= b @\rewrite@ ?<=?( a, b )
|
---|
| 2232 | a >= b @\rewrite@ ?>=?( a, b )
|
---|
| 2233 | \end{lstlisting}
|
---|
| 2234 |
|
---|
[bfee448] | 2235 | \predefined
|
---|
[f60d997] | 2236 | \begin{lstlisting}
|
---|
| 2237 | int ?<?( int, int ),
|
---|
| 2238 | ?<=?( int, int ),
|
---|
| 2239 | ?>?( int, int ),
|
---|
| 2240 | ?>=?( int, int );
|
---|
| 2241 | int ?<?( unsigned int, unsigned int ),
|
---|
| 2242 | ?<=?( unsigned int, unsigned int ),
|
---|
| 2243 | ?>?( unsigned int, unsigned int ),
|
---|
| 2244 | ?>=?( unsigned int, unsigned int );
|
---|
| 2245 | int ?<?( long int, long int ),
|
---|
| 2246 | ?<=?( long int, long int ),
|
---|
| 2247 | ?>?( long int, long int ),
|
---|
| 2248 | ?>=?( long int, long int );
|
---|
| 2249 | int ?<?( long unsigned int, long unsigned ),
|
---|
| 2250 | ?<=?( long unsigned int, long unsigned ),
|
---|
| 2251 | ?>?( long unsigned int, long unsigned ),
|
---|
| 2252 | ?>=?( long unsigned int, long unsigned );
|
---|
| 2253 | int ?<?( long long int, long long int ),
|
---|
| 2254 | ?<=?( long long int, long long int ),
|
---|
| 2255 | ?>?( long long int, long long int ),
|
---|
| 2256 | ?>=?( long long int, long long int );
|
---|
| 2257 | int ?<?( long long unsigned int, long long unsigned ),
|
---|
| 2258 | ?<=?( long long unsigned int, long long unsigned ),
|
---|
| 2259 | ?>?( long long unsigned int, long long unsigned ),
|
---|
| 2260 | ?>=?( long long unsigned int, long long unsigned );
|
---|
| 2261 | int ?<?( float, float ),
|
---|
| 2262 | ?<=?( float, float ),
|
---|
| 2263 | ?>?( float, float ),
|
---|
| 2264 | ?>=?( float, float );
|
---|
| 2265 | int ?<?( double, double ),
|
---|
| 2266 | ?<=?( double, double ),
|
---|
| 2267 | ?>?( double, double ),
|
---|
| 2268 | ?>=?( double, double );
|
---|
| 2269 | int ?<?( long double, long double ),
|
---|
| 2270 | ?<=?( long double, long double ),
|
---|
| 2271 | ?>?( long double, long double ),
|
---|
| 2272 | ?>=?( long double, long double );
|
---|
| 2273 |
|
---|
| 2274 | forall( dtype DT ) int
|
---|
| 2275 | ?<?( const restrict volatile DT *, const restrict volatile DT * ),
|
---|
| 2276 | ?<?( _Atomic const restrict volatile DT *, _Atomic const restrict volatile DT * ),
|
---|
| 2277 | ?<=?( const restrict volatile DT *, const restrict volatile DT * ),
|
---|
| 2278 | ?<=?( _Atomic const restrict volatile DT *, _Atomic const restrict volatile DT * ),
|
---|
| 2279 | ?>?( const restrict volatile DT *, const restrict volatile DT * ),
|
---|
| 2280 | ?>?( _Atomic const restrict volatile DT *, _Atomic const restrict volatile DT * ),
|
---|
| 2281 | ?>=?( const restrict volatile DT *, const restrict volatile DT * ),
|
---|
| 2282 | ?>=?( _Atomic const restrict volatile DT *, _Atomic const restrict volatile DT * );
|
---|
| 2283 | \end{lstlisting}
|
---|
[2fc0e5c] | 2284 | For every extended integer type \lstinline$X$ with \Index{integer conversion rank} greater than the
|
---|
| 2285 | rank of \lstinline$int$ there exist
|
---|
[f60d997] | 2286 | % Don't use predefined: keep this out of prelude.cf.
|
---|
| 2287 | \begin{lstlisting}
|
---|
| 2288 | int ?<?( X, X ),
|
---|
| 2289 | ?<=?( X, X ),
|
---|
| 2290 | ?<?( X, X ),
|
---|
| 2291 | ?>=?( X, X );
|
---|
| 2292 | \end{lstlisting}
|
---|
| 2293 |
|
---|
| 2294 | \semantics
|
---|
| 2295 | The interpretations of a relational expression are the interpretations of the corresponding function
|
---|
| 2296 | call.
|
---|
| 2297 |
|
---|
| 2298 |
|
---|
| 2299 | \subsection{Equality operators}
|
---|
| 2300 |
|
---|
| 2301 | \begin{syntax}
|
---|
| 2302 | \lhs{equality-expression}
|
---|
| 2303 | \rhs \nonterm{relational-expression}
|
---|
| 2304 | \rhs \nonterm{equality-expression} \lstinline$==$ \nonterm{relational-expression}
|
---|
| 2305 | \rhs \nonterm{equality-expression} \lstinline$!=$ \nonterm{relational-expression}
|
---|
| 2306 | \end{syntax}
|
---|
| 2307 |
|
---|
| 2308 | \rewriterules
|
---|
| 2309 | \begin{lstlisting}
|
---|
| 2310 | a == b @\rewrite@ ?==?( a, b )@\use{?==?}@
|
---|
| 2311 | a != b @\rewrite@ ?!=?( a, b )@\use{?"!=?}@
|
---|
| 2312 | \end{lstlisting}
|
---|
| 2313 |
|
---|
[bfee448] | 2314 | \predefined
|
---|
[f60d997] | 2315 | \begin{lstlisting}
|
---|
| 2316 | int ?==?( int, int ),
|
---|
| 2317 | ?!=?( int, int ),
|
---|
| 2318 | ?==?( unsigned int, unsigned int ),
|
---|
| 2319 | ?!=?( unsigned int, unsigned int ),
|
---|
| 2320 | ?==?( long int, long int ),
|
---|
| 2321 | ?!=?( long int, long int ),
|
---|
| 2322 | ?==?( long unsigned int, long unsigned int ),
|
---|
| 2323 | ?!=?( long unsigned int, long unsigned int ),
|
---|
| 2324 | ?==?( long long int, long long int ),
|
---|
| 2325 | ?!=?( long long int, long long int ),
|
---|
| 2326 | ?==?( long long unsigned int, long long unsigned int ),
|
---|
| 2327 | ?!=?( long long unsigned int, long long unsigned int ),
|
---|
| 2328 | ?==?( float, float ),
|
---|
| 2329 | ?!=?( float, float ),
|
---|
| 2330 | ?==?( _Complex float, float ),
|
---|
| 2331 | ?!=?( _Complex float, float ),
|
---|
| 2332 | ?==?( float, _Complex float ),
|
---|
| 2333 | ?!=?( float, _Complex float ),
|
---|
| 2334 | ?==?( _Complex float, _Complex float ),
|
---|
| 2335 | ?!=?( _Complex float, _Complex float ),
|
---|
| 2336 | ?==?( double, double ),
|
---|
| 2337 | ?!=?( double, double ),
|
---|
| 2338 | ?==?( _Complex double, double ),
|
---|
| 2339 | ?!=?( _Complex double, double ),
|
---|
| 2340 | ?==?( double, _Complex double ),
|
---|
| 2341 | ?!=?( double, _Complex double ),
|
---|
| 2342 | ?==?( _Complex double, _Complex double ),
|
---|
| 2343 | ?!=?( _Complex double, _Complex double ),
|
---|
| 2344 | ?==?( long double, long double ),
|
---|
| 2345 | ?!=?( long double, long double ),
|
---|
| 2346 | ?==?( _Complex long double, long double ),
|
---|
| 2347 | ?!=?( _Complex long double, long double ),
|
---|
| 2348 | ?==?( long double, _Complex long double ),
|
---|
| 2349 | ?!=?( long double, _Complex long double ),
|
---|
| 2350 | ?==?( _Complex long double, _Complex long double ),
|
---|
| 2351 | ?!=?( _Complex long double, _Complex long double );
|
---|
| 2352 |
|
---|
| 2353 | forall( dtype DT ) int
|
---|
| 2354 | ?==?( const restrict volatile DT *, const restrict volatile DT * ),
|
---|
| 2355 | ?!=?( const restrict volatile DT *, const restrict volatile DT * ),
|
---|
| 2356 | ?==?( const restrict volatile DT *, const restrict volatile void * ),
|
---|
| 2357 | ?!=?( const restrict volatile DT *, const restrict volatile void * ),
|
---|
| 2358 | ?==?( const restrict volatile void *, const restrict volatile DT * ),
|
---|
| 2359 | ?!=?( const restrict volatile void *, const restrict volatile DT * ),
|
---|
| 2360 | ?==?( const restrict volatile DT *, forall( dtype DT2) const DT2 * ),
|
---|
| 2361 | ?!=?( const restrict volatile DT *, forall( dtype DT2) const DT2 * ),
|
---|
| 2362 | ?==?( forall( dtype DT2) const DT2*, const restrict volatile DT * ),
|
---|
| 2363 | ?!=?( forall( dtype DT2) const DT2*, const restrict volatile DT * ),
|
---|
| 2364 | ?==?( forall( dtype DT2) const DT2*, forall( dtype DT3) const DT3 * ),
|
---|
| 2365 | ?!=?( forall( dtype DT2) const DT2*, forall( dtype DT3) const DT3 * ),
|
---|
| 2366 |
|
---|
| 2367 | ?==?( _Atomic const restrict volatile DT *, _Atomic const restrict volatile DT * ),
|
---|
| 2368 | ?!=?( _Atomic const restrict volatile DT *, _Atomic const restrict volatile DT * ),
|
---|
| 2369 | ?==?( _Atomic const restrict volatile DT *, const restrict volatile void * ),
|
---|
| 2370 | ?!=?( _Atomic const restrict volatile DT *, const restrict volatile void * ),
|
---|
| 2371 | ?==?( const restrict volatile void *, _Atomic const restrict volatile DT * ),
|
---|
| 2372 | ?!=?( const restrict volatile void *, _Atomic const restrict volatile DT * ),
|
---|
| 2373 | ?==?( _Atomic const restrict volatile DT *, forall( dtype DT2) const DT2 * ),
|
---|
| 2374 | ?!=?( _Atomic const restrict volatile DT *, forall( dtype DT2) const DT2 * ),
|
---|
| 2375 | ?==?( forall( dtype DT2) const DT2*, _Atomic const restrict volatile DT * ),
|
---|
| 2376 | ?!=?( forall( dtype DT2) const DT2*, _Atomic const restrict volatile DT * );
|
---|
| 2377 |
|
---|
| 2378 | forall( ftype FT ) int
|
---|
| 2379 | ?==?( FT *, FT * ),
|
---|
| 2380 | ?!=?( FT *, FT * ),
|
---|
| 2381 | ?==?( FT *, forall( ftype FT2) FT2 * ),
|
---|
| 2382 | ?!=?( FT *, forall( ftype FT2) FT2 * ),
|
---|
| 2383 | ?==?( forall( ftype FT2) FT2*, FT * ),
|
---|
| 2384 | ?!=?( forall( ftype FT2) FT2*, FT * ),
|
---|
| 2385 | ?==?( forall( ftype FT2) FT2*, forall( ftype FT3) FT3 * ),
|
---|
| 2386 | ?!=?( forall( ftype FT2) FT2*, forall( ftype FT3) FT3 * );
|
---|
| 2387 | \end{lstlisting}
|
---|
[2fc0e5c] | 2388 | For every extended integer type \lstinline$X$ with \Index{integer conversion rank} greater than the
|
---|
| 2389 | rank of \lstinline$int$ there exist
|
---|
[f60d997] | 2390 | % Don't use predefined: keep this out of prelude.cf.
|
---|
| 2391 | \begin{lstlisting}
|
---|
| 2392 | int ?==?( X, X ),
|
---|
| 2393 | ?!=?( X, X );
|
---|
| 2394 | \end{lstlisting}
|
---|
| 2395 |
|
---|
| 2396 | \begin{rationale}
|
---|
| 2397 | The polymorphic equality operations come in three styles: comparisons between pointers of compatible
|
---|
| 2398 | types, between pointers to \lstinline$void$ and pointers to object types or incomplete types, and
|
---|
[2fc0e5c] | 2399 | between the \Index{null pointer} constant and pointers to any type. In the last case, a special
|
---|
| 2400 | constraint rule for null pointer constant operands has been replaced by a consequence of the \CFA
|
---|
| 2401 | type system.
|
---|
[f60d997] | 2402 | \end{rationale}
|
---|
| 2403 |
|
---|
| 2404 | \semantics
|
---|
| 2405 | The interpretations of an equality expression are the interpretations of the corresponding function
|
---|
| 2406 | call.
|
---|
| 2407 |
|
---|
| 2408 | \begin{sloppypar}
|
---|
| 2409 | The result of an equality comparison between two pointers to predefined functions or predefined
|
---|
| 2410 | values is implementation-defined.
|
---|
| 2411 | \end{sloppypar}
|
---|
| 2412 | \begin{rationale}
|
---|
| 2413 | The implementation-defined status of equality comparisons allows implementations to use one library
|
---|
| 2414 | routine to implement many predefined functions. These optimization are particularly important when
|
---|
| 2415 | the predefined functions are polymorphic, as is the case for most pointer operations
|
---|
| 2416 | \end{rationale}
|
---|
| 2417 |
|
---|
| 2418 |
|
---|
| 2419 | \subsection{Bitwise AND operator}
|
---|
| 2420 |
|
---|
| 2421 | \begin{syntax}
|
---|
| 2422 | \lhs{AND-expression}
|
---|
| 2423 | \rhs \nonterm{equality-expression}
|
---|
| 2424 | \rhs \nonterm{AND-expression} \lstinline$&$ \nonterm{equality-expression}
|
---|
| 2425 | \end{syntax}
|
---|
| 2426 |
|
---|
| 2427 | \rewriterules
|
---|
| 2428 | \begin{lstlisting}
|
---|
| 2429 | a & b @\rewrite@ ?&?( a, b )@\use{?&?}@
|
---|
| 2430 | \end{lstlisting}
|
---|
| 2431 |
|
---|
[bfee448] | 2432 | \predefined
|
---|
[f60d997] | 2433 | \begin{lstlisting}
|
---|
| 2434 | int ?&?( int, int );
|
---|
| 2435 | unsigned int ?&?( unsigned int, unsigned int );
|
---|
| 2436 | long int ?&?( long int, long int );
|
---|
| 2437 | long unsigned int ?&?( long unsigned int, long unsigned int );
|
---|
| 2438 | long long int ?&?( long long int, long long int );
|
---|
| 2439 | long long unsigned int ?&?( long long unsigned int, long long unsigned int );
|
---|
| 2440 | \end{lstlisting}
|
---|
[2fc0e5c] | 2441 | For every extended integer type \lstinline$X$ with \Index{integer conversion rank} greater than the
|
---|
| 2442 | rank of \lstinline$int$ there exist
|
---|
[f60d997] | 2443 | % Don't use predefined: keep this out of prelude.cf.
|
---|
| 2444 | \begin{lstlisting}
|
---|
| 2445 | int ?&?( X, X );
|
---|
| 2446 | \end{lstlisting}
|
---|
| 2447 |
|
---|
| 2448 | \semantics
|
---|
| 2449 | The interpretations of a bitwise AND expression are the interpretations of the corresponding
|
---|
| 2450 | function call.
|
---|
| 2451 |
|
---|
| 2452 |
|
---|
| 2453 | \subsection{Bitwise exclusive OR operator}
|
---|
| 2454 |
|
---|
| 2455 | \begin{syntax}
|
---|
| 2456 | \lhs{exclusive-OR-expression}
|
---|
| 2457 | \rhs \nonterm{AND-expression}
|
---|
| 2458 | \rhs \nonterm{exclusive-OR-expression} \lstinline$^$ \nonterm{AND-expression}
|
---|
| 2459 | \end{syntax}
|
---|
| 2460 |
|
---|
| 2461 | \rewriterules
|
---|
| 2462 | \begin{lstlisting}
|
---|
| 2463 | a ^ b @\rewrite@ ?^?( a, b )@\use{?^?}@
|
---|
| 2464 | \end{lstlisting}
|
---|
| 2465 |
|
---|
[bfee448] | 2466 | \predefined
|
---|
[f60d997] | 2467 | \begin{lstlisting}
|
---|
| 2468 | int ?^?( int, int );
|
---|
| 2469 | unsigned int ?^?( unsigned int, unsigned int );
|
---|
| 2470 | long int ?^?( long int, long int );
|
---|
| 2471 | long unsigned int ?^?( long unsigned int, long unsigned int );
|
---|
| 2472 | long long int ?^?( long long int, long long int );
|
---|
| 2473 | long long unsigned int ?^?( long long unsigned int, long long unsigned int );
|
---|
| 2474 | \end{lstlisting}
|
---|
[2fc0e5c] | 2475 | For every extended integer type \lstinline$X$ with \Index{integer conversion rank} greater than the
|
---|
| 2476 | rank of \lstinline$int$ there exist
|
---|
[f60d997] | 2477 | % Don't use predefined: keep this out of prelude.cf.
|
---|
| 2478 | \begin{lstlisting}
|
---|
| 2479 | int ?^?( X, X );
|
---|
| 2480 | \end{lstlisting}
|
---|
| 2481 |
|
---|
| 2482 | \semantics
|
---|
| 2483 | The interpretations of a bitwise exclusive OR expression are the interpretations of the
|
---|
| 2484 | corresponding function call.
|
---|
| 2485 |
|
---|
| 2486 |
|
---|
| 2487 | \subsection{Bitwise inclusive OR operator}
|
---|
| 2488 |
|
---|
| 2489 | \begin{syntax}
|
---|
| 2490 | \lhs{inclusive-OR-expression}
|
---|
| 2491 | \rhs \nonterm{exclusive-OR-expression}
|
---|
| 2492 | \rhs \nonterm{inclusive-OR-expression} \lstinline$|$ \nonterm{exclusive-OR-expression}
|
---|
| 2493 | \end{syntax}
|
---|
| 2494 |
|
---|
| 2495 | \rewriterules\use{?"|?}
|
---|
| 2496 | \begin{lstlisting}
|
---|
| 2497 | a | b @\rewrite@ ?|?( a, b )
|
---|
| 2498 | \end{lstlisting}
|
---|
| 2499 |
|
---|
[bfee448] | 2500 | \predefined
|
---|
[f60d997] | 2501 | \begin{lstlisting}
|
---|
| 2502 | int ?|?( int, int );
|
---|
| 2503 | unsigned int ?|?( unsigned int, unsigned int );
|
---|
| 2504 | long int ?|?( long int, long int );
|
---|
| 2505 | long unsigned int ?|?( long unsigned int, long unsigned int );
|
---|
| 2506 | long long int ?|?( long long int, long long int );
|
---|
| 2507 | long long unsigned int ?|?( long long unsigned int, long long unsigned int );
|
---|
| 2508 | \end{lstlisting}
|
---|
[2fc0e5c] | 2509 | For every extended integer type \lstinline$X$ with \Index{integer conversion rank} greater than the
|
---|
| 2510 | rank of \lstinline$int$ there exist
|
---|
[f60d997] | 2511 | % Don't use predefined: keep this out of prelude.cf.
|
---|
| 2512 | \begin{lstlisting}
|
---|
| 2513 | int ?|?( X, X );
|
---|
| 2514 | \end{lstlisting}
|
---|
| 2515 |
|
---|
| 2516 | \semantics
|
---|
| 2517 | The interpretations of a bitwise inclusive OR expression are the interpretations of the
|
---|
| 2518 | corresponding function call.
|
---|
| 2519 |
|
---|
| 2520 |
|
---|
| 2521 | \subsection{Logical AND operator}
|
---|
| 2522 |
|
---|
| 2523 | \begin{syntax}
|
---|
| 2524 | \lhs{logical-AND-expression}
|
---|
| 2525 | \rhs \nonterm{inclusive-OR-expression}
|
---|
| 2526 | \rhs \nonterm{logical-AND-expression} \lstinline$&&$ \nonterm{inclusive-OR-expression}
|
---|
| 2527 | \end{syntax}
|
---|
| 2528 |
|
---|
| 2529 | \semantics The operands of the expression ``\lstinline$a && b$'' are treated as
|
---|
| 2530 | ``\lstinline$(int)((a)!=0)$'' and ``\lstinline$(int)((b)!=0)$'', which shall both be
|
---|
| 2531 | unambiguous. The expression has only one interpretation, which is of type \lstinline$int$.
|
---|
| 2532 | \begin{rationale}
|
---|
| 2533 | When the operands of a logical expression are values of built-in types, and ``\lstinline$!=$'' has
|
---|
| 2534 | not been redefined for those types, the compiler can optimize away the function calls.
|
---|
| 2535 |
|
---|
| 2536 | A common C idiom omits comparisons to \lstinline$0$ in the controlling expressions of loops and
|
---|
| 2537 | \lstinline$if$ statements. For instance, the loop below iterates as long as \lstinline$rp$ points
|
---|
| 2538 | at a \lstinline$Rational$ value that is non-zero.
|
---|
| 2539 |
|
---|
| 2540 | \begin{lstlisting}
|
---|
| 2541 | extern type Rational;@\use{Rational}@
|
---|
| 2542 | extern const Rational 0;@\use{0}@
|
---|
| 2543 | extern int ?!=?( Rational, Rational );
|
---|
| 2544 | Rational *rp;
|
---|
| 2545 |
|
---|
| 2546 | while ( rp && *rp ) { ... }
|
---|
| 2547 | \end{lstlisting}
|
---|
| 2548 | The logical expression calls the \lstinline$Rational$ inequality operator, passing
|
---|
| 2549 | it \lstinline$*rp$ and the \lstinline$Rational 0$, and getting a 1 or 0 as a result. In
|
---|
| 2550 | contrast, {\CC} would apply a programmer-defined \lstinline$Rational$-to-\lstinline$int$
|
---|
| 2551 | conversion to \lstinline$*rp$ in the equivalent situation. The conversion to \lstinline$int$ would
|
---|
| 2552 | produce a general integer value, which is unfortunate, and possibly dangerous if the conversion was
|
---|
| 2553 | not written with this situation in mind.
|
---|
| 2554 | \end{rationale}
|
---|
| 2555 |
|
---|
| 2556 |
|
---|
| 2557 | \subsection{Logical OR operator}
|
---|
| 2558 |
|
---|
| 2559 | \begin{syntax}
|
---|
| 2560 | \lhs{logical-OR-expression}
|
---|
| 2561 | \rhs \nonterm{logical-AND-expression}
|
---|
| 2562 | \rhs \nonterm{logical-OR-expression} \lstinline$||$ \nonterm{logical-AND-expression}
|
---|
| 2563 | \end{syntax}
|
---|
| 2564 |
|
---|
| 2565 | \semantics
|
---|
| 2566 |
|
---|
| 2567 | The operands of the expression ``\lstinline$a || b$'' are treated as ``\lstinline$(int)((a)!=0)$''
|
---|
[a188b16] | 2568 | and ``\lstinline$(int)((b))!=0)$'', which shall both be unambiguous. The expression has only one
|
---|
[f60d997] | 2569 | interpretation, which is of type \lstinline$int$.
|
---|
| 2570 |
|
---|
| 2571 |
|
---|
| 2572 | \subsection{Conditional operator}
|
---|
| 2573 |
|
---|
| 2574 | \begin{syntax}
|
---|
| 2575 | \lhs{conditional-expression}
|
---|
| 2576 | \rhs \nonterm{logical-OR-expression}
|
---|
| 2577 | \rhs \nonterm{logical-OR-expression} \lstinline$?$ \nonterm{expression}
|
---|
| 2578 | \lstinline$:$ \nonterm{conditional-expression}
|
---|
| 2579 | \end{syntax}
|
---|
| 2580 |
|
---|
| 2581 | \semantics
|
---|
| 2582 | In the conditional expression\use{?:} ``\lstinline$a?b:c$'', if the second and
|
---|
| 2583 | third operands both have an interpretation with \lstinline$void$ type, then the expression has an
|
---|
| 2584 | interpretation with type \lstinline$void$, equivalent to
|
---|
| 2585 | \begin{lstlisting}
|
---|
| 2586 | ( int)(( a)!=0) ? ( void)( b) : ( void)( c)
|
---|
| 2587 | \end{lstlisting}
|
---|
| 2588 |
|
---|
| 2589 | If the second and third operands both have interpretations with non-\lstinline$void$ types, the
|
---|
| 2590 | expression is treated as if it were the call ``\lstinline$cond((a)!=0, b, c)$'',
|
---|
| 2591 | with \lstinline$cond$ declared as
|
---|
| 2592 | \begin{lstlisting}
|
---|
| 2593 | forall( type T ) T cond( int, T, T );
|
---|
| 2594 |
|
---|
| 2595 | forall( dtype D ) void
|
---|
| 2596 | * cond( int, D *, void * ),
|
---|
| 2597 | * cond( int, void *, D * );
|
---|
| 2598 |
|
---|
| 2599 | forall( dtype D ) _atomic void
|
---|
| 2600 | * cond( int, _Atomic D *, _Atomic void * ),
|
---|
| 2601 | * cond( int, _Atomic void *, _Atomic D * );
|
---|
| 2602 |
|
---|
| 2603 | forall( dtype D ) const void
|
---|
| 2604 | * cond( int, const D *, const void * ),
|
---|
| 2605 | * cond( int, const void *, const D * );
|
---|
| 2606 |
|
---|
| 2607 | forall( dtype D ) restrict void
|
---|
| 2608 | * cond( int, restrict D *, restrict void * ),
|
---|
| 2609 | * cond( int, restrict void *, restrict D * );
|
---|
| 2610 |
|
---|
| 2611 | forall( dtype D ) volatile void
|
---|
| 2612 | * cond( int, volatile D *, volatile void * ),
|
---|
| 2613 | * cond( int, volatile void *, volatile D * );
|
---|
| 2614 |
|
---|
| 2615 | forall( dtype D ) _Atomic const void
|
---|
| 2616 | * cond( int, _Atomic const D *, _Atomic const void * ),
|
---|
| 2617 | * cond( int, _Atomic const void *, _Atomic const D * );
|
---|
| 2618 |
|
---|
| 2619 | forall( dtype D ) _Atomic restrict void
|
---|
| 2620 | * cond( int, _Atomic restrict D *, _Atomic restrict void * ),
|
---|
| 2621 | * cond( int, _Atomic restrict void *, _Atomic restrict D * );
|
---|
| 2622 |
|
---|
| 2623 | forall( dtype D ) _Atomic volatile void
|
---|
| 2624 | * cond( int, _Atomic volatile D *, _Atomic volatile void * ),
|
---|
| 2625 | * cond( int, _Atomic volatile void *, _Atomic volatile D * );
|
---|
| 2626 |
|
---|
| 2627 | forall( dtype D ) const restrict void
|
---|
| 2628 | * cond( int, const restrict D *, const restrict void * ),
|
---|
| 2629 | * cond( int, const restrict void *, const restrict D * );
|
---|
| 2630 |
|
---|
| 2631 | forall( dtype D ) const volatile void
|
---|
| 2632 | * cond( int, const volatile D *, const volatile void * ),
|
---|
| 2633 | * cond( int, const volatile void *, const volatile D * );
|
---|
| 2634 |
|
---|
| 2635 | forall( dtype D ) restrict volatile void
|
---|
| 2636 | * cond( int, restrict volatile D *, restrict volatile void * ),
|
---|
| 2637 | * cond( int, restrict volatile void *, restrict volatile D * );
|
---|
| 2638 |
|
---|
| 2639 | forall( dtype D ) _Atomic const restrict void
|
---|
| 2640 | * cond( int, _Atomic const restrict D *, _Atomic const restrict void * ),
|
---|
| 2641 | * cond( int, _Atomic const restrict void *, _Atomic const restrict D * );
|
---|
| 2642 |
|
---|
| 2643 | forall( dtype D ) _Atomic const volatile void
|
---|
| 2644 | * cond( int, _Atomic const volatile D *, _Atomic const volatile void * ),
|
---|
| 2645 | * cond( int, _Atomic const volatile void *, _Atomic const volatile D * );
|
---|
| 2646 |
|
---|
| 2647 | forall( dtype D ) _Atomic restrict volatile void
|
---|
| 2648 | * cond( int, _Atomic restrict volatile D *,
|
---|
| 2649 | _Atomic restrict volatile void * ),
|
---|
| 2650 | * cond( int, _Atomic restrict volatile void *,
|
---|
| 2651 | _Atomic restrict volatile D * );
|
---|
| 2652 |
|
---|
| 2653 | forall( dtype D ) const restrict volatile void
|
---|
| 2654 | * cond( int, const restrict volatile D *,
|
---|
| 2655 | const restrict volatile void * ),
|
---|
| 2656 | * cond( int, const restrict volatile void *,
|
---|
| 2657 | const restrict volatile D * );
|
---|
| 2658 |
|
---|
| 2659 | forall( dtype D ) _Atomic const restrict volatile void
|
---|
| 2660 | * cond( int, _Atomic const restrict volatile D *,
|
---|
| 2661 | _Atomic const restrict volatile void * ),
|
---|
| 2662 | * cond( int, _Atomic const restrict volatile void *,
|
---|
| 2663 | _Atomic const restrict volatile D * );
|
---|
| 2664 | \end{lstlisting}
|
---|
| 2665 |
|
---|
| 2666 | \begin{rationale}
|
---|
[2fc0e5c] | 2667 | The object of the above is to apply the \Index{usual arithmetic conversion}s when the second and
|
---|
| 2668 | third operands have arithmetic type, and to combine the qualifiers of the second and third operands
|
---|
| 2669 | if they are pointers.
|
---|
[f60d997] | 2670 | \end{rationale}
|
---|
| 2671 |
|
---|
| 2672 | \examples
|
---|
| 2673 | \begin{lstlisting}
|
---|
| 2674 | #include <stdlib.h>
|
---|
| 2675 | int i;
|
---|
| 2676 | long l;
|
---|
| 2677 | rand() ? i : l;
|
---|
| 2678 | \end{lstlisting}
|
---|
| 2679 | The best interpretation infers the expression's type to be \lstinline$long$ and applies the safe
|
---|
| 2680 | \lstinline$int$-to-\lstinline$long$ conversion to \lstinline$i$.
|
---|
| 2681 |
|
---|
| 2682 | \begin{lstlisting}
|
---|
| 2683 | const int *cip;
|
---|
| 2684 | volatile int *vip;
|
---|
| 2685 | rand() ? cip : vip;
|
---|
| 2686 | \end{lstlisting}
|
---|
| 2687 | The expression has type \lstinline$const volatile int *$, with safe conversions applied to the second
|
---|
| 2688 | and third operands to add \lstinline$volatile$ and \lstinline$const$ qualifiers, respectively.
|
---|
| 2689 |
|
---|
| 2690 | \begin{lstlisting}
|
---|
| 2691 | rand() ? cip : 0;
|
---|
| 2692 | \end{lstlisting}
|
---|
| 2693 | The expression has type \lstinline$const int *$, with a specialization conversion applied to
|
---|
| 2694 | \lstinline$0$.
|
---|
| 2695 |
|
---|
| 2696 |
|
---|
| 2697 | \subsection{Assignment operators}
|
---|
| 2698 |
|
---|
| 2699 | \begin{syntax}
|
---|
| 2700 | \lhs{assignment-expression}
|
---|
| 2701 | \rhs \nonterm{conditional-expression}
|
---|
| 2702 | \rhs \nonterm{unary-expression} \nonterm{assignment-operator}
|
---|
| 2703 | \nonterm{assignment-expression}
|
---|
| 2704 | \lhs{assignment-operator} one of
|
---|
| 2705 | \rhs \lstinline$=$\ \ \lstinline$*=$\ \ \lstinline$/=$\ \ \lstinline$%=$\ \ \lstinline$+=$\ \ \lstinline$-=$\ \
|
---|
| 2706 | \lstinline$<<=$\ \ \lstinline$>>=$\ \ \lstinline$&=$\ \ \lstinline$^=$\ \ \lstinline$|=$
|
---|
| 2707 | \end{syntax}
|
---|
| 2708 |
|
---|
| 2709 | \rewriterules
|
---|
| 2710 | Let ``\(\leftarrow\)'' be any of the assignment operators. Then
|
---|
| 2711 | \use{?=?}\use{?*=?}\use{?/=?}\use{?%=?}\use{?+=?}\use{?-=?}
|
---|
| 2712 | \use{?>>=?}\use{?&=?}\use{?^=?}\use{?"|=?}%use{?<<=?}
|
---|
| 2713 | \begin{lstlisting}
|
---|
| 2714 | a @$\leftarrow$@ b @\rewrite@ ?@$\leftarrow$@?( &( a ), b )
|
---|
| 2715 | \end{lstlisting}
|
---|
| 2716 |
|
---|
| 2717 | \semantics
|
---|
| 2718 | Each interpretation of the left operand of an assignment expression is considered separately. For
|
---|
| 2719 | each interpretation that is a bit-field or is declared with the \lstinline$register$ storage class
|
---|
| 2720 | specifier, the expression has one valid interpretation, with the type of the left operand. The
|
---|
| 2721 | right operand is cast to that type, and the assignment expression is ambiguous if either operand is.
|
---|
| 2722 | For the remaining interpretations, the expression is rewritten, and the interpretations of the
|
---|
| 2723 | assignment expression are the interpretations of the corresponding function call. Finally, all
|
---|
| 2724 | interpretations of the expression produced for the different interpretations of the left operand are
|
---|
| 2725 | combined to produce the interpretations of the expression as a whole; where interpretations have
|
---|
| 2726 | compatible result types, the best interpretations are selected in the manner described for function
|
---|
| 2727 | call expressions.
|
---|
| 2728 |
|
---|
| 2729 |
|
---|
| 2730 | \subsubsection{Simple assignment}
|
---|
| 2731 |
|
---|
[bfee448] | 2732 | \predefined
|
---|
[f60d997] | 2733 | \begin{lstlisting}
|
---|
| 2734 | _Bool
|
---|
| 2735 | ?=?( volatile _Bool *, _Bool ),
|
---|
| 2736 | ?=?( volatile _Bool *, forall( dtype D ) D * ),
|
---|
| 2737 | ?=?( volatile _Bool *, forall( ftype F ) F * ),
|
---|
| 2738 | ?=?( _Atomic volatile _Bool *, _Bool ),
|
---|
| 2739 | ?=?( _Atomic volatile _Bool *, forall( dtype D ) D * ),
|
---|
| 2740 | ?=?( _Atomic volatile _Bool *, forall( ftype F ) F * );
|
---|
| 2741 | char
|
---|
| 2742 | ?=?( volatile char *, char ),
|
---|
| 2743 | ?=?( _Atomic volatile char *, char );
|
---|
| 2744 | unsigned char
|
---|
| 2745 | ?=?( volatile unsigned char *, unsigned char ),
|
---|
| 2746 | ?=?( _Atomic volatile unsigned char *, unsigned char );
|
---|
| 2747 | signed char
|
---|
| 2748 | ?=?( volatile signed char *, signed char ),
|
---|
| 2749 | ?=?( _Atomic volatile signed char *, signed char );
|
---|
| 2750 | short int
|
---|
| 2751 | ?=?( volatile short int *, short int ),
|
---|
| 2752 | ?=?( _Atomic volatile short int *, short int );
|
---|
| 2753 | unsigned short
|
---|
| 2754 | ?=?( volatile unsigned int *, unsigned int ),
|
---|
| 2755 | ?=?( _Atomic volatile unsigned int *, unsigned int );
|
---|
| 2756 | int
|
---|
| 2757 | ?=?( volatile int *, int ),
|
---|
| 2758 | ?=?( _Atomic volatile int *, int );
|
---|
| 2759 | unsigned int
|
---|
| 2760 | ?=?( volatile unsigned int *, unsigned int ),
|
---|
| 2761 | ?=?( _Atomic volatile unsigned int *, unsigned int );
|
---|
| 2762 | long int
|
---|
| 2763 | ?=?( volatile long int *, long int ),
|
---|
| 2764 | ?=?( _Atomic volatile long int *, long int );
|
---|
| 2765 | unsigned long int
|
---|
| 2766 | ?=?( volatile unsigned long int *, unsigned long int ),
|
---|
| 2767 | ?=?( _Atomic volatile unsigned long int *, unsigned long int );
|
---|
| 2768 | long long int
|
---|
| 2769 | ?=?( volatile long long int *, long long int ),
|
---|
| 2770 | ?=?( _Atomic volatile long long int *, long long int );
|
---|
| 2771 | unsigned long long int
|
---|
| 2772 | ?=?( volatile unsigned long long int *, unsigned long long int ),
|
---|
| 2773 | ?=?( _Atomic volatile unsigned long long int *, unsigned long long int );
|
---|
| 2774 | float
|
---|
| 2775 | ?=?( volatile float *, float ),
|
---|
| 2776 | ?=?( _Atomic volatile float *, float );
|
---|
| 2777 | double
|
---|
| 2778 | ?=?( volatile double *, double ),
|
---|
| 2779 | ?=?( _Atomic volatile double *, double );
|
---|
| 2780 | long double
|
---|
| 2781 | ?=?( volatile long double *, long double ),
|
---|
| 2782 | ?=?( _Atomic volatile long double *, long double );
|
---|
| 2783 | _Complex float
|
---|
| 2784 | ?=?( volatile float *, float ),
|
---|
| 2785 | ?=?( _Atomic volatile float *, float );
|
---|
| 2786 | _Complex double
|
---|
| 2787 | ?=?( volatile double *, double ),
|
---|
| 2788 | ?=?( _Atomic volatile double *, double );
|
---|
| 2789 | _Complex long double
|
---|
| 2790 | ?=?( volatile _Complex long double *, _Complex long double ),
|
---|
| 2791 | ?=?( _Atomic volatile _Complex long double *, _Atomic _Complex long double );
|
---|
| 2792 |
|
---|
| 2793 | forall( ftype FT ) FT
|
---|
| 2794 | * ?=?( FT * volatile *, FT * ),
|
---|
| 2795 | * ?=?( FT * volatile *, forall( ftype F ) F * );
|
---|
| 2796 |
|
---|
| 2797 | forall( ftype FT ) FT const
|
---|
| 2798 | * ?=?( FT const * volatile *, FT const * ),
|
---|
| 2799 | * ?=?( FT const * volatile *, forall( ftype F ) F * );
|
---|
| 2800 |
|
---|
| 2801 | forall( ftype FT ) FT volatile
|
---|
| 2802 | * ?=?( FT volatile * volatile *, FT * ),
|
---|
| 2803 | * ?=?( FT volatile * volatile *, forall( ftype F ) F * );
|
---|
| 2804 |
|
---|
| 2805 | forall( ftype FT ) FT const
|
---|
| 2806 | * ?=?( FT const volatile * volatile *, FT const * ),
|
---|
| 2807 | * ?=?( FT const volatile * volatile *, forall( ftype F ) F * );
|
---|
| 2808 |
|
---|
| 2809 | forall( dtype DT ) DT
|
---|
| 2810 | * ?=?( DT * restrict volatile *, DT * ),
|
---|
| 2811 | * ?=?( DT * restrict volatile *, void * ),
|
---|
| 2812 | * ?=?( DT * restrict volatile *, forall( dtype D ) D * ),
|
---|
| 2813 | * ?=?( DT * _Atomic restrict volatile *, DT * ),
|
---|
| 2814 | * ?=?( DT * _Atomic restrict volatile *, void * ),
|
---|
| 2815 | * ?=?( DT * _Atomic restrict volatile *, forall( dtype D ) D * );
|
---|
| 2816 |
|
---|
| 2817 | forall( dtype DT ) DT _Atomic
|
---|
| 2818 | * ?=?( _Atomic DT * restrict volatile *, DT _Atomic * ),
|
---|
| 2819 | * ?=?( _Atomic DT * restrict volatile *, void * ),
|
---|
| 2820 | * ?=?( _Atomic DT * restrict volatile *, forall( dtype D ) D * ),
|
---|
| 2821 | * ?=?( _Atomic DT * _Atomic restrict volatile *, DT _Atomic * ),
|
---|
| 2822 | * ?=?( _Atomic DT * _Atomic restrict volatile *, void * ),
|
---|
| 2823 | * ?=?( _Atomic DT * _Atomic restrict volatile *, forall( dtype D ) D * );
|
---|
| 2824 |
|
---|
| 2825 | forall( dtype DT ) DT const
|
---|
| 2826 | * ?=?( DT const * restrict volatile *, DT const * ),
|
---|
| 2827 | * ?=?( DT const * restrict volatile *, void const * ),
|
---|
| 2828 | * ?=?( DT const * restrict volatile *, forall( dtype D ) D * ),
|
---|
| 2829 | * ?=?( DT const * _Atomic restrict volatile *, DT const * ),
|
---|
| 2830 | * ?=?( DT const * _Atomic restrict volatile *, void const * ),
|
---|
| 2831 | * ?=?( DT const * _Atomic restrict volatile *, forall( dtype D ) D * );
|
---|
| 2832 |
|
---|
| 2833 | forall( dtype DT ) DT restrict
|
---|
| 2834 | * ?=?( restrict DT * restrict volatile *, DT restrict * ),
|
---|
| 2835 | * ?=?( restrict DT * restrict volatile *, void * ),
|
---|
| 2836 | * ?=?( restrict DT * restrict volatile *, forall( dtype D ) D * ),
|
---|
| 2837 | * ?=?( restrict DT * _Atomic restrict volatile *, DT restrict * ),
|
---|
| 2838 | * ?=?( restrict DT * _Atomic restrict volatile *, void * ),
|
---|
| 2839 | * ?=?( restrict DT * _Atomic restrict volatile *, forall( dtype D ) D * );
|
---|
| 2840 |
|
---|
| 2841 | forall( dtype DT ) DT volatile
|
---|
| 2842 | * ?=?( DT volatile * restrict volatile *, DT volatile * ),
|
---|
| 2843 | * ?=?( DT volatile * restrict volatile *, void volatile * ),
|
---|
| 2844 | * ?=?( DT volatile * restrict volatile *, forall( dtype D ) D * ),
|
---|
| 2845 | * ?=?( DT volatile * _Atomic restrict volatile *, DT volatile * ),
|
---|
| 2846 | * ?=?( DT volatile * _Atomic restrict volatile *, void volatile * ),
|
---|
| 2847 | * ?=?( DT volatile * _Atomic restrict volatile *, forall( dtype D ) D * );
|
---|
| 2848 |
|
---|
| 2849 | forall( dtype DT ) DT _Atomic const
|
---|
| 2850 | * ?=?( DT _Atomic const * restrict volatile *, DT _Atomic const * ),
|
---|
| 2851 | * ?=?( DT _Atomic const * restrict volatile *, void const * ),
|
---|
| 2852 | * ?=?( DT _Atomic const * restrict volatile *, forall( dtype D ) D * ),
|
---|
| 2853 | * ?=?( DT _Atomic const * _Atomic restrict volatile *, DT _Atomic const * ),
|
---|
| 2854 | * ?=?( DT _Atomic const * _Atomic restrict volatile *, void const * ),
|
---|
| 2855 | * ?=?( DT _Atomic const * _Atomic restrict volatile *, forall( dtype D ) D * );
|
---|
| 2856 |
|
---|
| 2857 | forall( dtype DT ) DT _Atomic restrict
|
---|
| 2858 | * ?=?( _Atomic restrict DT * restrict volatile *, DT _Atomic restrict * ),
|
---|
| 2859 | * ?=?( _Atomic restrict DT * restrict volatile *, void * ),
|
---|
| 2860 | * ?=?( _Atomic restrict DT * restrict volatile *, forall( dtype D ) D * ),
|
---|
| 2861 | * ?=?( _Atomic restrict DT * _Atomic restrict volatile *, DT _Atomic restrict * ),
|
---|
| 2862 | * ?=?( _Atomic restrict DT * _Atomic restrict volatile *, void * ),
|
---|
| 2863 | * ?=?( _Atomic restrict DT * _Atomic restrict volatile *, forall( dtype D ) D * );
|
---|
| 2864 |
|
---|
| 2865 | forall( dtype DT ) DT _Atomic volatile
|
---|
| 2866 | * ?=?( DT _Atomic volatile * restrict volatile *, DT _Atomic volatile * ),
|
---|
| 2867 | * ?=?( DT _Atomic volatile * restrict volatile *, void volatile * ),
|
---|
| 2868 | * ?=?( DT _Atomic volatile * restrict volatile *, forall( dtype D ) D * ),
|
---|
| 2869 | * ?=?( DT _Atomic volatile * _Atomic restrict volatile *, DT _Atomic volatile * ),
|
---|
| 2870 | * ?=?( DT _Atomic volatile * _Atomic restrict volatile *, void volatile * ),
|
---|
| 2871 | * ?=?( DT _Atomic volatile * _Atomic restrict volatile *, forall( dtype D ) D * );
|
---|
| 2872 |
|
---|
| 2873 | forall( dtype DT ) DT const restrict
|
---|
| 2874 | * ?=?( DT const restrict * restrict volatile *, DT const restrict * ),
|
---|
| 2875 | * ?=?( DT const restrict * restrict volatile *, void const * ),
|
---|
| 2876 | * ?=?( DT const restrict * restrict volatile *, forall( dtype D ) D * ),
|
---|
| 2877 | * ?=?( DT const restrict * _Atomic restrict volatile *, DT const restrict * ),
|
---|
| 2878 | * ?=?( DT const restrict * _Atomic restrict volatile *, void const * ),
|
---|
| 2879 | * ?=?( DT const restrict * _Atomic restrict volatile *, forall( dtype D ) D * );
|
---|
| 2880 |
|
---|
| 2881 | forall( dtype DT ) DT const volatile
|
---|
| 2882 | * ?=?( DT const volatile * restrict volatile *, DT const volatile * ),
|
---|
| 2883 | * ?=?( DT const volatile * restrict volatile *, void const volatile * ),
|
---|
| 2884 | * ?=?( DT const volatile * restrict volatile *, forall( dtype D ) D * ),
|
---|
| 2885 | * ?=?( DT const volatile * _Atomic restrict volatile *, DT const volatile * ),
|
---|
| 2886 | * ?=?( DT const volatile * _Atomic restrict volatile *, void const volatile * ),
|
---|
| 2887 | * ?=?( DT const volatile * _Atomic restrict volatile *, forall( dtype D ) D * );
|
---|
| 2888 |
|
---|
| 2889 | forall( dtype DT ) DT restrict volatile
|
---|
| 2890 | * ?=?( DT restrict volatile * restrict volatile *, DT restrict volatile * ),
|
---|
| 2891 | * ?=?( DT restrict volatile * restrict volatile *, void volatile * ),
|
---|
| 2892 | * ?=?( DT restrict volatile * restrict volatile *, forall( dtype D ) D * ),
|
---|
| 2893 | * ?=?( DT restrict volatile * _Atomic restrict volatile *, DT restrict volatile * ),
|
---|
| 2894 | * ?=?( DT restrict volatile * _Atomic restrict volatile *, void volatile * ),
|
---|
| 2895 | * ?=?( DT restrict volatile * _Atomic restrict volatile *, forall( dtype D ) D * );
|
---|
| 2896 |
|
---|
| 2897 | forall( dtype DT ) DT _Atomic const restrict
|
---|
| 2898 | * ?=?( DT _Atomic const restrict * restrict volatile *,
|
---|
| 2899 | DT _Atomic const restrict * ),
|
---|
| 2900 | * ?=?( DT _Atomic const restrict * restrict volatile *,
|
---|
| 2901 | void const * ),
|
---|
| 2902 | * ?=?( DT _Atomic const restrict * restrict volatile *,
|
---|
| 2903 | forall( dtype D ) D * ),
|
---|
| 2904 | * ?=?( DT _Atomic const restrict * _Atomic restrict volatile *,
|
---|
| 2905 | DT _Atomic const restrict * ),
|
---|
| 2906 | * ?=?( DT _Atomic const restrict * _Atomic restrict volatile *,
|
---|
| 2907 | void const * ),
|
---|
| 2908 | * ?=?( DT _Atomic const restrict * _Atomic restrict volatile *,
|
---|
| 2909 | forall( dtype D ) D * );
|
---|
| 2910 |
|
---|
| 2911 | forall( dtype DT ) DT _Atomic const volatile
|
---|
| 2912 | * ?=?( DT _Atomic const volatile * restrict volatile *,
|
---|
| 2913 | DT _Atomic const volatile * ),
|
---|
| 2914 | * ?=?( DT _Atomic const volatile * restrict volatile *,
|
---|
| 2915 | void const volatile * ),
|
---|
| 2916 | * ?=?( DT _Atomic const volatile * restrict volatile *,
|
---|
| 2917 | forall( dtype D ) D * ),
|
---|
| 2918 | * ?=?( DT _Atomic const volatile * _Atomic restrict volatile *,
|
---|
| 2919 | DT _Atomic const volatile * ),
|
---|
| 2920 | * ?=?( DT _Atomic const volatile * _Atomic restrict volatile *,
|
---|
| 2921 | void const volatile * ),
|
---|
| 2922 | * ?=?( DT _Atomic const volatile * _Atomic restrict volatile *,
|
---|
| 2923 | forall( dtype D ) D * );
|
---|
| 2924 |
|
---|
| 2925 | forall( dtype DT ) DT _Atomic restrict volatile
|
---|
| 2926 | * ?=?( DT _Atomic restrict volatile * restrict volatile *,
|
---|
| 2927 | DT _Atomic restrict volatile * ),
|
---|
| 2928 | * ?=?( DT _Atomic restrict volatile * restrict volatile *,
|
---|
| 2929 | void volatile * ),
|
---|
| 2930 | * ?=?( DT _Atomic restrict volatile * restrict volatile *,
|
---|
| 2931 | forall( dtype D ) D * ),
|
---|
| 2932 | * ?=?( DT _Atomic restrict volatile * _Atomic restrict volatile *,
|
---|
| 2933 | DT _Atomic restrict volatile * ),
|
---|
| 2934 | * ?=?( DT _Atomic restrict volatile * _Atomic restrict volatile *,
|
---|
| 2935 | void volatile * ),
|
---|
| 2936 | * ?=?( DT _Atomic restrict volatile * _Atomic restrict volatile *,
|
---|
| 2937 | forall( dtype D ) D * );
|
---|
| 2938 |
|
---|
| 2939 | forall( dtype DT ) DT const restrict volatile
|
---|
| 2940 | * ?=?( DT const restrict volatile * restrict volatile *,
|
---|
| 2941 | DT const restrict volatile * ),
|
---|
| 2942 | * ?=?( DT const restrict volatile * restrict volatile *,
|
---|
| 2943 | void const volatile * ),
|
---|
| 2944 | * ?=?( DT const restrict volatile * restrict volatile *,
|
---|
| 2945 | forall( dtype D ) D * ),
|
---|
| 2946 | * ?=?( DT const restrict volatile * _Atomic restrict volatile *,
|
---|
| 2947 | DT const restrict volatile * ),
|
---|
| 2948 | * ?=?( DT const restrict volatile * _Atomic restrict volatile *,
|
---|
| 2949 | void const volatile * ),
|
---|
| 2950 | * ?=?( DT const restrict volatile * _Atomic restrict volatile *,
|
---|
| 2951 | forall( dtype D ) D * );
|
---|
| 2952 |
|
---|
| 2953 | forall( dtype DT ) DT _Atomic const restrict volatile
|
---|
| 2954 | * ?=?( DT _Atomic const restrict volatile * restrict volatile *,
|
---|
| 2955 | DT _Atomic const restrict volatile * ),
|
---|
| 2956 | * ?=?( DT _Atomic const restrict volatile * restrict volatile *,
|
---|
| 2957 | void const volatile * ),
|
---|
| 2958 | * ?=?( DT _Atomic const restrict volatile * restrict volatile *,
|
---|
| 2959 | forall( dtype D ) D * ),
|
---|
| 2960 | * ?=?( DT _Atomic const restrict volatile * _Atomic restrict volatile *,
|
---|
| 2961 | DT _Atomic const restrict volatile * ),
|
---|
| 2962 | * ?=?( DT _Atomic const restrict volatile * _Atomic restrict volatile *,
|
---|
| 2963 | void const volatile * ),
|
---|
| 2964 | * ?=?( DT _Atomic const restrict volatile * _Atomic restrict volatile *,
|
---|
| 2965 | forall( dtype D ) D * );
|
---|
| 2966 |
|
---|
| 2967 | forall( dtype DT ) void
|
---|
| 2968 | * ?=?( void * restrict volatile *, DT * );
|
---|
| 2969 |
|
---|
| 2970 | forall( dtype DT ) void const
|
---|
| 2971 | * ?=?( void const * restrict volatile *, DT const * );
|
---|
| 2972 |
|
---|
| 2973 | forall( dtype DT ) void volatile
|
---|
| 2974 | * ?=?( void volatile * restrict volatile *, DT volatile * );
|
---|
| 2975 |
|
---|
| 2976 | forall( dtype DT ) void const volatile
|
---|
| 2977 | * ?=?( void const volatile * restrict volatile *, DT const volatile * );
|
---|
| 2978 | \end{lstlisting}
|
---|
| 2979 | \begin{rationale}
|
---|
| 2980 | The pattern of overloadings for simple assignment resembles that of pointer increment and decrement,
|
---|
| 2981 | except that the polymorphic pointer assignment functions declare a \lstinline$dtype$ parameter,
|
---|
| 2982 | instead of a \lstinline$type$ parameter, because the left operand may be a pointer to an incomplete
|
---|
| 2983 | type.
|
---|
| 2984 | \end{rationale}
|
---|
| 2985 |
|
---|
| 2986 | For every complete structure or union type \lstinline$S$ there exist
|
---|
| 2987 | % Don't use predefined: keep this out of prelude.cf.
|
---|
| 2988 | \begin{lstlisting}
|
---|
| 2989 | S ?=?( S volatile *, S ), ?=?( S _Atomic volatile *, S );
|
---|
| 2990 | \end{lstlisting}
|
---|
| 2991 |
|
---|
| 2992 | For every extended integer type \lstinline$X$ there exist
|
---|
| 2993 | % Don't use predefined: keep this out of prelude.cf.
|
---|
| 2994 | \begin{lstlisting}
|
---|
| 2995 | X ?=?( X volatile *, X ), ?=?( X _Atomic volatile *, X );
|
---|
| 2996 | \end{lstlisting}
|
---|
| 2997 |
|
---|
| 2998 | For every complete enumerated type \lstinline$E$ there exist
|
---|
| 2999 | % Don't use predefined: keep this out of prelude.cf.
|
---|
| 3000 | \begin{lstlisting}
|
---|
| 3001 | E ?=?( E volatile *, int ), ?=?( E _Atomic volatile *, int );
|
---|
| 3002 | \end{lstlisting}
|
---|
| 3003 | \begin{rationale}
|
---|
| 3004 | The right-hand argument is \lstinline$int$ because enumeration constants have type \lstinline$int$.
|
---|
| 3005 | \end{rationale}
|
---|
| 3006 |
|
---|
| 3007 | \semantics
|
---|
| 3008 | The structure assignment functions provide member-wise assignment; each non-array member and each
|
---|
| 3009 | element of each array member of the right argument is assigned to the corresponding member or
|
---|
| 3010 | element of the left argument using the assignment function defined for its type. All other
|
---|
| 3011 | assignment functions have the same effect as the corresponding C assignment expression.
|
---|
| 3012 | \begin{rationale}
|
---|
| 3013 | Note that, by default, union assignment\index{deficiencies!union assignment} uses C semantics---that
|
---|
| 3014 | is, bitwise copy---even if some of the union members have programmer-defined assignment functions.
|
---|
| 3015 | \end{rationale}
|
---|
| 3016 |
|
---|
| 3017 |
|
---|
| 3018 | \subsubsection{Compound assignment}
|
---|
| 3019 |
|
---|
[bfee448] | 3020 | \predefined
|
---|
[f60d997] | 3021 | \begin{lstlisting}
|
---|
| 3022 | forall( type T ) T
|
---|
| 3023 | * ?+=?( T * restrict volatile *, ptrdiff_t ),
|
---|
| 3024 | * ?-=?( T * restrict volatile *, ptrdiff_t ),
|
---|
| 3025 | * ?+=?( T * _Atomic restrict volatile *, ptrdiff_t ),
|
---|
| 3026 | * ?-=?( T * _Atomic restrict volatile *, ptrdiff_t );
|
---|
| 3027 |
|
---|
| 3028 | forall( type T ) T _Atomic
|
---|
| 3029 | * ?+=?( T _Atomic * restrict volatile *, ptrdiff_t ),
|
---|
| 3030 | * ?-=?( T _Atomic * restrict volatile *, ptrdiff_t ),
|
---|
| 3031 | * ?+=?( T _Atomic * _Atomic restrict volatile *, ptrdiff_t ),
|
---|
| 3032 | * ?-=?( T _Atomic * _Atomic restrict volatile *, ptrdiff_t );
|
---|
| 3033 |
|
---|
| 3034 | forall( type T ) T const
|
---|
| 3035 | * ?+=?( T const * restrict volatile *, ptrdiff_t ),
|
---|
| 3036 | * ?-=?( T const * restrict volatile *, ptrdiff_t ),
|
---|
| 3037 | * ?+=?( T const * _Atomic restrict volatile *, ptrdiff_t ),
|
---|
| 3038 | * ?-=?( T const * _Atomic restrict volatile *, ptrdiff_t );
|
---|
| 3039 |
|
---|
| 3040 | forall( type T ) T restrict
|
---|
| 3041 | * ?+=?( T restrict * restrict volatile *, ptrdiff_t ),
|
---|
| 3042 | * ?-=?( T restrict * restrict volatile *, ptrdiff_t ),
|
---|
| 3043 | * ?+=?( T restrict * _Atomic restrict volatile *, ptrdiff_t ),
|
---|
| 3044 | * ?-=?( T restrict * _Atomic restrict volatile *, ptrdiff_t );
|
---|
| 3045 |
|
---|
| 3046 | forall( type T ) T volatile
|
---|
| 3047 | * ?+=?( T volatile * restrict volatile *, ptrdiff_t ),
|
---|
| 3048 | * ?-=?( T volatile * restrict volatile *, ptrdiff_t ),
|
---|
| 3049 | * ?+=?( T volatile * _Atomic restrict volatile *, ptrdiff_t ),
|
---|
| 3050 | * ?-=?( T volatile * _Atomic restrict volatile *, ptrdiff_t );
|
---|
| 3051 |
|
---|
| 3052 | forall( type T ) T _Atomic const
|
---|
| 3053 | * ?+=?( T _Atomic const restrict volatile *, ptrdiff_t ),
|
---|
| 3054 | * ?-=?( T _Atomic const restrict volatile *, ptrdiff_t ),
|
---|
| 3055 | * ?+=?( T _Atomic const _Atomic restrict volatile *, ptrdiff_t ),
|
---|
| 3056 | * ?-=?( T _Atomic const _Atomic restrict volatile *, ptrdiff_t );
|
---|
| 3057 |
|
---|
| 3058 | forall( type T ) T _Atomic restrict
|
---|
| 3059 | * ?+=?( T _Atomic restrict * restrict volatile *, ptrdiff_t ),
|
---|
| 3060 | * ?-=?( T _Atomic restrict * restrict volatile *, ptrdiff_t ),
|
---|
| 3061 | * ?+=?( T _Atomic restrict * _Atomic restrict volatile *, ptrdiff_t ),
|
---|
| 3062 | * ?-=?( T _Atomic restrict * _Atomic restrict volatile *, ptrdiff_t );
|
---|
| 3063 |
|
---|
| 3064 | forall( type T ) T _Atomic volatile
|
---|
| 3065 | * ?+=?( T _Atomic volatile * restrict volatile *, ptrdiff_t ),
|
---|
| 3066 | * ?-=?( T _Atomic volatile * restrict volatile *, ptrdiff_t ),
|
---|
| 3067 | * ?+=?( T _Atomic volatile * _Atomic restrict volatile *, ptrdiff_t ),
|
---|
| 3068 | * ?-=?( T _Atomic volatile * _Atomic restrict volatile *, ptrdiff_t );
|
---|
| 3069 |
|
---|
| 3070 | forall( type T ) T const restrict
|
---|
| 3071 | * ?+=?( T const restrict * restrict volatile *, ptrdiff_t ),
|
---|
| 3072 | * ?-=?( T const restrict * restrict volatile *, ptrdiff_t ),
|
---|
| 3073 | * ?+=?( T const restrict * _Atomic restrict volatile *, ptrdiff_t ),
|
---|
| 3074 | * ?-=?( T const restrict * _Atomic restrict volatile *, ptrdiff_t );
|
---|
| 3075 |
|
---|
| 3076 | forall( type T ) T const volatile
|
---|
| 3077 | * ?+=?( T const volatile * restrict volatile *, ptrdiff_t ),
|
---|
| 3078 | * ?-=?( T const volatile * restrict volatile *, ptrdiff_t ),
|
---|
| 3079 | * ?+=?( T const volatile * _Atomic restrict volatile *, ptrdiff_t ),
|
---|
| 3080 | * ?-=?( T const volatile * _Atomic restrict volatile *, ptrdiff_t );
|
---|
| 3081 |
|
---|
| 3082 | forall( type T ) T restrict volatile
|
---|
| 3083 | * ?+=?( T restrict volatile * restrict volatile *, ptrdiff_t ),
|
---|
| 3084 | * ?-=?( T restrict volatile * restrict volatile *, ptrdiff_t ),
|
---|
| 3085 | * ?+=?( T restrict volatile * _Atomic restrict volatile *, ptrdiff_t ),
|
---|
| 3086 | * ?-=?( T restrict volatile * _Atomic restrict volatile *, ptrdiff_t );
|
---|
| 3087 |
|
---|
| 3088 | forall( type T ) T _Atomic const restrict
|
---|
| 3089 | * ?+=?( T _Atomic const restrict * restrict volatile *, ptrdiff_t ),
|
---|
| 3090 | * ?-=?( T _Atomic const restrict * restrict volatile *, ptrdiff_t ),
|
---|
| 3091 | * ?+=?( T _Atomic const restrict * _Atomic restrict volatile *, ptrdiff_t ),
|
---|
| 3092 | * ?-=?( T _Atomic const restrict * _Atomic restrict volatile *, ptrdiff_t );
|
---|
| 3093 |
|
---|
| 3094 | forall( type T ) T _Atomic const volatile
|
---|
| 3095 | * ?+=?( T _Atomic const volatile * restrict volatile *, ptrdiff_t ),
|
---|
| 3096 | * ?-=?( T _Atomic const volatile * restrict volatile *, ptrdiff_t ),
|
---|
| 3097 | * ?+=?( T _Atomic const volatile * _Atomic restrict volatile *, ptrdiff_t ),
|
---|
| 3098 | * ?-=?( T _Atomic const volatile * _Atomic restrict volatile *, ptrdiff_t );
|
---|
| 3099 |
|
---|
| 3100 | forall( type T ) T _Atomic restrict volatile
|
---|
| 3101 | * ?+=?( T _Atomic restrict volatile * restrict volatile *, ptrdiff_t ),
|
---|
| 3102 | * ?-=?( T _Atomic restrict volatile * restrict volatile *, ptrdiff_t ),
|
---|
| 3103 | * ?+=?( T _Atomic restrict volatile * _Atomic restrict volatile *, ptrdiff_t ),
|
---|
| 3104 | * ?-=?( T _Atomic restrict volatile * _Atomic restrict volatile *, ptrdiff_t );
|
---|
| 3105 |
|
---|
| 3106 | forall( type T ) T const restrict volatile
|
---|
| 3107 | * ?+=?( T const restrict volatile * restrict volatile *, ptrdiff_t ),
|
---|
| 3108 | * ?-=?( T const restrict volatile * restrict volatile *, ptrdiff_t ),
|
---|
| 3109 | * ?+=?( T const restrict volatile * _Atomic restrict volatile *, ptrdiff_t ),
|
---|
| 3110 | * ?-=?( T const restrict volatile * _Atomic restrict volatile *, ptrdiff_t );
|
---|
| 3111 |
|
---|
| 3112 | forall( type T ) T _Atomic const restrict volatile
|
---|
| 3113 | * ?+=?( T _Atomic const restrict volatile * restrict volatile *, ptrdiff_t ),
|
---|
| 3114 | * ?-=?( T _Atomic const restrict volatile * restrict volatile *, ptrdiff_t ),
|
---|
| 3115 | * ?+=?( T _Atomic const restrict volatile * _Atomic restrict volatile *, ptrdiff_t ),
|
---|
| 3116 | * ?-=?( T _Atomic const restrict volatile * _Atomic restrict volatile *, ptrdiff_t );
|
---|
| 3117 |
|
---|
| 3118 | _Bool
|
---|
| 3119 | ?*=?( _Bool volatile *, _Bool ),
|
---|
| 3120 | ?/=?( _Bool volatile *, _Bool ),
|
---|
| 3121 | ?+=?( _Bool volatile *, _Bool ),
|
---|
| 3122 | ?-=?( _Bool volatile *, _Bool ),
|
---|
| 3123 | ?%=?( _Bool volatile *, _Bool ),
|
---|
| 3124 | ?<<=?( _Bool volatile *, int ),
|
---|
| 3125 | ?>>=?( _Bool volatile *, int ),
|
---|
| 3126 | ?&=?( _Bool volatile *, _Bool ),
|
---|
| 3127 | ?^=?( _Bool volatile *, _Bool ),
|
---|
| 3128 | ?|=?( _Bool volatile *, _Bool );
|
---|
| 3129 | char
|
---|
| 3130 | ?*=?( char volatile *, char ),
|
---|
| 3131 | ?/=?( char volatile *, char ),
|
---|
| 3132 | ?+=?( char volatile *, char ),
|
---|
| 3133 | ?-=?( char volatile *, char ),
|
---|
| 3134 | ?%=?( char volatile *, char ),
|
---|
| 3135 | ?<<=?( char volatile *, int ),
|
---|
| 3136 | ?>>=?( char volatile *, int ),
|
---|
| 3137 | ?&=?( char volatile *, char ),
|
---|
| 3138 | ?^=?( char volatile *, char ),
|
---|
| 3139 | ?|=?( char volatile *, char );
|
---|
| 3140 | unsigned char
|
---|
| 3141 | ?*=?( unsigned char volatile *, unsigned char ),
|
---|
| 3142 | ?/=?( unsigned char volatile *, unsigned char ),
|
---|
| 3143 | ?+=?( unsigned char volatile *, unsigned char ),
|
---|
| 3144 | ?-=?( unsigned char volatile *, unsigned char ),
|
---|
| 3145 | ?%=?( unsigned char volatile *, unsigned char ),
|
---|
| 3146 | ?<<=?( unsigned char volatile *, int ),
|
---|
| 3147 | ?>>=?( unsigned char volatile *, int ),
|
---|
| 3148 | ?&=?( unsigned char volatile *, unsigned char ),
|
---|
| 3149 | ?^=?( unsigned char volatile *, unsigned char ),
|
---|
| 3150 | ?|=?( unsigned char volatile *, unsigned char );
|
---|
| 3151 | signed char
|
---|
| 3152 | ?*=?( signed char volatile *, signed char ),
|
---|
| 3153 | ?/=?( signed char volatile *, signed char ),
|
---|
| 3154 | ?+=?( signed char volatile *, signed char ),
|
---|
| 3155 | ?-=?( signed char volatile *, signed char ),
|
---|
| 3156 | ?%=?( signed char volatile *, signed char ),
|
---|
| 3157 | ?<<=?( signed char volatile *, int ),
|
---|
| 3158 | ?>>=?( signed char volatile *, int ),
|
---|
| 3159 | ?&=?( signed char volatile *, signed char ),
|
---|
| 3160 | ?^=?( signed char volatile *, signed char ),
|
---|
| 3161 | ?|=?( signed char volatile *, signed char );
|
---|
| 3162 | short int
|
---|
| 3163 | ?*=?( short int volatile *, short int ),
|
---|
| 3164 | ?/=?( short int volatile *, short int ),
|
---|
| 3165 | ?+=?( short int volatile *, short int ),
|
---|
| 3166 | ?-=?( short int volatile *, short int ),
|
---|
| 3167 | ?%=?( short int volatile *, short int ),
|
---|
| 3168 | ?<<=?( short int volatile *, int ),
|
---|
| 3169 | ?>>=?( short int volatile *, int ),
|
---|
| 3170 | ?&=?( short int volatile *, short int ),
|
---|
| 3171 | ?^=?( short int volatile *, short int ),
|
---|
| 3172 | ?|=?( short int volatile *, short int );
|
---|
| 3173 | unsigned short int
|
---|
| 3174 | ?*=?( unsigned short int volatile *, unsigned short int ),
|
---|
| 3175 | ?/=?( unsigned short int volatile *, unsigned short int ),
|
---|
| 3176 | ?+=?( unsigned short int volatile *, unsigned short int ),
|
---|
| 3177 | ?-=?( unsigned short int volatile *, unsigned short int ),
|
---|
| 3178 | ?%=?( unsigned short int volatile *, unsigned short int ),
|
---|
| 3179 | ?<<=?( unsigned short int volatile *, int ),
|
---|
| 3180 | ?>>=?( unsigned short int volatile *, int ),
|
---|
| 3181 | ?&=?( unsigned short int volatile *, unsigned short int ),
|
---|
| 3182 | ?^=?( unsigned short int volatile *, unsigned short int ),
|
---|
| 3183 | ?|=?( unsigned short int volatile *, unsigned short int );
|
---|
| 3184 | int
|
---|
| 3185 | ?*=?( int volatile *, int ),
|
---|
| 3186 | ?/=?( int volatile *, int ),
|
---|
| 3187 | ?+=?( int volatile *, int ),
|
---|
| 3188 | ?-=?( int volatile *, int ),
|
---|
| 3189 | ?%=?( int volatile *, int ),
|
---|
| 3190 | ?<<=?( int volatile *, int ),
|
---|
| 3191 | ?>>=?( int volatile *, int ),
|
---|
| 3192 | ?&=?( int volatile *, int ),
|
---|
| 3193 | ?^=?( int volatile *, int ),
|
---|
| 3194 | ?|=?( int volatile *, int );
|
---|
| 3195 | unsigned int
|
---|
| 3196 | ?*=?( unsigned int volatile *, unsigned int ),
|
---|
| 3197 | ?/=?( unsigned int volatile *, unsigned int ),
|
---|
| 3198 | ?+=?( unsigned int volatile *, unsigned int ),
|
---|
| 3199 | ?-=?( unsigned int volatile *, unsigned int ),
|
---|
| 3200 | ?%=?( unsigned int volatile *, unsigned int ),
|
---|
| 3201 | ?<<=?( unsigned int volatile *, int ),
|
---|
| 3202 | ?>>=?( unsigned int volatile *, int ),
|
---|
| 3203 | ?&=?( unsigned int volatile *, unsigned int ),
|
---|
| 3204 | ?^=?( unsigned int volatile *, unsigned int ),
|
---|
| 3205 | ?|=?( unsigned int volatile *, unsigned int );
|
---|
| 3206 | long int
|
---|
| 3207 | ?*=?( long int volatile *, long int ),
|
---|
| 3208 | ?/=?( long int volatile *, long int ),
|
---|
| 3209 | ?+=?( long int volatile *, long int ),
|
---|
| 3210 | ?-=?( long int volatile *, long int ),
|
---|
| 3211 | ?%=?( long int volatile *, long int ),
|
---|
| 3212 | ?<<=?( long int volatile *, int ),
|
---|
| 3213 | ?>>=?( long int volatile *, int ),
|
---|
| 3214 | ?&=?( long int volatile *, long int ),
|
---|
| 3215 | ?^=?( long int volatile *, long int ),
|
---|
| 3216 | ?|=?( long int volatile *, long int );
|
---|
| 3217 | unsigned long int
|
---|
| 3218 | ?*=?( unsigned long int volatile *, unsigned long int ),
|
---|
| 3219 | ?/=?( unsigned long int volatile *, unsigned long int ),
|
---|
| 3220 | ?+=?( unsigned long int volatile *, unsigned long int ),
|
---|
| 3221 | ?-=?( unsigned long int volatile *, unsigned long int ),
|
---|
| 3222 | ?%=?( unsigned long int volatile *, unsigned long int ),
|
---|
| 3223 | ?<<=?( unsigned long int volatile *, int ),
|
---|
| 3224 | ?>>=?( unsigned long int volatile *, int ),
|
---|
| 3225 | ?&=?( unsigned long int volatile *, unsigned long int ),
|
---|
| 3226 | ?^=?( unsigned long int volatile *, unsigned long int ),
|
---|
| 3227 | ?|=?( unsigned long int volatile *, unsigned long int );
|
---|
| 3228 | long long int
|
---|
| 3229 | ?*=?( long long int volatile *, long long int ),
|
---|
| 3230 | ?/=?( long long int volatile *, long long int ),
|
---|
| 3231 | ?+=?( long long int volatile *, long long int ),
|
---|
| 3232 | ?-=?( long long int volatile *, long long int ),
|
---|
| 3233 | ?%=?( long long int volatile *, long long int ),
|
---|
| 3234 | ?<<=?( long long int volatile *, int ),
|
---|
| 3235 | ?>>=?( long long int volatile *, int ),
|
---|
| 3236 | ?&=?( long long int volatile *, long long int ),
|
---|
| 3237 | ?^=?( long long int volatile *, long long int ),
|
---|
| 3238 | ?|=?( long long int volatile *, long long int );
|
---|
| 3239 | unsigned long long int
|
---|
| 3240 | ?*=?( unsigned long long int volatile *, unsigned long long int ),
|
---|
| 3241 | ?/=?( unsigned long long int volatile *, unsigned long long int ),
|
---|
| 3242 | ?+=?( unsigned long long int volatile *, unsigned long long int ),
|
---|
| 3243 | ?-=?( unsigned long long int volatile *, unsigned long long int ),
|
---|
| 3244 | ?%=?( unsigned long long int volatile *, unsigned long long int ),
|
---|
| 3245 | ?<<=?( unsigned long long int volatile *, int ),
|
---|
| 3246 | ?>>=?( unsigned long long int volatile *, int ),
|
---|
| 3247 | ?&=?( unsigned long long int volatile *, unsigned long long int ),
|
---|
| 3248 | ?^=?( unsigned long long int volatile *, unsigned long long int ),
|
---|
| 3249 | ?|=?( unsigned long long int volatile *, unsigned long long int );
|
---|
| 3250 | float
|
---|
| 3251 | ?*=?( float volatile *, float ),
|
---|
| 3252 | ?/=?( float volatile *, float ),
|
---|
| 3253 | ?+=?( float volatile *, float ),
|
---|
| 3254 | ?-=?( float volatile *, float );
|
---|
| 3255 | double
|
---|
| 3256 | ?*=?( double volatile *, double ),
|
---|
| 3257 | ?/=?( double volatile *, double ),
|
---|
| 3258 | ?+=?( double volatile *, double ),
|
---|
| 3259 | ?-=?( double volatile *, double );
|
---|
| 3260 | long double
|
---|
| 3261 | ?*=?( long double volatile *, long double ),
|
---|
| 3262 | ?/=?( long double volatile *, long double ),
|
---|
| 3263 | ?+=?( long double volatile *, long double ),
|
---|
| 3264 | ?-=?( long double volatile *, long double );
|
---|
| 3265 | _Complex float
|
---|
| 3266 | ?*=?( _Complex float volatile *, _Complex float ),
|
---|
| 3267 | ?/=?( _Complex float volatile *, _Complex float ),
|
---|
| 3268 | ?+=?( _Complex float volatile *, _Complex float ),
|
---|
| 3269 | ?-=?( _Complex float volatile *, _Complex float );
|
---|
| 3270 | _Complex double
|
---|
| 3271 | ?*=?( _Complex double volatile *, _Complex double ),
|
---|
| 3272 | ?/=?( _Complex double volatile *, _Complex double ),
|
---|
| 3273 | ?+=?( _Complex double volatile *, _Complex double ),
|
---|
| 3274 | ?-=?( _Complex double volatile *, _Complex double );
|
---|
| 3275 | _Complex long double
|
---|
| 3276 | ?*=?( _Complex long double volatile *, _Complex long double ),
|
---|
| 3277 | ?/=?( _Complex long double volatile *, _Complex long double ),
|
---|
| 3278 | ?+=?( _Complex long double volatile *, _Complex long double ),
|
---|
| 3279 | ?-=?( _Complex long double volatile *, _Complex long double );
|
---|
| 3280 | \end{lstlisting}
|
---|
| 3281 |
|
---|
| 3282 | For every extended integer type \lstinline$X$ there exist
|
---|
| 3283 | % Don't use predefined: keep this out of prelude.cf.
|
---|
| 3284 | \begin{lstlisting}
|
---|
| 3285 | ?*=?( X volatile *, X ),
|
---|
| 3286 | ?/=?( X volatile *, X ),
|
---|
| 3287 | ?+=?( X volatile *, X ),
|
---|
| 3288 | ?-=?( X volatile *, X ),
|
---|
| 3289 | ?%=?( X volatile *, X ),
|
---|
| 3290 | ?<<=?( X volatile *, int ),
|
---|
| 3291 | ?>>=?( X volatile *, int ),
|
---|
| 3292 | ?&=?( X volatile *, X ),
|
---|
| 3293 | ?^=?( X volatile *, X ),
|
---|
| 3294 | ?|=?( X volatile *, X );
|
---|
| 3295 | \end{lstlisting}
|
---|
| 3296 |
|
---|
| 3297 | For every complete enumerated type \lstinline$E$ there exist
|
---|
| 3298 | % Don't use predefined: keep this out of prelude.cf.
|
---|
| 3299 | \begin{lstlisting}
|
---|
| 3300 | ?*=?( E volatile *, E ),
|
---|
| 3301 | ?/=?( E volatile *, E ),
|
---|
| 3302 | ?+=?( E volatile *, E ),
|
---|
| 3303 | ?-=?( E volatile *, E ),
|
---|
| 3304 | ?%=?( E volatile *, E ),
|
---|
| 3305 | ?<<=?( E volatile *, int ),
|
---|
| 3306 | ?>>=?( E volatile *, int ),
|
---|
| 3307 | ?&=?( E volatile *, E ),
|
---|
| 3308 | ?^=?( E volatile *, E ),
|
---|
| 3309 | ?|=?( E volatile *, E );
|
---|
| 3310 | \end{lstlisting}
|
---|
| 3311 |
|
---|
| 3312 |
|
---|
| 3313 | \subsection{Comma operator}
|
---|
| 3314 |
|
---|
| 3315 | \begin{syntax}
|
---|
| 3316 | \lhs{expression}
|
---|
| 3317 | \rhs \nonterm{assignment-expression}
|
---|
| 3318 | \rhs \nonterm{expression} \lstinline$,$ \nonterm{assignment-expression}
|
---|
| 3319 | \end{syntax}
|
---|
| 3320 |
|
---|
| 3321 | \semantics
|
---|
| 3322 | In the comma expression ``\lstinline$a, b$'', the first operand is interpreted as
|
---|
| 3323 | ``\lstinline$( void )(a)$'', which shall be unambiguous\index{ambiguous interpretation}. The
|
---|
| 3324 | interpretations of the expression are the interpretations of the second operand.
|
---|
| 3325 |
|
---|
| 3326 |
|
---|
| 3327 | \section{Constant expressions}
|
---|
| 3328 |
|
---|
| 3329 |
|
---|
| 3330 | \section{Declarations}
|
---|
| 3331 |
|
---|
| 3332 | \begin{syntax}
|
---|
| 3333 | \oldlhs{declaration}
|
---|
| 3334 | \rhs \nonterm{type-declaration}
|
---|
| 3335 | \rhs \nonterm{spec-definition}
|
---|
| 3336 | \end{syntax}
|
---|
| 3337 |
|
---|
| 3338 | \constraints
|
---|
[2fc0e5c] | 3339 | If an identifier has \Index{no linkage}, there shall be no more than one declaration of the
|
---|
| 3340 | identifier ( in a declarator or type specifier ) with compatible types in the same scope and in the
|
---|
| 3341 | same name space, except that:
|
---|
[f60d997] | 3342 | \begin{itemize}
|
---|
| 3343 | \item
|
---|
| 3344 | a typedef name may be redefined to denote the same type as it currently does, provided that type is
|
---|
| 3345 | not a variably modified type;
|
---|
| 3346 | \item
|
---|
| 3347 | tags may be redeclared as specified in section 6.7.2.3 of the {\c11} standard.
|
---|
| 3348 | \end{itemize}
|
---|
| 3349 | \begin{rationale}
|
---|
| 3350 | This constraint adds the phrase ``with compatible types'' to the {\c11} constraint, to allow
|
---|
| 3351 | overloading.
|
---|
| 3352 | \end{rationale}
|
---|
| 3353 |
|
---|
| 3354 | An identifier declared by a type declaration shall not be redeclared as a parameter in a function
|
---|
| 3355 | definition whose declarator includes an identifier list.
|
---|
| 3356 | \begin{rationale}
|
---|
| 3357 | This restriction echos {\c11}'s ban on the redeclaration of typedef names as parameters. This
|
---|
| 3358 | avoids an ambiguity between old-style function declarations and new-style function prototypes:
|
---|
| 3359 | \begin{lstlisting}
|
---|
| 3360 | void f( Complex, // ... 3000 characters ...
|
---|
| 3361 | void g( Complex, // ... 3000 characters ...
|
---|
| 3362 | int Complex; { ... }
|
---|
| 3363 | \end{lstlisting}
|
---|
| 3364 | Without the rule, \lstinline$Complex$ would be a type in the first case, and a parameter name in the
|
---|
| 3365 | second.
|
---|
| 3366 | \end{rationale}
|
---|
| 3367 |
|
---|
| 3368 |
|
---|
| 3369 | \setcounter{subsection}{1}
|
---|
| 3370 | \subsection{Type specifiers}
|
---|
| 3371 |
|
---|
| 3372 | \begin{syntax}
|
---|
| 3373 | \oldlhs{type-specifier}
|
---|
| 3374 | \rhs \nonterm{forall-specifier}
|
---|
| 3375 | \end{syntax}
|
---|
| 3376 |
|
---|
| 3377 | \semantics
|
---|
| 3378 | Forall specifiers are discussed in \VRef{forall}.
|
---|
| 3379 |
|
---|
| 3380 |
|
---|
| 3381 | \subsubsection{Structure and union specifiers}
|
---|
| 3382 |
|
---|
| 3383 | \semantics
|
---|
| 3384 | \CFA extends the {\c11} definition of \define{anonymous structure} to include structure
|
---|
| 3385 | specifiers with tags, and extends the {\c11} definition of \define{anonymous union} to include union
|
---|
| 3386 | specifiers with tags.
|
---|
| 3387 | \begin{rationale}
|
---|
| 3388 | This extension imitates an extension in the Plan 9 C compiler \cite{Thompson90new}.
|
---|
| 3389 | \end{rationale}
|
---|
| 3390 |
|
---|
| 3391 | \examples
|
---|
| 3392 | \begin{lstlisting}
|
---|
| 3393 | struct point {@\impl{point}@
|
---|
| 3394 | int x, y;
|
---|
| 3395 | };
|
---|
| 3396 | struct color_point {@\impl{color_point}@
|
---|
| 3397 | enum { RED, BLUE, GREEN } color;
|
---|
| 3398 | struct point;
|
---|
| 3399 | };
|
---|
| 3400 | struct color_point cp;
|
---|
| 3401 | cp.x = 0;
|
---|
| 3402 | cp.color = RED;
|
---|
| 3403 |
|
---|
| 3404 | struct literal {@\impl{literal}@
|
---|
| 3405 | enum { NUMBER, STRING } tag;
|
---|
| 3406 | union {
|
---|
| 3407 | double n;
|
---|
| 3408 | char *s;
|
---|
| 3409 | };
|
---|
| 3410 | };
|
---|
| 3411 | struct literal *next;
|
---|
| 3412 | int length;
|
---|
| 3413 | extern int strlen( const char * );
|
---|
| 3414 | ...
|
---|
| 3415 | if ( next->tag == STRING ) length = strlen( next->s );
|
---|
| 3416 | \end{lstlisting}
|
---|
| 3417 |
|
---|
| 3418 |
|
---|
| 3419 | \setcounter{subsubsection}{4}
|
---|
[41b3ddd] | 3420 | \subsubsection{Forall specifiers}
|
---|
| 3421 | \label{forall}
|
---|
[f60d997] | 3422 |
|
---|
| 3423 | \begin{syntax}
|
---|
| 3424 | \lhs{forall-specifier}
|
---|
| 3425 | \rhs \lstinline$forall$ \lstinline$($ \nonterm{type-parameter-list} \lstinline$)$
|
---|
| 3426 | \end{syntax}
|
---|
| 3427 |
|
---|
[41b3ddd] | 3428 | \begin{comment}
|
---|
[f60d997] | 3429 | \constraints
|
---|
| 3430 | If the \nonterm{declaration-specifiers} of a declaration that contains a \nonterm{forall-specifier}
|
---|
| 3431 | declares a structure or union tag, the types of the members of the structure or union shall not use
|
---|
| 3432 | any of the type identifiers declared by the \nonterm{type-parameter-list}.
|
---|
| 3433 | \begin{rationale}
|
---|
| 3434 | This sort of declaration is illegal because the scope of the type identifiers ends at the end of the
|
---|
| 3435 | declaration, but the scope of the structure tag does not.
|
---|
| 3436 | \begin{lstlisting}
|
---|
| 3437 | forall( type T ) struct Pair { T a, b; } mkPair( T, T ); // illegal
|
---|
| 3438 | \end{lstlisting}
|
---|
| 3439 | If an instance of \lstinline$struct Pair$ was declared later in the current scope, what would the
|
---|
| 3440 | members' type be?
|
---|
| 3441 | \end{rationale}
|
---|
[41b3ddd] | 3442 | \end{comment}
|
---|
[f60d997] | 3443 |
|
---|
| 3444 | \semantics
|
---|
| 3445 | The \nonterm{type-parameter-list}s and assertions of the \nonterm{forall-specifier}s declare type
|
---|
[2fc0e5c] | 3446 | identifiers, function and object identifiers with \Index{no linkage}.
|
---|
[f60d997] | 3447 |
|
---|
[41b3ddd] | 3448 | If, in the declaration ``\lstinline$T D$'', \lstinline$T$ contains \nonterm{forall-specifier}s and
|
---|
| 3449 | \lstinline$D$ has the form
|
---|
[f60d997] | 3450 | \begin{lstlisting}
|
---|
| 3451 | D( @\normalsize\nonterm{parameter-type-list}@ )
|
---|
| 3452 | \end{lstlisting}
|
---|
| 3453 | then a type identifier declared by one of the \nonterm{forall-specifier}s is an \define{inferred
|
---|
[2fc0e5c] | 3454 | parameter} of the function declarator if and only if it is not an inferred parameter of a function
|
---|
[f60d997] | 3455 | declarator in \lstinline$D$, and it is used in the type of a parameter in the following
|
---|
| 3456 | \nonterm{type-parameter-list} or it and an inferred parameter are used as arguments of a
|
---|
[2fc0e5c] | 3457 | \Index{specification} in one of the \nonterm{forall-specifier}s. The identifiers declared by
|
---|
| 3458 | assertions that use an inferred parameter of a function declarator are \Index{assertion parameter}s
|
---|
| 3459 | of that function declarator.
|
---|
[41b3ddd] | 3460 |
|
---|
| 3461 | \begin{comment}
|
---|
[f60d997] | 3462 | \begin{rationale}
|
---|
| 3463 | Since every inferred parameter is used by some parameter, inference can be understood as a single
|
---|
| 3464 | bottom-up pass over the expression tree, that only needs to apply local reasoning at each node.
|
---|
| 3465 |
|
---|
| 3466 | If this restriction were lifted, it would be possible to write
|
---|
| 3467 | \begin{lstlisting}
|
---|
| 3468 | forall( type T ) T * alloc( void );@\use{alloc}@
|
---|
| 3469 | int *p = alloc();
|
---|
| 3470 | \end{lstlisting}
|
---|
| 3471 | Here \lstinline$alloc()$ would receive \lstinline$int$ as an inferred argument, and return an
|
---|
| 3472 | \lstinline$int *$. In general, if a call to \lstinline$alloc()$ is a subexpression of an expression
|
---|
| 3473 | involving polymorphic functions and overloaded identifiers, there could be considerable distance
|
---|
| 3474 | between the call and the subexpression that causes \lstinline$T$ to be bound.
|
---|
| 3475 |
|
---|
| 3476 | With the current restriction, \lstinline$alloc()$ must be given an argument that determines
|
---|
| 3477 | \lstinline$T$:
|
---|
| 3478 | \begin{lstlisting}
|
---|
| 3479 | forall( type T ) T * alloc( T initial_value );@\use{alloc}@
|
---|
| 3480 | \end{lstlisting}
|
---|
| 3481 | \end{rationale}
|
---|
[41b3ddd] | 3482 | \end{comment}
|
---|
[f60d997] | 3483 |
|
---|
| 3484 | If a function declarator is part of a function definition, its inferred parameters and assertion
|
---|
[2fc0e5c] | 3485 | parameters have \Index{block scope}; otherwise, identifiers declared by assertions have a
|
---|
[f60d997] | 3486 | \define{declaration scope}, which terminates at the end of the \nonterm{declaration}.
|
---|
| 3487 |
|
---|
| 3488 | A function type that has at least one inferred parameter is a \define{polymorphic function} type.
|
---|
| 3489 | Function types with no inferred parameters are \define{monomorphic function} types. One function
|
---|
| 3490 | type is \define{less polymorphic} than another if it has fewer inferred parameters, or if it has the
|
---|
| 3491 | same number of inferred parameters and fewer of its explicit parameters have types that depend on an
|
---|
| 3492 | inferred parameter.
|
---|
| 3493 |
|
---|
| 3494 | The names of inferred parameters and the order of identifiers in forall specifiers are not relevant
|
---|
| 3495 | to polymorphic function type compatibility. Let $f$ and $g$ be two polymorphic function types with
|
---|
| 3496 | the same number of inferred parameters, and let $f_i$ and $g_i$ be the inferred parameters of $f$
|
---|
| 3497 | and $g$ in their order of occurance in the function types' \nonterm{parameter-type-list}s. Let $f'$
|
---|
| 3498 | be $f$ with every occurrence of $f_i$ replaced by $g_i$, for all $i$. Then $f$ and $g$ are
|
---|
[2fc0e5c] | 3499 | \Index{compatible type}s if $f'$'s and $g$'s return types and parameter lists are compatible, and if
|
---|
| 3500 | for every assertion parameter of $f'$ there is an assertion parameter in $g$ with the same
|
---|
| 3501 | identifier and compatible type, and vice versa.
|
---|
[f60d997] | 3502 |
|
---|
| 3503 | \examples
|
---|
| 3504 | Consider these analogous monomorphic and polymorphic declarations.
|
---|
| 3505 | \begin{lstlisting}
|
---|
| 3506 | int fi( int );
|
---|
| 3507 | forall( type T ) T fT( T );
|
---|
| 3508 | \end{lstlisting}
|
---|
| 3509 | \lstinline$fi()$ takes an \lstinline$int$ and returns an \lstinline$int$. \lstinline$fT()$ takes a
|
---|
| 3510 | \lstinline$T$ and returns a \lstinline$T$, for any type \lstinline$T$.
|
---|
| 3511 | \begin{lstlisting}
|
---|
| 3512 | int (*pfi )( int ) = fi;
|
---|
| 3513 | forall( type T ) T (*pfT )( T ) = fT;
|
---|
| 3514 | \end{lstlisting}
|
---|
| 3515 | \lstinline$pfi$ and \lstinline$pfT$ are pointers to functions. \lstinline$pfT$ is not
|
---|
| 3516 | polymorphic, but the function it points at is.
|
---|
| 3517 | \begin{lstlisting}
|
---|
| 3518 | int (*fvpfi( void ))( int ) {
|
---|
| 3519 | return pfi;
|
---|
| 3520 | }
|
---|
| 3521 | forall( type T ) T (*fvpfT( void ))( T ) {
|
---|
| 3522 | return pfT;
|
---|
| 3523 | }
|
---|
| 3524 | \end{lstlisting}
|
---|
| 3525 | \lstinline$fvpfi()$ and \lstinline$fvpfT()$ are functions taking no arguments and returning pointers
|
---|
| 3526 | to functions. \lstinline$fvpfT()$ is monomorphic, but the function that its return value points
|
---|
| 3527 | at is polymorphic.
|
---|
| 3528 | \begin{lstlisting}
|
---|
| 3529 | forall( type T ) int ( *fTpfi( T ) )( int );
|
---|
| 3530 | forall( type T ) T ( *fTpfT( T ) )( T );
|
---|
| 3531 | forall( type T, type U ) U ( *fTpfU( T ) )( U );
|
---|
| 3532 | \end{lstlisting}
|
---|
| 3533 | \lstinline$fTpfi()$ is a polymorphic function that returns a pointer to a monomorphic function
|
---|
| 3534 | taking an integer and returning an integer. It could return \lstinline$pfi$. \lstinline$fTpfT()$
|
---|
| 3535 | is subtle: it is a polymorphic function returning a \emph{monomorphic} function taking and returning
|
---|
| 3536 | \lstinline$T$, where \lstinline$T$ is an inferred parameter of \lstinline$fTpfT()$. For instance,
|
---|
| 3537 | in the expression ``\lstinline$fTpfT(17)$'', \lstinline$T$ is inferred to be \lstinline$int$, and
|
---|
| 3538 | the returned value would have type \lstinline$int ( * )( int )$. ``\lstinline$fTpfT(17)(13)$'' and
|
---|
| 3539 | ``\lstinline$fTpfT("yes")("no")$'' are legal, but ``\lstinline$fTpfT(17)("no")$'' is illegal.
|
---|
| 3540 | \lstinline$fTpfU()$ is polymorphic ( in type \lstinline$T$), and returns a pointer to a function that
|
---|
| 3541 | is polymorphic ( in type \lstinline$U$). ``\lstinline$f5(17)("no")$'' is a legal expression of type
|
---|
| 3542 | \lstinline$char *$.
|
---|
| 3543 | \begin{lstlisting}
|
---|
| 3544 | forall( type T, type U, type V ) U * f( T *, U, V * const );
|
---|
| 3545 | forall( type U, type V, type W ) U * g( V *, U, W * const );
|
---|
| 3546 | \end{lstlisting}
|
---|
| 3547 | The functions \lstinline$f()$ and \lstinline$g()$ have compatible types. Let \(f\) and \(g\) be
|
---|
| 3548 | their types; then \(f_1\) = \lstinline$T$, \(f_2\) = \lstinline$U$, \(f_3\) = \lstinline$V$, \(g_1\)
|
---|
| 3549 | = \lstinline$V$, \(g_2\) = \lstinline$U$, and \(g_3\) = \lstinline$W$. Replacing every \(f_i\)
|
---|
| 3550 | by \(g_i\) in \(f\) gives
|
---|
| 3551 | \begin{lstlisting}
|
---|
| 3552 | forall( type V, type U, type W ) U * f( V *, U, W * const );
|
---|
| 3553 | \end{lstlisting}
|
---|
| 3554 | which has a return type and parameter list that is compatible with \(g\).
|
---|
| 3555 | \begin{rationale}
|
---|
| 3556 | The word ``\lstinline$type$'' in a forall specifier is redundant at the moment, but I want to leave
|
---|
| 3557 | room for inferred parameters of ordinary types in case parameterized types get added one day.
|
---|
| 3558 |
|
---|
| 3559 | Even without parameterized types, I might try to allow
|
---|
| 3560 | \begin{lstlisting}
|
---|
| 3561 | forall( int n ) int sum( int vector[n] );
|
---|
| 3562 | \end{lstlisting}
|
---|
| 3563 | but C currently rewrites array parameters as pointer parameters, so the effects of such a change
|
---|
| 3564 | require more thought.
|
---|
| 3565 | \end{rationale}
|
---|
| 3566 |
|
---|
| 3567 | \begin{rationale}
|
---|
| 3568 | A polymorphic declaration must do two things: it must introduce type parameters, and it must apply
|
---|
| 3569 | assertions to those types. Adding this to existing C declaration syntax and semantics was delicate,
|
---|
| 3570 | and not entirely successful.
|
---|
| 3571 |
|
---|
| 3572 | C depends on declaration-before-use, so a forall specifier must introduce type names before they can
|
---|
| 3573 | be used in the declaration specifiers. This could be done by making the forall specifier part of
|
---|
| 3574 | the declaration specifiers, or by making it a new introductory clause of declarations.
|
---|
| 3575 |
|
---|
| 3576 | Assertions are also part of polymorphic function types, because it must be clear which functions
|
---|
| 3577 | have access to the assertion parameters declared by the assertions. All attempts to put assertions
|
---|
| 3578 | inside an introductory clause produced complex semantics and confusing code. Building them into the
|
---|
| 3579 | declaration specifiers could be done by placing them in the function's parameter list, or in a
|
---|
| 3580 | forall specifier that is a declaration specifier. Assertions are also used with type parameters of
|
---|
| 3581 | specifications, and by type declarations. For consistency's sake it seems best to attach assertions
|
---|
| 3582 | to the type declarations in forall specifiers, which means that forall specifiers must be
|
---|
| 3583 | declaration specifiers.
|
---|
| 3584 | \end{rationale}
|
---|
| 3585 | %HERE
|
---|
| 3586 |
|
---|
| 3587 |
|
---|
| 3588 | \subsection{Type qualifiers}
|
---|
| 3589 |
|
---|
| 3590 | \CFA defines a new type qualifier \lstinline$lvalue$\impl{lvalue}\index{lvalue}.
|
---|
| 3591 | \begin{syntax}
|
---|
| 3592 | \oldlhs{type-qualifier}
|
---|
| 3593 | \rhs \lstinline$lvalue$
|
---|
| 3594 | \end{syntax}
|
---|
| 3595 |
|
---|
| 3596 | \constraints
|
---|
| 3597 | \lstinline$restrict$\index{register@{\lstinline$restrict$}} Types other than type parameters and
|
---|
| 3598 | pointer types whose referenced type is an object type shall not be restrict-qualified.
|
---|
| 3599 |
|
---|
| 3600 | \semantics
|
---|
| 3601 | An object's type may be a restrict-qualified type parameter. \lstinline$restrict$ does not
|
---|
| 3602 | establish any special semantics in that case.
|
---|
| 3603 |
|
---|
| 3604 | \begin{rationale}
|
---|
| 3605 | \CFA loosens the constraint on the restrict qualifier so that restrict-qualified pointers may be
|
---|
| 3606 | passed to polymorphic functions.
|
---|
| 3607 | \end{rationale}
|
---|
| 3608 |
|
---|
| 3609 | \lstinline$lvalue$ may be used to qualify the return type of a function type. Let \lstinline$T$ be
|
---|
| 3610 | an unqualified version of a type; then the result of calling a function with return type
|
---|
[2fc0e5c] | 3611 | \lstinline$lvalue T$ is a \Index{modifiable lvalue} of type \lstinline$T$.
|
---|
[f60d997] | 3612 | \lstinline$const$\use{const} and \lstinline$volatile$\use{volatile} qualifiers may also be added to
|
---|
| 3613 | indicate that the function result is a constant or volatile lvalue.
|
---|
| 3614 | \begin{rationale}
|
---|
| 3615 | The \lstinline$const$ and \lstinline$volatile$ qualifiers can only be sensibly used to qualify the
|
---|
| 3616 | return type of a function if the \lstinline$lvalue$ qualifier is also used.
|
---|
| 3617 | \end{rationale}
|
---|
| 3618 |
|
---|
[2fc0e5c] | 3619 | An {lvalue}-qualified type may be used in a \Index{cast expression} if the operand is an lvalue; the
|
---|
| 3620 | result of the expression is an lvalue.
|
---|
[f60d997] | 3621 |
|
---|
| 3622 | \begin{rationale}
|
---|
| 3623 | \lstinline$lvalue$ provides some of the functionality of {\CC}'s ``\lstinline$T&$'' ( reference to
|
---|
| 3624 | object of type \lstinline$T$) type. Reference types have four uses in {\CC}.
|
---|
| 3625 | \begin{itemize}
|
---|
| 3626 | \item
|
---|
| 3627 | They are necessary for user-defined operators that return lvalues, such as ``subscript'' and
|
---|
| 3628 | ``dereference''.
|
---|
| 3629 |
|
---|
| 3630 | \item
|
---|
| 3631 | A reference can be used to define an alias for a complicated lvalue expression, as a way of getting
|
---|
| 3632 | some of the functionality of the Pascal \lstinline$with$ statement. The following {\CC} code gives
|
---|
| 3633 | an example.
|
---|
| 3634 | \begin{lstlisting}
|
---|
| 3635 | {
|
---|
| 3636 | char &code = long_name.some_field[i].data->code;
|
---|
| 3637 | code = toupper( code );
|
---|
| 3638 | }
|
---|
| 3639 | \end{lstlisting}
|
---|
| 3640 | This is not very useful.
|
---|
| 3641 |
|
---|
| 3642 | \item
|
---|
| 3643 | A reference parameter can be used to allow a function to modify an argument without forcing the
|
---|
| 3644 | caller to pass the address of the argument. This is most useful for user-defined assignment
|
---|
| 3645 | operators. In {\CC}, plain assignment is done by a function called ``\lstinline$operator=$'', and
|
---|
| 3646 | the two expressions
|
---|
| 3647 | \begin{lstlisting}
|
---|
| 3648 | a = b;
|
---|
| 3649 | operator=( a, b );
|
---|
| 3650 | \end{lstlisting}
|
---|
| 3651 | are equivalent. If \lstinline$a$ and \lstinline$b$ are of type \lstinline$T$, then the first
|
---|
| 3652 | parameter of \lstinline$operator=$ must have type ``\lstinline$T&$''. It cannot have type
|
---|
| 3653 | \lstinline$T$, because then assignment couldn't alter the variable, and it can't have type
|
---|
| 3654 | ``\lstinline$T *$'', because the assignment would have to be written ``\lstinline$&a = b;$''.
|
---|
| 3655 |
|
---|
| 3656 | In the case of user-defined operators, this could just as well be handled by using pointer types and
|
---|
| 3657 | by changing the rewrite rules so that ``\lstinline$a = b;$'' is equivalent to
|
---|
| 3658 | ``\lstinline$operator=(&( a), b )$''. Reference parameters of ``normal'' functions are Bad Things,
|
---|
| 3659 | because they remove a useful property of C function calls: an argument can only be modified by a
|
---|
| 3660 | function if it is preceded by ``\lstinline$&$''.
|
---|
| 3661 |
|
---|
| 3662 | \item
|
---|
[2fc0e5c] | 3663 | References to \Index{const-qualified} types can be used instead of value parameters. Given the
|
---|
| 3664 | {\CC} function call ``\lstinline$fiddle( a_thing )$'', where the type of \lstinline$a_thing$ is
|
---|
| 3665 | \lstinline$Thing$, the type of \lstinline$fiddle$ could be either of
|
---|
[f60d997] | 3666 | \begin{lstlisting}
|
---|
| 3667 | void fiddle( Thing );
|
---|
| 3668 | void fiddle( const Thing & );
|
---|
| 3669 | \end{lstlisting}
|
---|
| 3670 | If the second form is used, then constructors and destructors are not invoked to create a temporary
|
---|
| 3671 | variable at the call site ( and it is bad style for the caller to make any assumptions about such
|
---|
| 3672 | things), and within \lstinline$fiddle$ the parameter is subject to the usual problems caused by
|
---|
| 3673 | aliases. The reference form might be chosen for efficiency's sake if \lstinline$Thing$s are too
|
---|
| 3674 | large or their constructors or destructors are too expensive. An implementation may switch between
|
---|
| 3675 | them without causing trouble for well-behaved clients. This leaves the implementor to define ``too
|
---|
| 3676 | large'' and ``too expensive''.
|
---|
| 3677 |
|
---|
| 3678 | I propose to push this job onto the compiler by allowing it to implement
|
---|
| 3679 | \begin{lstlisting}
|
---|
| 3680 | void fiddle( const volatile Thing );
|
---|
| 3681 | \end{lstlisting}
|
---|
| 3682 | with call-by-reference. Since it knows all about the size of \lstinline$Thing$s and the parameter
|
---|
| 3683 | passing mechanism, it should be able to come up with a better definition of ``too large'', and may
|
---|
| 3684 | be able to make a good guess at ``too expensive''.
|
---|
| 3685 | \end{itemize}
|
---|
| 3686 |
|
---|
| 3687 | In summary, since references are only really necessary for returning lvalues, I'll only provide
|
---|
| 3688 | lvalue functions.
|
---|
| 3689 | \end{rationale}
|
---|
| 3690 |
|
---|
| 3691 |
|
---|
| 3692 | \setcounter{subsection}{8}
|
---|
| 3693 | \subsection{Initialization}
|
---|
| 3694 |
|
---|
| 3695 | An expression that is used as an \nonterm{initializer} is treated as being cast to the type of the
|
---|
| 3696 | object being initialized. An expression used in an \nonterm{initializer-list} is treated as being
|
---|
| 3697 | cast to the type of the aggregate member that it initializes. In either case the cast must have a
|
---|
[2fc0e5c] | 3698 | single unambiguous \Index{interpretation}.
|
---|
[f60d997] | 3699 |
|
---|
| 3700 |
|
---|
| 3701 | \setcounter{subsection}{10}
|
---|
| 3702 | \subsection{Specification definitions}
|
---|
| 3703 |
|
---|
| 3704 | \begin{syntax}
|
---|
| 3705 | \lhs{spec-definition}
|
---|
| 3706 | \rhs \lstinline$spec$ \nonterm{identifier}
|
---|
| 3707 | \lstinline$($ \nonterm{type-parameter-list} \lstinline$)$
|
---|
| 3708 | \lstinline${$ \nonterm{spec-declaration-list}\opt \lstinline$}$
|
---|
| 3709 | \lhs{spec-declaration-list}
|
---|
| 3710 | \rhs \nonterm{spec-declaration} \lstinline$;$
|
---|
| 3711 | \rhs \nonterm{spec-declaration-list} \nonterm{spec-declaration} \lstinline$;$
|
---|
| 3712 | \lhs{spec-declaration}
|
---|
| 3713 | \rhs \nonterm{specifier-qualifier-list} \nonterm{declarator-list}
|
---|
| 3714 | \lhs{declarator-list}
|
---|
| 3715 | \rhs \nonterm{declarator}
|
---|
| 3716 | \rhs \nonterm{declarator-list} \lstinline$,$ \nonterm{declarator}
|
---|
| 3717 | \end{syntax}
|
---|
| 3718 | \begin{rationale}
|
---|
| 3719 | The declarations allowed in a specification are much the same as those allowed in a structure,
|
---|
[2fc0e5c] | 3720 | except that bit fields are not allowed, and \Index{incomplete type}s and function types are allowed.
|
---|
[f60d997] | 3721 | \end{rationale}
|
---|
| 3722 |
|
---|
| 3723 | \semantics
|
---|
| 3724 | A \define{specification definition} defines a name for a \define{specification}: a parameterized
|
---|
| 3725 | collection of object and function declarations.
|
---|
| 3726 |
|
---|
| 3727 | The declarations in a specification consist of the declarations in the
|
---|
| 3728 | \nonterm{spec-declaration-list} and declarations produced by any assertions in the
|
---|
| 3729 | \nonterm{spec-parameter-list}. If the collection contains two declarations that declare the same
|
---|
| 3730 | identifier and have compatible types, they are combined into one declaration with the composite type
|
---|
| 3731 | constructed from the two types.
|
---|
| 3732 |
|
---|
| 3733 |
|
---|
| 3734 | \subsubsection{Assertions}
|
---|
[2fc0e5c] | 3735 |
|
---|
[f60d997] | 3736 | \begin{syntax}
|
---|
| 3737 | \lhs{assertion-list}
|
---|
| 3738 | \rhs \nonterm{assertion}
|
---|
| 3739 | \rhs \nonterm{assertion-list} \nonterm{assertion}
|
---|
| 3740 | \lhs{assertion}
|
---|
| 3741 | \rhs \lstinline$|$ \nonterm{identifier} \lstinline$($ \nonterm{type-name-list} \lstinline$)$
|
---|
| 3742 | \rhs \lstinline$|$ \nonterm{spec-declaration}
|
---|
| 3743 | \lhs{type-name-list}
|
---|
| 3744 | \rhs \nonterm{type-name}
|
---|
| 3745 | \rhs \nonterm{type-name-list} \lstinline$,$ \nonterm{type-name}
|
---|
| 3746 | \end{syntax}
|
---|
| 3747 |
|
---|
| 3748 | \constraints
|
---|
| 3749 | The \nonterm{identifier} in an assertion that is not a \nonterm{spec-declaration} shall be the name
|
---|
| 3750 | of a specification. The \nonterm{type-name-list} shall contain one \nonterm{type-name} argument for
|
---|
| 3751 | each \nonterm{type-parameter} in that specification's \nonterm{spec-parameter-list}. If the
|
---|
| 3752 | \nonterm{type-parameter} uses type-class \lstinline$type$\use{type}, the argument shall be the type
|
---|
[2fc0e5c] | 3753 | name of an \Index{object type}; if it uses \lstinline$dtype$, the argument shall be the type name of
|
---|
| 3754 | an object type or an \Index{incomplete type}; and if it uses \lstinline$ftype$, the argument shall
|
---|
| 3755 | be the type name of a \Index{function type}.
|
---|
[f60d997] | 3756 |
|
---|
| 3757 | \semantics
|
---|
| 3758 | An \define{assertion} is a declaration of a collection of objects and functions, called
|
---|
| 3759 | \define{assertion parameters}.
|
---|
| 3760 |
|
---|
| 3761 | The assertion parameters produced by an assertion that applies the name of a specification to type
|
---|
| 3762 | arguments are found by taking the declarations specified in the specification and treating each of
|
---|
| 3763 | the specification's parameters as a synonym for the corresponding \nonterm{type-name} argument.
|
---|
| 3764 |
|
---|
| 3765 | The collection of assertion parameters produced by the \nonterm{assertion-list} are found by
|
---|
| 3766 | combining the declarations produced by each assertion. If the collection contains two declarations
|
---|
| 3767 | that declare the same identifier and have compatible types, they are combined into one declaration
|
---|
[2fc0e5c] | 3768 | with the \Index{composite type} constructed from the two types.
|
---|
[f60d997] | 3769 |
|
---|
| 3770 | \examples
|
---|
| 3771 | \begin{lstlisting}
|
---|
| 3772 | forall( type T | T ?*?( T, T ))@\use{?*?}@
|
---|
| 3773 | T square( T val ) {@\impl{square}@
|
---|
| 3774 | return val + val;
|
---|
| 3775 | }
|
---|
| 3776 |
|
---|
| 3777 | context summable( type T ) {@\impl{summable}@
|
---|
| 3778 | T ?+=?( T *, T );@\use{?+=?}@
|
---|
| 3779 | const T 0;@\use{0}@
|
---|
| 3780 | };
|
---|
| 3781 | context list_of( type List, type Element ) {@\impl{list_of}@
|
---|
| 3782 | Element car( List );
|
---|
| 3783 | List cdr( List );
|
---|
| 3784 | List cons( Element, List );
|
---|
| 3785 | List nil;
|
---|
| 3786 | int is_nil( List );
|
---|
| 3787 | };
|
---|
| 3788 | context sum_list( type List, type Element | summable( Element ) | list_of( List, Element ) ) {};
|
---|
| 3789 | \end{lstlisting}
|
---|
| 3790 | \lstinline$sum_list$ contains seven declarations, which describe a list whose elements can be added
|
---|
| 3791 | up. The assertion ``\lstinline$|sum_list( i_list, int )$''\use{sum_list} produces the assertion
|
---|
| 3792 | parameters
|
---|
| 3793 | \begin{lstlisting}
|
---|
| 3794 | int ?+=?( int *, int );
|
---|
| 3795 | const int 0;
|
---|
| 3796 | int car( i_list );
|
---|
| 3797 | i_list cdr( i_list );
|
---|
| 3798 | i_list cons( int, i_list );
|
---|
| 3799 | i_list nil;
|
---|
| 3800 | int is_nil;
|
---|
| 3801 | \end{lstlisting}
|
---|
| 3802 |
|
---|
[2fc0e5c] | 3803 |
|
---|
[f60d997] | 3804 | \subsection{Type declarations}
|
---|
[2fc0e5c] | 3805 |
|
---|
[f60d997] | 3806 | \begin{syntax}
|
---|
| 3807 | \lhs{type-parameter-list}
|
---|
| 3808 | \rhs \nonterm{type-parameter}
|
---|
| 3809 | \rhs \nonterm{type-parameter-list} \lstinline$,$ \nonterm{type-parameter}
|
---|
| 3810 | \lhs{type-parameter}
|
---|
| 3811 | \rhs \nonterm{type-class} \nonterm{identifier} \nonterm{assertion-list}\opt
|
---|
| 3812 | \lhs{type-class}
|
---|
| 3813 | \rhs \lstinline$type$
|
---|
| 3814 | \rhs \lstinline$dtype$
|
---|
| 3815 | \rhs \lstinline$ftype$
|
---|
| 3816 | \lhs{type-declaration}
|
---|
| 3817 | \rhs \nonterm{storage-class-specifier}\opt \lstinline$type$ \nonterm{type-declarator-list} \verb|;|
|
---|
| 3818 | \lhs{type-declarator-list}
|
---|
| 3819 | \rhs \nonterm{type-declarator}
|
---|
| 3820 | \rhs \nonterm{type-declarator-list} \lstinline$,$ \nonterm{type-declarator}
|
---|
| 3821 | \lhs{type-declarator}
|
---|
| 3822 | \rhs \nonterm{identifier} \nonterm{assertion-list}\opt \lstinline$=$ \nonterm{type-name}
|
---|
| 3823 | \rhs \nonterm{identifier} \nonterm{assertion-list}\opt
|
---|
| 3824 | \end{syntax}
|
---|
| 3825 |
|
---|
| 3826 | \constraints
|
---|
| 3827 | If a type declaration has block scope, and the declared identifier has external or internal linkage,
|
---|
| 3828 | the declaration shall have no initializer for the identifier.
|
---|
| 3829 |
|
---|
| 3830 | \semantics
|
---|
[2fc0e5c] | 3831 | A \nonterm{type-parameter} or a \nonterm{type-declarator} declares an identifier to be a \Index{type
|
---|
| 3832 | name} for a type incompatible with all other types.
|
---|
| 3833 |
|
---|
| 3834 | An identifier declared by a \nonterm{type-parameter} has \Index{no linkage}. Identifiers declared
|
---|
| 3835 | with type-class \lstinline$type$\use{type} are \Index{object type}s; those declared with type-class
|
---|
| 3836 | \lstinline$dtype$\use{dtype} are \Index{incomplete type}s; and those declared with type-class
|
---|
| 3837 | \lstinline$ftype$\use{ftype} are \Index{function type}s. The identifier has \Index{block scope} that
|
---|
| 3838 | terminates at the end of the \nonterm{spec-declaration-list} or polymorphic function that contains
|
---|
| 3839 | the \nonterm{type-parameter}.
|
---|
| 3840 |
|
---|
| 3841 | A \nonterm{type-declarator} with an \Index{initializer} is a \define{type definition}. The declared
|
---|
| 3842 | identifier is an \Index{incomplete type} within the initializer, and an \Index{object type} after
|
---|
| 3843 | the end of the initializer. The type in the initializer is called the \define{implementation
|
---|
| 3844 | type}. Within the scope of the declaration, \Index{implicit conversion}s can be performed between
|
---|
| 3845 | the defined type and the implementation type, and between pointers to the defined type and pointers
|
---|
| 3846 | to the implementation type.
|
---|
| 3847 |
|
---|
| 3848 | A type declaration without an \Index{initializer} and without a \Index{storage-class specifier} or
|
---|
| 3849 | with storage-class specifier \lstinline$static$\use{static} defines an \Index{incomplete type}. If a
|
---|
| 3850 | \Index{translation unit} or \Index{block} contains one or more such declarations for an identifier,
|
---|
| 3851 | it must contain exactly one definition of the identifier ( but not in an enclosed block, which would
|
---|
| 3852 | define a new type known only within that block).
|
---|
[f60d997] | 3853 | \begin{rationale}
|
---|
| 3854 | Incomplete type declarations allow compact mutually-recursive types.
|
---|
| 3855 | \begin{lstlisting}
|
---|
| 3856 | type t1; // Incomplete type declaration.
|
---|
| 3857 | type t2 = struct { t1 * p; ... };
|
---|
| 3858 | type t1 = struct { t2 * p; ... };
|
---|
| 3859 | \end{lstlisting}
|
---|
| 3860 | Without them, mutual recursion could be handled by declaring mutually recursive structures, then
|
---|
| 3861 | initializing the types to those structures.
|
---|
| 3862 | \begin{lstlisting}
|
---|
| 3863 | struct s1;
|
---|
| 3864 | type t2 = struct s2 { struct s1 * p; ... };
|
---|
| 3865 | type t1 = struct s1 { struct s2 * p; ... };
|
---|
| 3866 | \end{lstlisting}
|
---|
| 3867 | This introduces extra names, and may force the programmer to cast between the types and their
|
---|
| 3868 | implementations.
|
---|
| 3869 | \end{rationale}
|
---|
| 3870 |
|
---|
[2fc0e5c] | 3871 | A type declaration without an initializer and with \Index{storage-class specifier}
|
---|
| 3872 | \lstinline$extern$\use{extern} is an \define{opaque type declaration}. Opaque types are
|
---|
| 3873 | \Index{object type}s. An opaque type is not a \nonterm{constant-expression}; neither is a structure
|
---|
| 3874 | or union that has a member whose type is not a \nonterm{constant-expression}. Every other
|
---|
| 3875 | \Index{object type} is a \nonterm{constant-expression}. Objects with static storage duration shall
|
---|
| 3876 | be declared with a type that is a \nonterm{constant-expression}.
|
---|
[f60d997] | 3877 | \begin{rationale}
|
---|
| 3878 | Type declarations can declare identifiers with external linkage, whereas typedef declarations
|
---|
| 3879 | declare identifiers that only exist within a translation unit. These opaque types can be used in
|
---|
| 3880 | declarations, but the implementation of the type is not visible.
|
---|
| 3881 |
|
---|
| 3882 | Static objects can not have opaque types because space for them would have to be allocated at
|
---|
| 3883 | program start-up. This is a deficiency\index{deficiencies!static opaque objects}, but I don't want
|
---|
| 3884 | to deal with ``module initialization'' code just now.
|
---|
| 3885 | \end{rationale}
|
---|
| 3886 |
|
---|
[2fc0e5c] | 3887 | An \Index{incomplete type} which is not a qualified version\index{qualified type} of a type is a
|
---|
| 3888 | value of \Index{type-class} \lstinline$dtype$. An object type\index{object types} which is not a
|
---|
| 3889 | qualified version of a type is a value of type-classes \lstinline$type$ and \lstinline$dtype$. A
|
---|
| 3890 | \Index{function type} is a value of type-class \lstinline$ftype$.
|
---|
[f60d997] | 3891 | \begin{rationale}
|
---|
| 3892 | Syntactically, a type value is a \nonterm{type-name}, which is a declaration for an object which
|
---|
| 3893 | omits the identifier being declared.
|
---|
| 3894 |
|
---|
| 3895 | Object types are precisely the types that can be instantiated. Type qualifiers are not included in
|
---|
| 3896 | type values because the compiler needs the information they provide at compile time to detect
|
---|
| 3897 | illegal statements or to produce efficient machine instructions. For instance, the code that a
|
---|
| 3898 | compiler must generate to manipulate an object that has volatile-qualified type may be different
|
---|
| 3899 | from the code to manipulate an ordinary object.
|
---|
| 3900 |
|
---|
| 3901 | Type qualifiers are a weak point of C's type system. Consider the standard library function
|
---|
| 3902 | \lstinline$strchr()$ which, given a string and a character, returns a pointer to the first
|
---|
| 3903 | occurrence of the character in the string.
|
---|
| 3904 | \begin{lstlisting}
|
---|
| 3905 | char *strchr( const char *s, int c ) {@\impl{strchr}@
|
---|
| 3906 | char real_c = c; // done because c was declared as int.
|
---|
| 3907 | for ( ; *s != real_c; s++ )
|
---|
| 3908 | if ( *s == '\0' ) return NULL;
|
---|
| 3909 | return ( char * )s;
|
---|
| 3910 | }
|
---|
| 3911 | \end{lstlisting}
|
---|
| 3912 | The parameter \lstinline$s$ must be \lstinline$const char *$, because \lstinline$strchr()$ might be
|
---|
| 3913 | used to search a constant string, but the return type must be \lstinline$char *$, because the result
|
---|
| 3914 | might be used to modify a non-constant string. Hence the body must perform a cast, and ( even worse)
|
---|
| 3915 | \lstinline$strchr()$ provides a type-safe way to attempt to modify constant strings. What is needed
|
---|
| 3916 | is some way to say that \lstinline$s$'s type might contain qualifiers, and the result type has
|
---|
| 3917 | exactly the same qualifiers. Polymorphic functions do not provide a fix for this
|
---|
| 3918 | deficiency\index{deficiencies!pointers to qualified types}, because type qualifiers are not part of
|
---|
| 3919 | type values. Instead, overloading can be used to define \lstinline$strchr()$ for each combination
|
---|
| 3920 | of qualifiers.
|
---|
| 3921 | \end{rationale}
|
---|
| 3922 |
|
---|
| 3923 | \begin{rationale}
|
---|
[2fc0e5c] | 3924 | Since \Index{incomplete type}s are not type values, they can not be used as the initializer in a
|
---|
| 3925 | type declaration, or as the type of a structure or union member. This prevents the declaration of
|
---|
| 3926 | types that contain each other.
|
---|
[f60d997] | 3927 | \begin{lstlisting}
|
---|
| 3928 | type t1;
|
---|
| 3929 | type t2 = t1; // illegal: incomplete type t1.
|
---|
| 3930 | type t1 = t2;
|
---|
| 3931 | \end{lstlisting}
|
---|
| 3932 |
|
---|
| 3933 | The initializer in a file-scope declaration must be a constant expression. This means type
|
---|
| 3934 | declarations can not build on opaque types, which is a deficiency\index{deficiencies!nesting opaque
|
---|
| 3935 | types}.
|
---|
| 3936 | \begin{lstlisting}
|
---|
| 3937 | extern type Huge; // extended-precision integer type.
|
---|
| 3938 | type Rational = struct {
|
---|
| 3939 | Huge numerator, denominator; // illegal
|
---|
| 3940 | };
|
---|
| 3941 | struct Pair {
|
---|
| 3942 | Huge first, second; // legal
|
---|
| 3943 | };
|
---|
| 3944 | \end{lstlisting}
|
---|
| 3945 | Without this restriction, \CFA might require ``module initialization'' code ( since
|
---|
| 3946 | \lstinline$Rational$ has external linkage, it must be created before any other translation unit
|
---|
| 3947 | instantiates it), and would force an ordering on the initialization of the translation unit that
|
---|
| 3948 | defines \lstinline$Huge$ and the translation that declares \lstinline$Rational$.
|
---|
| 3949 |
|
---|
| 3950 | A benefit of the restriction is that it prevents the declaration in separate translation units of
|
---|
| 3951 | types that contain each other, which would be hard to prevent otherwise.
|
---|
| 3952 | \begin{lstlisting}
|
---|
| 3953 | // File a.c:
|
---|
| 3954 | extern type t1;
|
---|
| 3955 | type t2 = struct { t1 f1; ... } // illegal
|
---|
| 3956 | // File b.c:
|
---|
| 3957 | extern type t2;
|
---|
| 3958 | type t1 = struct { t2 f2; ... } // illegal
|
---|
| 3959 | \end{lstlisting}
|
---|
| 3960 | \end{rationale}
|
---|
| 3961 |
|
---|
| 3962 | \begin{rationale}
|
---|
| 3963 | Since a \nonterm{type-declaration} is a \nonterm{declaration} and not a
|
---|
| 3964 | \nonterm{struct-declaration}, type declarations can not be structure members. The form of
|
---|
| 3965 | \nonterm{type-declaration} forbids arrays of, pointers to, and functions returning \lstinline$type$.
|
---|
| 3966 | Hence the syntax of \nonterm{type-specifier} does not have to be extended to allow type-valued
|
---|
| 3967 | expressions. It also side-steps the problem of type-valued expressions producing different values
|
---|
| 3968 | in different declarations.
|
---|
| 3969 |
|
---|
| 3970 | Since a type declaration is not a \nonterm{parameter-declaration}, functions can not have explicit
|
---|
| 3971 | type parameters. This may be too restrictive, but it attempts to make compilation simpler. Recall
|
---|
| 3972 | that when traditional C scanners read in an identifier, they look it up in the symbol table to
|
---|
| 3973 | determine whether or not it is a typedef name, and return a ``type'' or ``identifier'' token
|
---|
| 3974 | depending on what they find. A type parameter would add a type name to the current scope. The
|
---|
| 3975 | scope manipulations involved in parsing the declaration of a function that takes function pointer
|
---|
| 3976 | parameters and returns a function pointer may just be too complicated.
|
---|
| 3977 |
|
---|
| 3978 | Explicit type parameters don't seem to be very useful, anyway, because their scope would not include
|
---|
| 3979 | the return type of the function. Consider the following attempt to define a type-safe memory
|
---|
| 3980 | allocation function.
|
---|
| 3981 | \begin{lstlisting}
|
---|
| 3982 | #include <stdlib.h>
|
---|
| 3983 | T * new( type T ) { return ( T * )malloc( sizeof( T) ); };
|
---|
| 3984 | @\ldots@
|
---|
| 3985 | int * ip = new( int );
|
---|
| 3986 | \end{lstlisting}
|
---|
| 3987 | This looks sensible, but \CFA's declaration-before-use rules mean that ``\lstinline$T$'' in the
|
---|
| 3988 | function body refers to the parameter, but the ``\lstinline$T$'' in the return type refers to the
|
---|
| 3989 | meaning of \lstinline$T$ in the scope that contains \lstinline$new$; it could be undefined, or a
|
---|
| 3990 | type name, or a function or variable name. Nothing good can result from such a situation.
|
---|
| 3991 | \end{rationale}
|
---|
| 3992 |
|
---|
| 3993 | \examples
|
---|
| 3994 | Since type declarations create new types, instances of types are always passed by value.
|
---|
| 3995 | \begin{lstlisting}
|
---|
| 3996 | type A1 = int[2];
|
---|
| 3997 | void f1( A1 a ) { a[0] = 0; };
|
---|
| 3998 | typedef int A2[2];
|
---|
| 3999 | void f2( A2 a ) { a[0] = 0; };
|
---|
| 4000 | A1 v1;
|
---|
| 4001 | A2 v2;
|
---|
| 4002 | f1( v1 );
|
---|
| 4003 | f2( v2 );
|
---|
| 4004 | \end{lstlisting}
|
---|
| 4005 | \lstinline$V1$ is passed by value, so \lstinline$f1()$'s assignment to \lstinline$a[0]$ does not
|
---|
| 4006 | modify v1. \lstinline$V2$ is converted to a pointer, so \lstinline$f2()$ modifies
|
---|
| 4007 | \lstinline$v2[0]$.
|
---|
| 4008 |
|
---|
| 4009 | A translation unit containing the declarations
|
---|
| 4010 | \begin{lstlisting}
|
---|
| 4011 | extern type Complex;@\use{Complex}@ // opaque type declaration.
|
---|
| 4012 | extern float abs( Complex );@\use{abs}@
|
---|
| 4013 | \end{lstlisting}
|
---|
| 4014 | can contain declarations of complex numbers, which can be passed to \lstinline$abs$. Some other
|
---|
| 4015 | translation unit must implement \lstinline$Complex$ and \lstinline$abs$. That unit might contain
|
---|
| 4016 | the declarations
|
---|
| 4017 | \begin{lstlisting}
|
---|
| 4018 | type Complex = struct { float re, im; };@\impl{Complex}@
|
---|
| 4019 | Complex cplx_i = { 0.0, 1.0 };@\impl{cplx_i}@
|
---|
| 4020 | float abs( Complex c ) {@\impl{abs( Complex )}@
|
---|
| 4021 | return sqrt( c.re * c.re + c.im * c.im );
|
---|
| 4022 | }
|
---|
| 4023 | \end{lstlisting}
|
---|
| 4024 | Note that \lstinline$c$ is implicitly converted to a \lstinline$struct$ so that its components can
|
---|
| 4025 | be retrieved.
|
---|
| 4026 |
|
---|
| 4027 | \begin{lstlisting}
|
---|
| 4028 | type Time_of_day = int;@\impl{Time_of_day}@ // seconds since midnight.
|
---|
| 4029 | Time_of_day ?+?( Time_of_day t1, int seconds ) {@\impl{?+?}@
|
---|
| 4030 | return (( int)t1 + seconds ) % 86400;
|
---|
| 4031 | }
|
---|
| 4032 | \end{lstlisting}
|
---|
| 4033 | \lstinline$t1$ must be cast to its implementation type to prevent infinite recursion.
|
---|
| 4034 |
|
---|
| 4035 | \begin{rationale}
|
---|
| 4036 | Within the scope of a type definition, an instance of the type can be viewed as having that type or
|
---|
| 4037 | as having the implementation type. In the \lstinline$Time_of_day$ example, the difference is
|
---|
| 4038 | important. Different languages have treated the distinction between the abstraction and the
|
---|
| 4039 | implementation in different ways.
|
---|
| 4040 | \begin{itemize}
|
---|
| 4041 | \item
|
---|
| 4042 | Inside a Clu cluster \cite{clu}, the declaration of an instance states which view applies. Two
|
---|
| 4043 | primitives called \lstinline$up$ and \lstinline$down$ can be used to convert between the views.
|
---|
| 4044 | \item
|
---|
| 4045 | The Simula class \cite{Simula87} is essentially a record type. Since the only operations on a
|
---|
| 4046 | record are member selection and assignment, which can not be overloaded, there is never any
|
---|
| 4047 | ambiguity as to whether the abstraction or the implementation view is being used. In {\CC}
|
---|
| 4048 | \cite{c++}, operations on class instances include assignment and ``\lstinline$&$'', which can be
|
---|
| 4049 | overloaded. A ``scope resolution'' operator can be used inside the class to specify whether the
|
---|
| 4050 | abstract or implementation version of the operation should be used.
|
---|
| 4051 | \item
|
---|
| 4052 | An Ada derived type definition \cite{ada} creates a new type from an old type, and also implicitly
|
---|
| 4053 | declares derived subprograms that correspond to the existing subprograms that use the old type as a
|
---|
| 4054 | parameter type or result type. The derived subprograms are clones of the existing subprograms with
|
---|
| 4055 | the old type replaced by the derived type. Literals and aggregates of the old type are also cloned.
|
---|
| 4056 | In other words, the abstract view provides exactly the same operations as the implementation view.
|
---|
| 4057 | This allows the abstract view to be used in all cases.
|
---|
| 4058 |
|
---|
| 4059 | The derived subprograms can be replaced by programmer-specified subprograms. This is an exception
|
---|
| 4060 | to the normal scope rules, which forbid duplicate definitions of a subprogram in a scope. In this
|
---|
| 4061 | case, explicit conversions between the derived type and the old type can be used.
|
---|
| 4062 | \end{itemize}
|
---|
| 4063 | \CFA's rules are like Clu's, except that implicit conversions and
|
---|
| 4064 | conversion costs allow it to do away with most uses of \lstinline$up$ and \lstinline$down$.
|
---|
| 4065 | \end{rationale}
|
---|
| 4066 |
|
---|
| 4067 |
|
---|
| 4068 | \subsubsection{Default functions and objects}
|
---|
| 4069 |
|
---|
| 4070 | A declaration\index{type declaration} of a type identifier \lstinline$T$ with type-class
|
---|
| 4071 | \lstinline$type$ implicitly declares a \define{default assignment} function
|
---|
[2fc0e5c] | 4072 | \lstinline$T ?=?( T *, T )$\use{?=?}, with the same \Index{scope} and \Index{linkage} as the
|
---|
| 4073 | identifier \lstinline$T$.
|
---|
[f60d997] | 4074 | \begin{rationale}
|
---|
| 4075 | Assignment is central to C's imperative programming style, and every existing C object type has
|
---|
| 4076 | assignment defined for it ( except for array types, which are treated as pointer types for purposes
|
---|
| 4077 | of assignment). Without this rule, nearly every inferred type parameter would need an accompanying
|
---|
| 4078 | assignment assertion parameter. If a type parameter should not have an assignment operation,
|
---|
| 4079 | \lstinline$dtype$ should be used. If a type should not have assignment defined, the user can define
|
---|
| 4080 | an assignment function that causes a run-time error, or provide an external declaration but no
|
---|
| 4081 | definition and thus cause a link-time error.
|
---|
| 4082 | \end{rationale}
|
---|
| 4083 |
|
---|
[2fc0e5c] | 4084 | A definition\index{type definition} of a type identifier \lstinline$T$ with \Index{implementation
|
---|
| 4085 | type} \lstinline$I$ and type-class \lstinline$type$ implicitly defines a default assignment
|
---|
| 4086 | function. A definition\index{type definition} of a type identifier \lstinline$T$ with implementation
|
---|
| 4087 | type \lstinline$I$ and an assertion list implicitly defines \define{default function}s and
|
---|
| 4088 | \define{default object}s as declared by the assertion declarations. The default objects and
|
---|
| 4089 | functions have the same \Index{scope} and \Index{linkage} as the identifier \lstinline$T$. Their
|
---|
| 4090 | values are determined as follows:
|
---|
[f60d997] | 4091 | \begin{itemize}
|
---|
| 4092 | \item
|
---|
| 4093 | If at the definition of \lstinline$T$ there is visible a declaration of an object with the same name
|
---|
| 4094 | as the default object, and if the type of that object with all occurrence of \lstinline$I$ replaced
|
---|
| 4095 | by \lstinline$T$ is compatible with the type of the default object, then the default object is
|
---|
| 4096 | initialized with that object. Otherwise the scope of the declaration of \lstinline$T$ must contain
|
---|
| 4097 | a definition of the default object.
|
---|
| 4098 |
|
---|
| 4099 | \item
|
---|
| 4100 | If at the definition of \lstinline$T$ there is visible a declaration of a function with the same
|
---|
| 4101 | name as the default function, and if the type of that function with all occurrence of \lstinline$I$
|
---|
| 4102 | replaced by \lstinline$T$ is compatible with the type of the default function, then the default
|
---|
| 4103 | function calls that function after converting its arguments and returns the converted result.
|
---|
| 4104 |
|
---|
| 4105 | Otherwise, if \lstinline$I$ contains exactly one anonymous member\index{anonymous member} such that
|
---|
| 4106 | at the definition of \lstinline$T$ there is visible a declaration of a function with the same name
|
---|
| 4107 | as the default function, and the type of that function with all occurrences of the anonymous
|
---|
| 4108 | member's type in its parameter list replaced by \lstinline$T$ is compatible with the type of the
|
---|
| 4109 | default function, then the default function calls that function after converting its arguments and
|
---|
| 4110 | returns the result.
|
---|
| 4111 |
|
---|
| 4112 | Otherwise the scope of the declaration of \lstinline$T$ must contain a definition of the default
|
---|
| 4113 | function.
|
---|
| 4114 | \end{itemize}
|
---|
| 4115 | \begin{rationale}
|
---|
| 4116 | Note that a pointer to a default function will not compare as equal to a pointer to the inherited
|
---|
| 4117 | function.
|
---|
| 4118 | \end{rationale}
|
---|
| 4119 |
|
---|
| 4120 | A function or object with the same type and name as a default function or object that is declared
|
---|
| 4121 | within the scope of the definition of \lstinline$T$ replaces the default function or object.
|
---|
| 4122 |
|
---|
| 4123 | \examples
|
---|
| 4124 | \begin{lstlisting}
|
---|
| 4125 | context s( type T ) {
|
---|
| 4126 | T a, b;
|
---|
| 4127 | }
|
---|
| 4128 | struct impl { int left, right; } a = { 0, 0 };
|
---|
| 4129 | type Pair | s( Pair ) = struct impl;
|
---|
| 4130 | Pair b = { 1, 1 };
|
---|
| 4131 | \end{lstlisting}
|
---|
| 4132 | The definition of \lstinline$Pair$ implicitly defines two objects \lstinline$a$ and \lstinline$b$.
|
---|
| 4133 | \lstinline$Pair a$ inherits its value from the \lstinline$struct impl a$. The definition of
|
---|
| 4134 | \lstinline$Pair b$ is compulsory because there is no \lstinline$struct impl b$ to construct a value
|
---|
| 4135 | from.
|
---|
| 4136 | \begin{lstlisting}
|
---|
| 4137 | context ss( type T ) {
|
---|
| 4138 | T clone( T );
|
---|
| 4139 | void munge( T * );
|
---|
| 4140 | }
|
---|
| 4141 | type Whatsit | ss( Whatsit );@\use{Whatsit}@
|
---|
| 4142 | type Doodad | ss( Doodad ) = struct doodad {@\use{Doodad}@
|
---|
| 4143 | Whatsit; // anonymous member
|
---|
| 4144 | int extra;
|
---|
| 4145 | };
|
---|
| 4146 | Doodad clone( Doodad ) { ... }
|
---|
| 4147 | \end{lstlisting}
|
---|
| 4148 | The definition of \lstinline$Doodad$ implicitly defines three functions:
|
---|
| 4149 | \begin{lstlisting}
|
---|
| 4150 | Doodad ?=?( Doodad *, Doodad );
|
---|
| 4151 | Doodad clone( Doodad );
|
---|
| 4152 | void munge( Doodad * );
|
---|
| 4153 | \end{lstlisting}
|
---|
| 4154 | The assignment function inherits \lstinline$struct doodad$'s assignment function because the types
|
---|
| 4155 | match when \lstinline$struct doodad$ is replaced by \lstinline$Doodad$ throughout.
|
---|
| 4156 | \lstinline$munge()$ inherits \lstinline$Whatsit$'s \lstinline$munge()$ because the types match when
|
---|
| 4157 | \lstinline$Whatsit$ is replaced by \lstinline$Doodad$ in the parameter list. \lstinline$clone()$
|
---|
| 4158 | does \emph{not} inherit \lstinline$Whatsit$'s \lstinline$clone()$: replacement in the parameter
|
---|
| 4159 | list yields ``\lstinline$Whatsit clone( Doodad )$'', which is not compatible with
|
---|
| 4160 | \lstinline$Doodad$'s \lstinline$clone()$'s type. Hence the definition of
|
---|
| 4161 | ``\lstinline$Doodad clone( Doodad )$'' is necessary.
|
---|
| 4162 |
|
---|
| 4163 | Default functions and objects are subject to the normal scope rules.
|
---|
| 4164 | \begin{lstlisting}
|
---|
| 4165 | type T = @\ldots@;
|
---|
| 4166 | T a_T = @\ldots@; // Default assignment used.
|
---|
| 4167 | T ?=?( T *, T );
|
---|
| 4168 | T a_T = @\ldots@; // Programmer-defined assignment called.
|
---|
| 4169 | \end{lstlisting}
|
---|
| 4170 | \begin{rationale}
|
---|
| 4171 | A compiler warning would be helpful in this situation.
|
---|
| 4172 | \end{rationale}
|
---|
| 4173 |
|
---|
| 4174 | \begin{rationale}
|
---|
| 4175 | The \emph{class} construct of object-oriented programming languages performs three independent
|
---|
| 4176 | functions. It \emph{encapsulates} a data structure; it defines a \emph{subtype} relationship, whereby
|
---|
| 4177 | instances of one class may be used in contexts that require instances of another; and it allows one
|
---|
| 4178 | class to \emph{inherit} the implementation of another.
|
---|
| 4179 |
|
---|
| 4180 | In \CFA, encapsulation is provided by opaque types and the scope rules, and subtyping is provided
|
---|
| 4181 | by specifications and assertions. Inheritance is provided by default functions and objects.
|
---|
| 4182 | \end{rationale}
|
---|
| 4183 |
|
---|
| 4184 |
|
---|
| 4185 | \section{Statements and blocks}
|
---|
[2fc0e5c] | 4186 |
|
---|
[ce6c57c] | 4187 | \begin{syntax}
|
---|
| 4188 | \oldlhs{statement}
|
---|
| 4189 | \rhs \nonterm{exception-statement}
|
---|
| 4190 | \end{syntax}
|
---|
| 4191 |
|
---|
[f60d997] | 4192 | Many statements contain expressions, which may have more than one interpretation. The following
|
---|
[2fc0e5c] | 4193 | sections describe how the \CFA translator selects an interpretation. In all cases the result of the
|
---|
| 4194 | selection shall be a single unambiguous \Index{interpretation}.
|
---|
[f60d997] | 4195 |
|
---|
| 4196 |
|
---|
[2f9956b] | 4197 | \subsection{Labeled statements}
|
---|
| 4198 |
|
---|
| 4199 | \begin{syntax}
|
---|
| 4200 | \oldlhs{labeled-statement}
|
---|
| 4201 | \rhs \lstinline$case$ \nonterm{case-value-list} : \nonterm{statement}
|
---|
| 4202 | \lhs{case-value-list}
|
---|
| 4203 | \rhs \nonterm{case-value}
|
---|
| 4204 | \rhs \nonterm{case-value-list} \lstinline$,$ \nonterm{case-value}
|
---|
| 4205 | \lhs{case-value}
|
---|
| 4206 | \rhs \nonterm{constant-expression}
|
---|
| 4207 | \rhs \nonterm{subrange}
|
---|
| 4208 | \lhs{subrange}
|
---|
| 4209 | \rhs \nonterm{constant-expression} \lstinline$~$ \nonterm{constant-expression}
|
---|
| 4210 | \end{syntax}
|
---|
| 4211 |
|
---|
| 4212 | The following have identical meaning:
|
---|
| 4213 | \begin{lstlisting}
|
---|
[ce6c57c] | 4214 | case 1: case 2: case 3: case 4: case 5:
|
---|
[2f9956b] | 4215 | case 1, 2, 3, 4, 5:
|
---|
| 4216 | case 1~5:
|
---|
| 4217 | \end{lstlisting}
|
---|
[865249a] | 4218 | Multiple subranges are allowed:
|
---|
[2f9956b] | 4219 | \begin{lstlisting}
|
---|
| 4220 | case 1~4, 9~14, 27~32:
|
---|
| 4221 | \end{lstlisting}
|
---|
[865249a] | 4222 | The \lstinline$case$ and \lstinline$default$ clauses are restricted within the \lstinline$switch$ and \lstinline$choose$ statements, precluding Duff's device.
|
---|
[2f9956b] | 4223 |
|
---|
| 4224 |
|
---|
[f60d997] | 4225 | \subsection{Expression and null statements}
|
---|
| 4226 |
|
---|
| 4227 | The expression in an expression statement is treated as being cast to \lstinline$void$.
|
---|
| 4228 |
|
---|
| 4229 |
|
---|
| 4230 | \subsection{Selection statements}
|
---|
| 4231 |
|
---|
[2f9956b] | 4232 | \begin{syntax}
|
---|
| 4233 | \oldlhs{selection-statement}
|
---|
| 4234 | \rhs \lstinline$choose$ \lstinline$($ \nonterm{expression} \lstinline$)$ \nonterm{statement}
|
---|
| 4235 | \end{syntax}
|
---|
| 4236 |
|
---|
| 4237 | The controlling expression \lstinline$E$ in the \lstinline$switch$ and \lstinline$choose$ statement:
|
---|
[f60d997] | 4238 | \begin{lstlisting}
|
---|
| 4239 | switch ( E ) ...
|
---|
[2f9956b] | 4240 | choose ( E ) ...
|
---|
[f60d997] | 4241 | \end{lstlisting}
|
---|
[865249a] | 4242 | may have more than one interpretation, but it shall have only one interpretation with an integral type.
|
---|
| 4243 | An \Index{integer promotion} is performed on the expression if necessary.
|
---|
| 4244 | The constant expressions in \lstinline$case$ statements with the switch are converted to the promoted type.
|
---|
[f60d997] | 4245 |
|
---|
| 4246 |
|
---|
[2f9956b] | 4247 | \setcounter{subsubsection}{3}
|
---|
| 4248 | \subsubsection{The \lstinline$choose$ statement}
|
---|
| 4249 |
|
---|
| 4250 | 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.
|
---|
| 4251 | The \lstinline$fallthru$ statement is used to fall through to the next \lstinline$case$ or \lstinline$default$ labeled statement.
|
---|
| 4252 | The following have identical meaning:
|
---|
| 4253 | \begin{flushleft}
|
---|
| 4254 | \begin{tabular}{@{\hspace{2em}}l@{\hspace{2em}}l@{}}
|
---|
| 4255 | \begin{lstlisting}
|
---|
| 4256 | switch (...) {
|
---|
| 4257 | case 1: ... ; break;
|
---|
| 4258 | case 2: ... ; break;
|
---|
| 4259 | case 3: ... ; // fall through
|
---|
| 4260 | case 4: ... ; // fall through
|
---|
| 4261 | default: ... break;
|
---|
| 4262 | }
|
---|
| 4263 | \end{lstlisting}
|
---|
| 4264 | &
|
---|
| 4265 | \begin{lstlisting}
|
---|
| 4266 | choose (...) {
|
---|
| 4267 | case 1: ... ; // exit
|
---|
| 4268 | case 2: ... ; // exit
|
---|
| 4269 | case 3: ... ; fallthru;
|
---|
| 4270 | case 4: ... ; fallthru;
|
---|
| 4271 | default: ... ; // exit
|
---|
| 4272 | }
|
---|
| 4273 | \end{lstlisting}
|
---|
| 4274 | \end{tabular}
|
---|
| 4275 | \end{flushleft}
|
---|
[865249a] | 4276 | The \lstinline$choose$ statement addresses the problem of accidental fall-through associated with the \lstinline$switch$ statement.
|
---|
[2f9956b] | 4277 |
|
---|
| 4278 |
|
---|
[f60d997] | 4279 | \subsection{Iteration statements}
|
---|
| 4280 |
|
---|
| 4281 | The controlling expression \lstinline$E$ in the loops
|
---|
| 4282 | \begin{lstlisting}
|
---|
| 4283 | if ( E ) ...
|
---|
| 4284 | while ( E ) ...
|
---|
| 4285 | do ... while ( E );
|
---|
| 4286 | \end{lstlisting}
|
---|
| 4287 | is treated as ``\lstinline$( int )((E)!=0)$''.
|
---|
| 4288 |
|
---|
| 4289 | The statement
|
---|
| 4290 | \begin{lstlisting}
|
---|
| 4291 | for ( a; b; c ) @\ldots@
|
---|
| 4292 | \end{lstlisting}
|
---|
| 4293 | is treated as
|
---|
| 4294 | \begin{lstlisting}
|
---|
[2f9956b] | 4295 | for ( ( void )( a ); ( int )(( b )!=0); ( void )( c ) ) ...
|
---|
[f60d997] | 4296 | \end{lstlisting}
|
---|
| 4297 |
|
---|
| 4298 |
|
---|
| 4299 | \subsection{Jump statements}
|
---|
| 4300 |
|
---|
[2f9956b] | 4301 | \begin{syntax}
|
---|
| 4302 | \oldlhs{jump-statement}
|
---|
| 4303 | \rhs \lstinline$continue$ \nonterm{identifier}\opt
|
---|
| 4304 | \rhs \lstinline$break$ \nonterm{identifier}\opt
|
---|
[ce6c57c] | 4305 | \rhs \ldots
|
---|
| 4306 | \rhs \lstinline$throw$ \nonterm{assignment-expression}\opt
|
---|
[a188b16] | 4307 | \rhs \lstinline$throwResume$ \nonterm{assignment-expression}\opt \nonterm{at-expression}\opt
|
---|
| 4308 | \lhs{at-expression} \lstinline$_At$ \nonterm{assignment-expression}
|
---|
[2f9956b] | 4309 | \end{syntax}
|
---|
| 4310 |
|
---|
[865249a] | 4311 | 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.
|
---|
[2f9956b] | 4312 | \begin{lstlisting}
|
---|
| 4313 | L1: { // compound
|
---|
| 4314 | L2: switch ( ... ) { // switch
|
---|
[ce6c57c] | 4315 | case ...:
|
---|
[2f9956b] | 4316 | L3: for ( ;; ) { // outer for
|
---|
| 4317 | L4: for ( ;; ) { // inner for
|
---|
| 4318 | continue L1; // error: not enclosing iteration
|
---|
| 4319 | continue L2; // error: not enclosing iteration
|
---|
| 4320 | continue L3; // next iteration of outer for
|
---|
| 4321 | continue L4; // next iteration of inner for
|
---|
| 4322 | break L1; // exit compound
|
---|
| 4323 | break L2; // exit switch
|
---|
| 4324 | break L3; // exit outer for
|
---|
| 4325 | break L4; // exit inner for
|
---|
| 4326 | } // for
|
---|
| 4327 | } // for
|
---|
| 4328 | break; // exit switch
|
---|
| 4329 | default:
|
---|
| 4330 | break L1; // exit compound
|
---|
| 4331 | } // switch
|
---|
| 4332 | ...
|
---|
| 4333 | } // compound
|
---|
| 4334 | \end{lstlisting}
|
---|
| 4335 |
|
---|
| 4336 |
|
---|
| 4337 | \setcounter{subsubsection}{1}
|
---|
| 4338 | \subsubsection{The \lstinline$continue$ statement}
|
---|
| 4339 |
|
---|
| 4340 | The identifier in a \lstinline$continue$ statement shall name a label located on an enclosing iteration statement.
|
---|
| 4341 |
|
---|
| 4342 |
|
---|
| 4343 | \subsubsection{The \lstinline$break$ statement}
|
---|
| 4344 |
|
---|
| 4345 | The identifier in a \lstinline$break$ statement shall name a label located on an enclosing compound, selection or iteration statement.
|
---|
| 4346 |
|
---|
| 4347 |
|
---|
| 4348 | \subsubsection{The \lstinline$return$ statement}
|
---|
| 4349 |
|
---|
[ce6c57c] | 4350 | An expression in a \lstinline$return$ statement is treated as being cast to the result type of the function.
|
---|
| 4351 |
|
---|
| 4352 |
|
---|
| 4353 | \subsubsection{The \lstinline$throw$ statement}
|
---|
| 4354 |
|
---|
| 4355 | When an exception is raised, \Index{propagation} directs control from a raise in the source execution to a handler in the faulting execution.
|
---|
| 4356 |
|
---|
| 4357 |
|
---|
| 4358 | \subsubsection{The \lstinline$throwResume$ statement}
|
---|
| 4359 |
|
---|
| 4360 |
|
---|
| 4361 | \subsection{Exception statements}
|
---|
| 4362 |
|
---|
| 4363 | \begin{syntax}
|
---|
| 4364 | \lhs{exception-statement}
|
---|
| 4365 | \rhs \lstinline$try$ \nonterm{compound-statement} \nonterm{handler-list}
|
---|
| 4366 | \rhs \lstinline$try$ \nonterm{compound-statement} \nonterm{finally-clause}
|
---|
| 4367 | \rhs \lstinline$try$ \nonterm{compound-statement} \nonterm{handler-list} \nonterm{finally-clause}
|
---|
| 4368 | \lhs{handler-list}
|
---|
| 4369 | \rhs \nonterm{handler-clause}
|
---|
| 4370 | \rhs \lstinline$catch$ \lstinline$($ \ldots \lstinline$)$ \nonterm{compound-statement}
|
---|
| 4371 | \rhs \nonterm{handler-clause} \lstinline$catch$ \lstinline$($ \ldots \lstinline$)$ \nonterm{compound-statement}
|
---|
| 4372 | \rhs \lstinline$catchResume$ \lstinline$($ \ldots \lstinline$)$ \nonterm{compound-statement}
|
---|
| 4373 | \rhs \nonterm{handler-clause} \lstinline$catchResume$ \lstinline$($ \ldots \lstinline$)$ \nonterm{compound-statement}
|
---|
| 4374 | \lhs{handler-clause}
|
---|
| 4375 | \rhs \lstinline$catch$ \lstinline$($ \nonterm{exception-declaration} \lstinline$)$ \nonterm{compound-statement}
|
---|
| 4376 | \rhs \nonterm{handler-clause} \lstinline$catch$ \lstinline$($ \nonterm{exception-declaration} \lstinline$)$ \nonterm{compound-statement}
|
---|
| 4377 | \rhs \lstinline$catchResume$ \lstinline$($ \nonterm{exception-declaration} \lstinline$)$ \nonterm{compound-statement}
|
---|
| 4378 | \rhs \nonterm{handler-clause} \lstinline$catchResume$ \lstinline$($ \nonterm{exception-declaration} \lstinline$)$ \nonterm{compound-statement}
|
---|
| 4379 | \lhs{finally-clause}
|
---|
| 4380 | \rhs \lstinline$finally$ \nonterm{compound-statement}
|
---|
| 4381 | \lhs{exception-declaration}
|
---|
| 4382 | \rhs \nonterm{type-specifier}
|
---|
| 4383 | \rhs \nonterm{type-specifier} \nonterm{declarator}
|
---|
| 4384 | \rhs \nonterm{type-specifier} \nonterm{abstract-declarator}
|
---|
| 4385 | \rhs \nonterm{new-abstract-declarator-tuple} \nonterm{identifier}
|
---|
| 4386 | \rhs \nonterm{new-abstract-declarator-tuple}
|
---|
| 4387 | \lhs{asynchronous-statement}
|
---|
| 4388 | \rhs \lstinline$enable$ \nonterm{identifier-list} \nonterm{compound-statement}
|
---|
| 4389 | \rhs \lstinline$disable$ \nonterm{identifier-list} \nonterm{compound-statement}
|
---|
| 4390 | \end{syntax}
|
---|
| 4391 |
|
---|
| 4392 | \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}.
|
---|
| 4393 |
|
---|
| 4394 |
|
---|
| 4395 | \subsubsection{The \lstinline$try$ statement}
|
---|
| 4396 |
|
---|
| 4397 | The \lstinline$try$ statement is a block with associated handlers, called a \Index{guarded block};
|
---|
| 4398 | all other blocks are \Index{unguarded block}s.
|
---|
| 4399 | 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.
|
---|
| 4400 |
|
---|
| 4401 |
|
---|
| 4402 | \subsubsection{The \lstinline$enable$/\lstinline$disable$ statements}
|
---|
| 4403 |
|
---|
[a188b16] | 4404 | The \lstinline$enable$/\lstinline$disable$ statements toggle delivery of \Index{asynchronous exception}s.
|
---|
[f60d997] | 4405 |
|
---|
| 4406 |
|
---|
| 4407 | \setcounter{section}{9}
|
---|
| 4408 | \section{Preprocessing directives}
|
---|
| 4409 |
|
---|
| 4410 |
|
---|
| 4411 | \setcounter{subsection}{7}
|
---|
| 4412 | \subsection{Predefined macro names}
|
---|
| 4413 |
|
---|
| 4414 | The implementation shall define the macro names \lstinline$__LINE__$, \lstinline$__FILE__$,
|
---|
| 4415 | \lstinline$__DATE__$, and \lstinline$__TIME__$, as in the {\c11} standard. It shall not define the
|
---|
| 4416 | macro name \lstinline$__STDC__$.
|
---|
| 4417 |
|
---|
| 4418 | In addition, the implementation shall define the macro name \lstinline$__CFORALL__$ to be the
|
---|
| 4419 | decimal constant 1.
|
---|
| 4420 |
|
---|
| 4421 |
|
---|
| 4422 | \appendix
|
---|
| 4423 |
|
---|
[2fc0e5c] | 4424 |
|
---|
[f60d997] | 4425 | \chapter{Examples}
|
---|
| 4426 |
|
---|
[2fc0e5c] | 4427 |
|
---|
[f60d997] | 4428 | \section{C types}
|
---|
| 4429 | This section gives example specifications for some groups of types that are important in the C
|
---|
| 4430 | language, in terms of the predefined operations that can be applied to those types.
|
---|
| 4431 |
|
---|
| 4432 |
|
---|
| 4433 | \subsection{Scalar, arithmetic, and integral types}
|
---|
| 4434 |
|
---|
| 4435 | The pointer, integral, and floating-point types are all \define{scalar types}. All of these types
|
---|
| 4436 | can be logically negated and compared. The assertion ``\lstinline$scalar( Complex )$'' should be read
|
---|
| 4437 | as ``type \lstinline$Complex$ is scalar''.
|
---|
| 4438 | \begin{lstlisting}
|
---|
| 4439 | context scalar( type T ) {@\impl{scalar}@
|
---|
| 4440 | int !?( T );
|
---|
| 4441 | int ?<?( T, T ), ?<=?( T, T ), ?==?( T, T ), ?>=?( T, T ), ?>?( T, T ), ?!=?( T, T );
|
---|
| 4442 | };
|
---|
| 4443 | \end{lstlisting}
|
---|
| 4444 |
|
---|
| 4445 | The integral and floating-point types are \define{arithmetic types}, which support the basic
|
---|
| 4446 | arithmetic operators. The use of an assertion in the \nonterm{spec-parameter-list} declares that,
|
---|
| 4447 | in order to be arithmetic, a type must also be scalar ( and hence that scalar operations are
|
---|
| 4448 | available ). This is equivalent to inheritance of specifications.
|
---|
| 4449 | \begin{lstlisting}
|
---|
| 4450 | context arithmetic( type T | scalar( T ) ) {@\impl{arithmetic}@@\use{scalar}@
|
---|
| 4451 | T +?( T ), -?( T );
|
---|
| 4452 | T ?*?( T, T ), ?/?( T, T ), ?+?( T, T ), ?-?( T, T );
|
---|
| 4453 | };
|
---|
| 4454 | \end{lstlisting}
|
---|
| 4455 |
|
---|
| 4456 | The various flavors of \lstinline$char$ and \lstinline$int$ and the enumerated types make up the
|
---|
| 4457 | \define{integral types}.
|
---|
| 4458 | \begin{lstlisting}
|
---|
| 4459 | context integral( type T | arithmetic( T ) ) {@\impl{integral}@@\use{arithmetic}@
|
---|
| 4460 | T ~?( T );
|
---|
| 4461 | T ?&?( T, T ), ?|?( T, T ), ?^?( T, T );
|
---|
| 4462 | T ?%?( T, T );
|
---|
| 4463 | T ?<<?( T, T ), ?>>?( T, T );
|
---|
| 4464 | };
|
---|
| 4465 | \end{lstlisting}
|
---|
| 4466 |
|
---|
| 4467 |
|
---|
| 4468 | \subsection{Modifiable types}
|
---|
| 4469 | \index{modifiable lvalue}
|
---|
| 4470 |
|
---|
| 4471 | The only operation that can be applied to all modifiable lvalues is simple assignment.
|
---|
| 4472 | \begin{lstlisting}
|
---|
| 4473 | context m_lvalue( type T ) {@\impl{m_lvalue}@
|
---|
| 4474 | T ?=?( T *, T );
|
---|
| 4475 | };
|
---|
| 4476 | \end{lstlisting}
|
---|
| 4477 |
|
---|
| 4478 | Modifiable scalar lvalues are scalars and are modifiable lvalues, and assertions in the
|
---|
| 4479 | \nonterm{spec-parameter-list} reflect those relationships. This is equivalent to multiple
|
---|
| 4480 | inheritance of specifications. Scalars can also be incremented and decremented.
|
---|
| 4481 | \begin{lstlisting}
|
---|
| 4482 | context m_l_scalar( type T | scalar( T ) | m_lvalue( T ) ) {@\impl{m_l_scalar}@
|
---|
| 4483 | T ?++( T * ), ?--( T * );@\use{scalar}@@\use{m_lvalue}@
|
---|
| 4484 | T ++?( T * ), --?( T * );
|
---|
| 4485 | };
|
---|
| 4486 | \end{lstlisting}
|
---|
| 4487 |
|
---|
| 4488 | Modifiable arithmetic lvalues are both modifiable scalar lvalues and arithmetic. Note that this
|
---|
| 4489 | results in the ``inheritance'' of \lstinline$scalar$ along both paths.
|
---|
| 4490 | \begin{lstlisting}
|
---|
| 4491 | context m_l_arithmetic( type T | m_l_scalar( T ) | arithmetic( T ) ) {@\impl{m_l_arithmetic}@
|
---|
| 4492 | T ?/=?( T *, T ), ?*=?( T *, T );@\use{m_l_scalar}@@\use{arithmetic}@
|
---|
| 4493 | T ?+=?( T *, T ), ?-=?( T *, T );
|
---|
| 4494 | };
|
---|
| 4495 |
|
---|
| 4496 | context m_l_integral( type T | m_l_arithmetic( T ) | integral( T ) ) {@\impl{m_l_integral}@
|
---|
| 4497 | T ?&=?( T *, T ), ?|=?( T *, T ), ?^=?( T *, T );@\use{m_l_arithmetic}@
|
---|
| 4498 | T ?%=?( T *, T ), ?<<=?( T *, T ), ?>>=?( T *, T );@\use{integral}@
|
---|
| 4499 | };
|
---|
| 4500 | \end{lstlisting}
|
---|
| 4501 |
|
---|
| 4502 |
|
---|
| 4503 | \subsection{Pointer and array types}
|
---|
| 4504 |
|
---|
| 4505 | Array types can barely be said to exist in {\c11}, since in most cases an array name is treated as a
|
---|
| 4506 | constant pointer to the first element of the array, and the subscript expression
|
---|
| 4507 | ``\lstinline$a[i]$'' is equivalent to the dereferencing expression ``\lstinline$(*( a+( i )))$''.
|
---|
| 4508 | Technically, pointer arithmetic and pointer comparisons other than ``\lstinline$==$'' and
|
---|
| 4509 | ``\lstinline$!=$'' are only defined for pointers to array elements, but the type system does not
|
---|
| 4510 | enforce those restrictions. Consequently, there is no need for a separate ``array type''
|
---|
| 4511 | specification.
|
---|
| 4512 |
|
---|
| 4513 | Pointer types are scalar types. Like other scalar types, they have ``\lstinline$+$'' and
|
---|
| 4514 | ``\lstinline$-$'' operators, but the types do not match the types of the operations in
|
---|
| 4515 | \lstinline$arithmetic$, so these operators cannot be consolidated in \lstinline$scalar$.
|
---|
| 4516 | \begin{lstlisting}
|
---|
| 4517 | context pointer( type P | scalar( P ) ) {@\impl{pointer}@@\use{scalar}@
|
---|
| 4518 | P ?+?( P, long int ), ?+?( long int, P ), ?-?( P, long int );
|
---|
| 4519 | ptrdiff_t ?-?( P, P );
|
---|
| 4520 | };
|
---|
| 4521 |
|
---|
| 4522 | context m_l_pointer( type P | pointer( P ) | m_l_scalar( P ) ) {@\impl{m_l_pointer}@
|
---|
| 4523 | P ?+=?( P *, long int ), ?-=?( P *, long int );
|
---|
| 4524 | P ?=?( P *, void * );
|
---|
| 4525 | void * ?=?( void **, P );
|
---|
| 4526 | };
|
---|
| 4527 | \end{lstlisting}
|
---|
| 4528 |
|
---|
[2fc0e5c] | 4529 | Specifications that define the dereference operator ( or subscript operator ) require two
|
---|
| 4530 | parameters, one for the pointer type and one for the pointed-at ( or element ) type. Different
|
---|
| 4531 | specifications are needed for each set of \Index{type qualifier}s, because qualifiers are not
|
---|
| 4532 | included in types. The assertion ``\lstinline$|ptr_to( Safe_pointer, int )$'' should be read as
|
---|
[f60d997] | 4533 | ``\lstinline$Safe_pointer$ acts like a pointer to \lstinline$int$''.
|
---|
| 4534 | \begin{lstlisting}
|
---|
| 4535 | context ptr_to( type P | pointer( P ), type T ) {@\impl{ptr_to}@@\use{pointer}@
|
---|
| 4536 | lvalue T *?( P ); lvalue T ?[?]( P, long int );
|
---|
| 4537 | };
|
---|
| 4538 |
|
---|
| 4539 | context ptr_to_const( type P | pointer( P ), type T ) {@\impl{ptr_to_const}@
|
---|
| 4540 | const lvalue T *?( P ); const lvalue T ?[?]( P, long int );@\use{pointer}@
|
---|
| 4541 | };
|
---|
| 4542 |
|
---|
| 4543 | context ptr_to_volatile( type P | pointer( P ), type T ) }@\impl{ptr_to_volatile}@
|
---|
| 4544 | volatile lvalue T *?( P ); volatile lvalue T ?[?]( P, long int );@\use{pointer}@
|
---|
| 4545 | };
|
---|
| 4546 | \end{lstlisting}
|
---|
| 4547 | \begin{lstlisting}
|
---|
| 4548 | context ptr_to_const_volatile( type P | pointer( P ), type T ) }@\impl{ptr_to_const_volatile}@
|
---|
| 4549 | const volatile lvalue T *?( P );@\use{pointer}@
|
---|
| 4550 | const volatile lvalue T ?[?]( P, long int );
|
---|
| 4551 | };
|
---|
| 4552 | \end{lstlisting}
|
---|
| 4553 |
|
---|
| 4554 | Assignment to pointers is more complicated than is the case with other types, because the target's
|
---|
| 4555 | type can have extra type qualifiers in the pointed-at type: a ``\lstinline$T *$'' can be assigned to
|
---|
| 4556 | a ``\lstinline$const T *$'', a ``\lstinline$volatile T *$'', and a ``\lstinline$const volatile T *$''.
|
---|
| 4557 | Again, the pointed-at type is passed in, so that assertions can connect these specifications to the
|
---|
| 4558 | ``\lstinline$ptr_to$'' specifications.
|
---|
| 4559 | \begin{lstlisting}
|
---|
| 4560 | 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}@ {
|
---|
| 4561 | P ?=?( P *, T * );
|
---|
| 4562 | T * ?=?( T **, P );
|
---|
| 4563 | };
|
---|
| 4564 |
|
---|
| 4565 | 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}@) {
|
---|
| 4566 | P ?=?( P *, const T * );
|
---|
| 4567 | const T * ?=?( const T **, P );
|
---|
| 4568 | };
|
---|
| 4569 |
|
---|
| 4570 | 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}@
|
---|
| 4571 | P ?=?( P *, volatile T * );
|
---|
| 4572 | volatile T * ?=?( volatile T **, P );
|
---|
| 4573 | };
|
---|
| 4574 |
|
---|
| 4575 | 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}@
|
---|
| 4576 | 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}@
|
---|
| 4577 | P ?=?( P *, const volatile T * );
|
---|
| 4578 | const volatile T * ?=?( const volatile T **, P );
|
---|
| 4579 | };
|
---|
| 4580 | \end{lstlisting}
|
---|
| 4581 |
|
---|
| 4582 | Note the regular manner in which type qualifiers appear in those specifications. An alternative
|
---|
| 4583 | specification can make use of the fact that qualification of the pointed-at type is part of a
|
---|
| 4584 | pointer type to capture that regularity.
|
---|
| 4585 | \begin{lstlisting}
|
---|
| 4586 | 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 ) ) {
|
---|
| 4587 | MyP ?=?( MyP *, CP );
|
---|
| 4588 | CP ?=?( CP *, MyP );
|
---|
| 4589 | };
|
---|
| 4590 | \end{lstlisting}
|
---|
| 4591 | The assertion ``\lstinline$| m_l_ptr_like( Safe_ptr, const int * )$'' should be read as
|
---|
| 4592 | ``\lstinline$Safe_ptr$ is a pointer type like \lstinline$const int *$''. This specification has two
|
---|
| 4593 | defects, compared to the original four: there is no automatic assertion that dereferencing a
|
---|
| 4594 | \lstinline$MyP$ produces an lvalue of the type that \lstinline$CP$ points at, and the
|
---|
| 4595 | ``\lstinline$|m_l_pointer( CP )$'' assertion provides only a weak assurance that the argument passed
|
---|
| 4596 | to \lstinline$CP$ really is a pointer type.
|
---|
| 4597 |
|
---|
| 4598 |
|
---|
| 4599 | \section{Relationships between operations}
|
---|
| 4600 |
|
---|
| 4601 | Different operators often have related meanings; for instance, in C, ``\lstinline$+$'',
|
---|
| 4602 | ``\lstinline$+=$'', and the two versions of ``\lstinline$++$'' perform variations of addition.
|
---|
| 4603 | Languages like {\CC} and Ada allow programmers to define operators for new types, but do not
|
---|
| 4604 | require that these relationships be preserved, or even that all of the operators be implemented.
|
---|
| 4605 | Completeness and consistency is left to the good taste and discretion of the programmer. It is
|
---|
| 4606 | possible to encourage these attributes by providing generic operator functions, or member functions
|
---|
| 4607 | of abstract classes, that are defined in terms of other, related operators.
|
---|
| 4608 |
|
---|
| 4609 | In \CFA, polymorphic functions provide the equivalent of these generic operators, and
|
---|
| 4610 | specifications explicitly define the minimal implementation that a programmer should provide. This
|
---|
| 4611 | section shows a few examples.
|
---|
| 4612 |
|
---|
| 4613 |
|
---|
| 4614 | \subsection{Relational and equality operators}
|
---|
| 4615 |
|
---|
| 4616 | The different comparison operators have obvious relationships, but there is no obvious subset of the
|
---|
| 4617 | operations to use in the implementation of the others. However, it is usually convenient to
|
---|
| 4618 | implement a single comparison function that returns a negative integer, 0, or a positive integer if
|
---|
| 4619 | its first argument is respectively less than, equal to, or greater than its second argument; the
|
---|
| 4620 | library function \lstinline$strcmp$ is an example.
|
---|
| 4621 |
|
---|
| 4622 | C and \CFA have an extra, non-obvious comparison operator: ``\lstinline$!$'', logical negation,
|
---|
| 4623 | returns 1 if its operand compares equal to 0, and 0 otherwise.
|
---|
| 4624 | \begin{lstlisting}
|
---|
| 4625 | context comparable( type T ) {
|
---|
| 4626 | const T 0;
|
---|
| 4627 | int compare( T, T );
|
---|
| 4628 | }
|
---|
| 4629 |
|
---|
| 4630 | forall( type T | comparable( T ) ) int ?<?( T l, T r ) {
|
---|
| 4631 | return compare( l, r ) < 0;
|
---|
| 4632 | }
|
---|
| 4633 | // ... similarly for <=, ==, >=, >, and !=.
|
---|
| 4634 |
|
---|
| 4635 | forall( type T | comparable( T ) ) int !?( T operand ) {
|
---|
| 4636 | return !compare( operand, 0 );
|
---|
| 4637 | }
|
---|
| 4638 | \end{lstlisting}
|
---|
| 4639 |
|
---|
| 4640 |
|
---|
| 4641 | \subsection{Arithmetic and integer operations}
|
---|
| 4642 |
|
---|
| 4643 | A complete arithmetic type would provide the arithmetic operators and the corresponding assignment
|
---|
| 4644 | operators. Of these, the assignment operators are more likely to be implemented directly, because
|
---|
| 4645 | it is usually more efficient to alter the contents of an existing object than to create and return a
|
---|
| 4646 | new one. Similarly, a complete integral type would provide integral operations based on integral
|
---|
| 4647 | assignment operations.
|
---|
| 4648 | \begin{lstlisting}
|
---|
| 4649 | context arith_base( type T ) {
|
---|
| 4650 | const T 1;
|
---|
| 4651 | T ?+=?( T *, T ), ?-=?( T *, T ), ?*=?( T *, T ), ?/=?( T *, T );
|
---|
| 4652 | }
|
---|
| 4653 |
|
---|
| 4654 | forall( type T | arith_base( T ) ) T ?+?( T l, T r ) {
|
---|
| 4655 | return l += r;
|
---|
| 4656 | }
|
---|
| 4657 |
|
---|
| 4658 | forall( type T | arith_base( T ) ) T ?++( T * operand ) {
|
---|
| 4659 | T temporary = *operand;
|
---|
| 4660 | *operand += 1;
|
---|
| 4661 | return temporary;
|
---|
| 4662 | }
|
---|
| 4663 |
|
---|
| 4664 | forall( type T | arith_base( T ) ) T ++?( T * operand ) {
|
---|
| 4665 | return *operand += 1;
|
---|
| 4666 | }
|
---|
| 4667 | // ... similarly for -, --, *, and /.
|
---|
| 4668 |
|
---|
| 4669 | context int_base( type T ) {
|
---|
| 4670 | T ?&=?( T *, T ), ?|=?( T *, T ), ?^=?( T *, T );
|
---|
| 4671 | T ?%=?( T *, T ), ?<<=?( T *, T ), ?>>=?( T *, T );
|
---|
| 4672 | }
|
---|
| 4673 |
|
---|
| 4674 | forall( type T | int_base( T ) ) T ?&?( T l, T r ) {
|
---|
| 4675 | return l &= r;
|
---|
| 4676 | }
|
---|
| 4677 | // ... similarly for |, ^, %, <<, and >>.
|
---|
| 4678 | \end{lstlisting}
|
---|
| 4679 |
|
---|
| 4680 | Note that, although an arithmetic type would certainly provide comparison functions, and an integral
|
---|
| 4681 | type would provide arithmetic operations, there does not have to be any relationship among
|
---|
| 4682 | \lstinline$int_base$, \lstinline$arith_base$ and \lstinline$comparable$. Note also that these
|
---|
| 4683 | declarations provide guidance and assistance, but they do not define an absolutely minimal set of
|
---|
| 4684 | requirements. A truly minimal implementation of an arithmetic type might only provide
|
---|
| 4685 | \lstinline$0$, \lstinline$1$, and \lstinline$?-=?$, which would be used by polymorphic
|
---|
| 4686 | \lstinline$?+=?$, \lstinline$?*=?$, and \lstinline$?/=?$ functions.
|
---|
| 4687 |
|
---|
| 4688 | Note also that \lstinline$short$ is an integer type in C11 terms, but has no operations!
|
---|
| 4689 |
|
---|
| 4690 |
|
---|
| 4691 | \chapter{TODO}
|
---|
| 4692 | Review index entries.
|
---|
| 4693 |
|
---|
| 4694 | Restrict allowed to qualify anything, or type/dtype parameters, but only affects pointers. This gets
|
---|
| 4695 | into \lstinline$noalias$ territory. Qualifying anything (``\lstinline$short restrict rs$'') means
|
---|
| 4696 | pointer parameters of \lstinline$?++$, etc, would need restrict qualifiers.
|
---|
| 4697 |
|
---|
| 4698 | Enumerated types. Constants are not ints. Overloading. Definition should be ``representable as an
|
---|
| 4699 | integer type'', not ``as an int''. C11 usual conversions freely convert to and from ordinary
|
---|
| 4700 | integer types via assignment, which works between any integer types. Does enum Color ?*?( enum
|
---|
| 4701 | Color, enum Color ) really make sense? ?++ does, but it adds (int)1.
|
---|
| 4702 |
|
---|
| 4703 | Operators on {,signed,unsigned} char and other small types. ?<? harmless; ?*? questionable for
|
---|
| 4704 | chars. Generic selections make these choices visible. Safe conversion operators? Predefined
|
---|
| 4705 | ``promotion'' function?
|
---|
| 4706 |
|
---|
| 4707 | \lstinline$register$ assignment might be handled as assignment to a temporary with copying back and
|
---|
| 4708 | forth, but copying must not be done by assignment.
|
---|
| 4709 |
|
---|
| 4710 | Don't use ptrdiff\_t by name in the predefineds.
|
---|
| 4711 |
|
---|
| 4712 | Polymorphic objects. Polymorphic typedefs and type declarations.
|
---|
| 4713 |
|
---|
| 4714 |
|
---|
| 4715 | \bibliographystyle{plain}
|
---|
| 4716 | \bibliography{refrat}
|
---|
| 4717 |
|
---|
| 4718 |
|
---|
| 4719 | \addcontentsline{toc}{chapter}{\indexname} % add index name to table of contents
|
---|
| 4720 | \begin{theindex}
|
---|
| 4721 | Italic page numbers give the location of the main entry for the referenced term. Plain page numbers
|
---|
| 4722 | denote uses of the indexed term. Entries for grammar non-terminals are italicized. A typewriter
|
---|
| 4723 | font is used for grammar terminals and program identifiers.
|
---|
| 4724 | \indexspace
|
---|
| 4725 | \input{refrat.ind}
|
---|
| 4726 | \end{theindex}
|
---|
| 4727 |
|
---|
| 4728 | \end{document}
|
---|
| 4729 |
|
---|
| 4730 | % Local Variables: %
|
---|
| 4731 | % tab-width: 4 %
|
---|
| 4732 | % fill-column: 100 %
|
---|
| 4733 | % compile-command: "make" %
|
---|
| 4734 | % End: %
|
---|