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