Changeset 32a1e5fd for doc/refrat
 Timestamp:
 Sep 11, 2015, 1:01:14 PM (7 years ago)
 Branches:
 aaronthesis, armeh, cleanupdtors, ctor, deferred_resn, demangler, enum, forallpointerdecay, gc_noraii, jacob/cs343translation, jenkinssandbox, master, memory, newast, newastuniqueexpr, newenv, no_list, persistentindexer, resolvnew, string, with_gc
 Children:
 2fc0e5c, 76b48f1, 830c21a
 Parents:
 8a4da06 (diff), aa99647 (diff)
Note: this is a merge changeset, the changes displayed below correspond to the merge itself.
Use the(diff)
links above to see all the changes relative to each parent.  Location:
 doc/refrat
 Files:

 5 added
 1 edited
Legend:
 Unmodified
 Added
 Removed

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