 Timestamp:
 Mar 2, 2016, 4:59:19 PM (8 years ago)
 Branches:
 ADT, aaronthesis, armeh, astexperimental, cleanupdtors, ctor, deferred_resn, demangler, enum, forallpointerdecay, gc_noraii, jacob/cs343translation, jenkinssandbox, master, memory, newast, newastuniqueexpr, newenv, no_list, persistentindexer, pthreademulation, qualifiedEnum, resolvnew, string, with_gc
 Children:
 bdad1679
 Parents:
 ac1ed49
 Location:
 doc/refrat
 Files:

 2 edited
Legend:
 Unmodified
 Added
 Removed

doc/refrat/Makefile
rac1ed49 r90c3b1c 1 1 ## Define the appropriate configuration variables. 2 2 3 TeXLIB = .:: 3 Macros = 4 TeXLIB = .:${Macros}: 4 5 LaTeX = TEXINPUTS=${TeXLIB} && export TEXINPUTS && latex 5 6 BibTeX = BSTINPUTS=${TeXLIB} && export BSTINPUTS && bibtex 
doc/refrat/refrat.tex
rac1ed49 r90c3b1c 33 33 34 34 \makeatletter 35 % index macros 35 \renewcommand{\labelitemi}{{\raisebox{0.25ex}{\footnotesize$\bullet$}}} 36 \renewenvironment{itemize}{\begin{list}{\labelitemi}{\topsep=5pt\itemsep=5pt\parsep=0pt}}{\end{list}} 37 38 % Reduce size of chapter/section titles 39 \def\@makechapterhead#1{% 40 \vspace*{50\p@}% 41 {\parindent \z@ \raggedright \normalfont 42 \ifnum \c@secnumdepth >\m@ne 43 \large\bfseries \@chapapp\space \thechapter 44 \par\nobreak 45 \vskip 5\p@ 46 \fi 47 \interlinepenalty\@M 48 \Large \bfseries #1\par\nobreak 49 \vskip 50\p@ 50 }} 51 \def\@makeschapterhead#1{% 52 \vspace*{50\p@}% 53 {\parindent \z@ \raggedright 54 \normalfont 55 \interlinepenalty\@M 56 \Large \bfseries #1\par\nobreak 57 \vskip 50\p@ 58 }} 59 \renewcommand\section{\@startsection{section}{1}{\z@}{3.0ex \@plus 1ex \@minus .2ex}{1.0ex \@plus .2ex}{\normalfont\large\bfseries}} 60 \renewcommand\subsection{\@startsection{subsection}{2}{\z@}{2.5ex \@plus 1ex \@minus .2ex}{1.0ex \@plus .2ex}{\normalfont\normalsize\bfseries}} 61 \renewcommand\subsubsection{\@startsection{subsubsection}{3}{\z@}{2.0ex \@plus 1ex \@minus .2ex}{1.0ex \@plus .2ex}{\normalfont\normalsize\bfseries}} 62 \renewcommand\paragraph{\@startsection{paragraph}{4}{\z@}{2.0ex \@plus 1ex \@minus .2ex}{1em}{\normalfont\normalsize\bfseries}} 63 36 64 \newcommand{\italic}[1]{\emph{\hyperpage{#1}}} 37 65 \newcommand{\definition}[1]{\textbf{\hyperpage{#1}}} … … 60 88 %\newcommand{\impl}[1]{\index{\protect#1@{\lstinline$\protect#1$}definition}} 61 89 62 % text inline and lowercase index: \Index{Inline andindex text}63 % text inline and asin index: \Index{Inline and Indextext}64 % text inlinebut index with different asis text: \Index[index text]{inline text}90 % inline text and lowercase index: \Index{inline and lowercase index text} 91 % inline text and asin index: \Index[asis index text]{inline text} 92 % inline text but index with different asis text: \Index[index text]{inline text} 65 93 \newcommand{\Index}{\@ifstar\@sIndex\@Index} 66 94 \newcommand{\@Index}[2][\@empty]{\lowercase{\def\temp{#2}}#2\ifx#1\@empty\index{\temp}\else\index{#1@{\protect#2}}\fi} … … 145 173 \linenumbers % comment out to turn off line numbering 146 174 147 \title{\CFA (\CFAA) Reference Manual and Rationale} 148 \author{Glen Ditchfield \and Peter A. Buhr} 149 \date{DRAFT\\\today} 175 \title{\Huge 176 \CFA (\CFAA) Reference Manual and Rationale 177 }% title 178 \author{\huge 179 Glen Ditchfield and Peter A. Buhr 180 }% author 181 \date{ 182 DRAFT\\\today 183 }% date 150 184 151 185 \pagenumbering{roman} … … 159 193 \copyright\,2015 Glen Ditchfield \\ \\ 160 194 \noindent 161 This work is licensed under the Creative Commons Attribution 4.0 International License. To view a162 copy of this license, visit {\small\url{http://creativecommons.org/licenses/by/4.0}}.195 This work is licensed under the Creative Commons Attribution 4.0 International License. 196 To view a copy of this license, visit {\small\url{http://creativecommons.org/licenses/by/4.0}}. 163 197 \vspace*{1in} 164 198 … … 173 207 \chapter*{Introduction}\addcontentsline{toc}{chapter}{Introduction} 174 208 175 This document is a reference manual and rationale for \CFA, a polymorphic extension of the C 176 programming language. It makes frequent reference to the {\c11} standard \cite{ANS:C11}, and 177 occasionally compares \CFA to {\CC} \cite{c++}. 178 179 The manual deliberately imitates the ordering of the {\c11} standard (although the section numbering 180 differs). Unfortunately, this means the manual contains more ``forward references'' than usual, 181 making it harder to follow if the reader does not have a copy of the {\c11} standard. For a simple 182 introduction to \CFA, see the companion document ``An Overview of \CFA'' 209 This document is a reference manual and rationale for \CFA, a polymorphic extension of the C programming language. 210 It makes frequent reference to the {\c11} standard \cite{ANS:C11}, and occasionally compares \CFA to {\CC} \cite{c++}. 211 212 The manual deliberately imitates the ordering of the {\c11} standard (although the section numbering differs). 213 Unfortunately, this means the manual contains more ``forward references'' than usual, making it harder to follow if the reader does not have a copy of the {\c11} standard. 214 For a simple introduction to \CFA, see the companion document ``An Overview of \CFA'' 183 215 \cite{Ditchfield96:Overview}. 184 216 185 217 \begin{rationale} 186 Commentary (like this) is quoted with quads. Commentary usually deals with subtle points, the187 rationale behind a rule, and design decisions.218 Commentary (like this) is quoted with quads. 219 Commentary usually deals with subtle points, the rationale behind a rule, and design decisions. 188 220 \end{rationale} 189 221 … … 194 226 \chapter{Terms, definitions, and symbols} 195 227 196 Terms from the {\c11} standard used in this document have the same meaning as in the {\c11} 197 standard. 228 Terms from the {\c11} standard used in this document have the same meaning as in the {\c11} standard. 198 229 199 230 % No ``Conformance'' or ``Environment'' chapters yet. … … 205 236 206 237 \section{Notation} 207 The syntax notation used in this document is the same as in the {\c11} standard, with one exception: 208 ellipsis in the definition of a nonterminal, as in ``\emph{declaration:} \ldots'', indicates that 209 these rules extend a previous definition, which occurs in this document or in the {\c11} standard. 238 The syntax notation used in this document is the same as in the {\c11} standard, with one exception: ellipsis in the definition of a nonterminal, as in ``\emph{declaration:} \ldots'', indicates that these rules extend a previous definition, which occurs in this document or in the {\c11} standard. 210 239 211 240 … … 215 244 \subsection{Scopes of identifiers}\index{scopes} 216 245 217 \CFA's scope rules differ from C's in one major respect: a declaration of an identifier may 218 overload\index{overloading} outer declarations of lexically identical identifiers in the same 219 \Index{name space}, instead of hiding them. The outer declaration is hidden if the two declarations 220 have \Index{compatible type}, or if one declares an array type and the other declares a pointer type 221 and the element type and pointedat type are compatible, or if one has function type and the other 222 is a pointer to a compatible function type, or if one declaration is a \lstinline$type$\use{type} or 246 \CFA's scope rules differ from C's in one major respect: a declaration of an identifier may overload\index{overloading} outer declarations of lexically identical identifiers in the same 247 \Index{name space}, instead of hiding them. 248 The outer declaration is hidden if the two declarations have \Index{compatible type}, or if one declares an array type and the other declares a pointer type and the element type and pointedat type are compatible, or if one has function type and the other is a pointer to a compatible function type, or if one declaration is a \lstinline$type$\use{type} or 223 249 \lstinline$typedef$\use{typedef} declaration and the other is not. The outer declaration becomes 224 250 \Index{visible} when the scope of the inner declaration terminates. 225 251 \begin{rationale} 226 Hence, a \CFA program can declare an \lstinline$int v$ and a \lstinline$float v$ in the same 227 scope;a {\CC} program can not.252 Hence, a \CFA program can declare an \lstinline$int v$ and a \lstinline$float v$ in the same scope; 253 a {\CC} program can not. 228 254 \end{rationale} 229 255 … … 232 258 \index{linkage} 233 259 234 \CFA's linkage rules differ from C's in only one respect: instances of a particular identifier with 235 external or internal linkage do not necessarily denote the same object or function. Instead, in the 236 set of translation units and libraries that constitutes an entire program, any two instances of a 237 particular identifier with \Index{external linkage} denote the same object or function if they have 238 \Index{compatible type}s, or if one declares an array type and the other declares a pointer type and 239 the element type and pointedat type are compatible, or if one has function type and the other is a 240 pointer to a compatible function type. Within one translation unit, each instance of an identifier 241 with \Index{internal linkage} denotes the same object or function in the same circumstances. 260 \CFA's linkage rules differ from C's in only one respect: instances of a particular identifier with external or internal linkage do not necessarily denote the same object or function. 261 Instead, in the set of translation units and libraries that constitutes an entire program, any two instances of a particular identifier with \Index{external linkage} denote the same object or function if they have 262 \Index{compatible type}s, or if one declares an array type and the other declares a pointer type and the element type and pointedat type are compatible, or if one has function type and the other is a pointer to a compatible function type. 263 Within one translation unit, each instance of an identifier with \Index{internal linkage} denotes the same object or function in the same circumstances. 242 264 Identifiers with \Index{no linkage} always denote unique entities. 243 265 \begin{rationale} 244 A \CFA program can declare an \lstinline$extern int v$ and an \lstinline$extern float v$; a C245 program cannot.266 A \CFA program can declare an \lstinline$extern int v$ and an \lstinline$extern float v$; 267 a C program cannot. 246 268 \end{rationale} 247 269 … … 253 275 \subsubsection{Semantics} 254 276 255 \CFA provides a capability for generic types; using this capability a single "generic type 256 generator" can be written that can represent multiple concrete type instantiations by substitution 257 of the "type parameters" of the generic type for concrete types. Syntactically a generic type 258 generator is represented by putting a forall specifier on a struct or union declaration, as defined 259 in \VRef{forall}. An instantiation of the generic type is written by specifying the type parameters 260 in parentheses after the name of the generic type generator: 277 \CFA provides a capability for generic types; 278 using this capability a single "generic type generator" can be written that can represent multiple concrete type instantiations by substitution of the "type parameters" of the generic type for concrete types. 279 Syntactically a generic type generator is represented by putting a forall specifier on a struct or union declaration, as defined in \VRef{forall}. 280 An instantiation of the generic type is written by specifying the type parameters in parentheses after the name of the generic type generator: 261 281 \begin{lstlisting} 262 282 forall( type T  sumable( T ) ) struct pair { … … 267 287 \end{lstlisting} 268 288 269 The type parameters in an instantiation of a generic type must satisfy any constraints in the forall 270 specifier on the type generator declaration, e.g., \lstinline$sumable$. The instantiation then has 271 the semantics that would result if the type parameters were substituted into the type generator 272 declaration by macro substitution. 273 274 Polymorphic functions may have generic types as parameters, and those generic types may use type 275 parameters of the polymorphic function as type parameters of the generic type: 289 The type parameters in an instantiation of a generic type must satisfy any constraints in the forall specifier on the type generator declaration, e.g., \lstinline$sumable$. 290 The instantiation then has the semantics that would result if the type parameters were substituted into the type generator declaration by macro substitution. 291 292 Polymorphic functions may have generic types as parameters, and those generic types may use type parameters of the polymorphic function as type parameters of the generic type: 276 293 \begin{lstlisting} 277 294 forall( type T ) void swap( pair(T) *p ) { … … 285 302 \subsubsection{Constraints} 286 303 287 To avoid unduly constraining implementors, the generic type generator definition must be visible at 288 any point where it is instantiated. Forward declarations of generic type generators are not 289 forbidden, but the definition must be visible to instantiate the generic type. Equivalently, 290 instantiations of generic types are not allowed to be incomplete types. 304 To avoid unduly constraining implementors, the generic type generator definition must be visible at any point where it is instantiated. Forward declarations of generic type generators are not forbidden, but the definition must be visible to instantiate the generic type. Equivalently, instantiations of generic types are not allowed to be incomplete types. 291 305 292 306 \examples … … 295 309 296 310 forall( type T ) struct B { 297 A(T) *a; 311 A(T) *a; // legal, but cannot instantiate B(T) 298 312 }; 299 313 300 B(T) x; 301 314 B(T) x; // illegal, *x.a is of an incomplete generic type 315 302 316 forall( type T ) struct A { 303 317 B( T ) *b; 304 318 }; 305 319 306 B( T ) y; // legal, *x.a is now of a complete generic type 307 320 B( T ) y; // legal, *x.a is now of a complete generic type 308 321 309 322 // box.h: … … 313 326 314 327 // main.c: 315 box( int ) *b = make_box( 42 ); // illegal, def 'n of box not visible316 use_box( b ); 328 box( int ) *b = make_box( 42 ); // illegal, definition of box not visible 329 use_box( b ); // illegal 317 330 \end{lstlisting} 318 331 … … 320 333 \section{Conversions} 321 334 \CFA defines situations where values of one type are automatically converted to another type. 322 These conversions are called \define{implicit conversion}s. The programmer can request 335 These conversions are called \define{implicit conversion}s. 336 The programmer can request 323 337 \define{explicit conversion}s using cast expressions. 324 338 … … 330 344 \subsubsection{Safe arithmetic conversions} 331 345 332 In C, a pattern of conversions known as the \define{usual arithmetic conversion}s is used with most 333 binary arithmetic operators to convert the operands to a common type and determine the type of the 334 operator's result. In \CFA, these conversions play a role in overload resolution, and 335 collectively are called the \define{safe arithmetic conversion}s. 336 337 Let \(int_r\) and \(unsigned_r\) be the signed and unsigned integer types with integer conversion 338 rank\index{integer conversion rank}\index{ranksee{integer conversion rank}} $r$. Let 339 \(unsigned_{mr}\) be the unsigned integer type with maximal rank. 346 In C, a pattern of conversions known as the \define{usual arithmetic conversion}s is used with most binary arithmetic operators to convert the operands to a common type and determine the type of the operator's result. 347 In \CFA, these conversions play a role in overload resolution, and collectively are called the \define{safe arithmetic conversion}s. 348 349 Let \(int_r\) and \(unsigned_r\) be the signed and unsigned integer types with integer conversion rank\index{integer conversion rank}\index{ranksee{integer conversion rank}} $r$. 350 Let \(unsigned_{mr}\) be the unsigned integer type with maximal rank. 340 351 341 352 The following conversions are \emph{direct} safe arithmetic conversions. … … 343 354 \item 344 355 The \Index{integer promotion}s. 345 346 \item 347 For every rank $r$ greater than or equal to the rank of \lstinline$int$, conversion from \(int_r\) 348 to \(unsigned_r\). 349 350 \item 351 For every rank $r$ greater than or equal to the rank of \lstinline$int$, where \(int_{r+1}\) exists 352 and can represent all values of \(unsigned_r\), conversion from \(unsigned_r\) to \(int_{r+1}\). 353 356 \item 357 For every rank $r$ greater than or equal to the rank of \lstinline$int$, conversion from \(int_r\) to \(unsigned_r\). 358 \item 359 For every rank $r$ greater than or equal to the rank of \lstinline$int$, where \(int_{r+1}\) exists and can represent all values of \(unsigned_r\), conversion from \(unsigned_r\) to \(int_{r+1}\). 354 360 \item 355 361 Conversion from \(unsigned_{mr}\) to \lstinline$float$. 356 357 362 \item 358 363 Conversion from an enumerated type to its compatible integer type. 359 360 \item 361 Conversion from \lstinline$float$ to \lstinline$double$, and from \lstinline$double$ to 362 \lstinline$long double$. 363 364 \item 365 Conversion from \lstinline$float _Complex$ to \lstinline$double _Complex$, 366 and from \lstinline$double _Complex$ to \lstinline$long double _Complex$. 367 364 \item 365 Conversion from \lstinline$float$ to \lstinline$double$, and from \lstinline$double$ to \lstinline$long double$. 366 \item 367 Conversion from \lstinline$float _Complex$ to \lstinline$double _Complex$, and from \lstinline$double _Complex$ to \lstinline$long double _Complex$. 368 368 \begin{sloppypar} 369 369 \item 370 Conversion from \lstinline$float _Imaginary$ to \lstinline$double _Imaginary$, and from 371 \lstinline$double _Imaginary$ to \lstinline$long double$ \lstinline$_Imaginary$, if the 372 implementation supports imaginary types. 370 Conversion from \lstinline$float _Imaginary$ to \lstinline$double _Imaginary$, and from \lstinline$double _Imaginary$ to \lstinline$long double$ \lstinline$_Imaginary$, if the implementation supports imaginary types. 373 371 \end{sloppypar} 374 372 \end{itemize} 375 373 376 If type \lstinline$T$ can be converted to type \lstinline$U$ by a safe direct arithmetic conversion 377 and type \lstinline$U$ can be converted to type \lstinline$V$ by a safe arithmetic conversion, then 378 the conversion from \lstinline$T$ to type \lstinline$V$ is an \emph{indirect} safe arithmetic 379 conversion. 380 381 \begin{rationale} 382 Note that {\c11} does not include conversion from \Index{real type}s to \Index{complex type}s in the 383 usual arithmetic conversions, and \CFA does not include them as safe conversions. 374 If type \lstinline$T$ can be converted to type \lstinline$U$ by a safe direct arithmetic conversion and type \lstinline$U$ can be converted to type \lstinline$V$ by a safe arithmetic conversion, then the conversion from \lstinline$T$ to type \lstinline$V$ is an \emph{indirect} safe arithmetic conversion. 375 376 \begin{rationale} 377 Note that {\c11} does not include conversion from \Index{real type}s to \Index{complex type}s in the usual arithmetic conversions, and \CFA does not include them as safe conversions. 384 378 \end{rationale} 385 379 … … 393 387 394 388 If an expression's type is a pointer to a structure or union type that has a member that is an 395 \Index{anonymous structure} or an \Index{anonymous union}, it can be implicitly 396 converted\index{implicit conversion} to a pointer to the anonymous structure's or anonymous union's 397 type. The result of the conversion is a pointer to the member. 389 \Index{anonymous structure} or an \Index{anonymous union}, it can be implicitly converted\index{implicit conversion} to a pointer to the anonymous structure's or anonymous union's type. 390 The result of the conversion is a pointer to the member. 398 391 399 392 \examples … … 402 395 int x, y; 403 396 }; 404 void move_by( struct point * p1, struct point * p2) {@\impl{move_by}@397 void move_by( struct point * p1, struct point * p2 ) {@\impl{move_by}@ 405 398 p1>x += p2.x; 406 399 p1>y += p2.y; 407 400 } 408 409 401 struct color_point { 410 402 enum { RED, BLUE, GREEN } color; 411 403 struct point; 412 404 } cp1, cp2; 413 move_to( &cp1, &cp2);405 move_to( &cp1, &cp2 ); 414 406 \end{lstlisting} 415 407 Thanks to implicit conversion, the two arguments that \lstinline$move_by()$ receives are pointers to … … 419 411 \subsubsection{Specialization} 420 412 A function or value whose type is polymorphic may be implicitly converted to one whose type is 421 \Index{less polymorphic} by binding values to one or more of its \Index{inferred parameter}. Any 422 value that is legal for the inferred parameter may be used, including other inferred parameters. 423 424 If, after the inferred parameter binding, an \Index{assertion parameter} has no inferred parameters 425 in its type, then an object or function must be visible at the point of the specialization that has 426 the same identifier as the assertion parameter and has a type that is compatible\index{compatible 427 type} with or can be specialized to the type of the assertion parameter. The assertion parameter 428 is bound to that object or function. 429 430 The type of the specialization is the type of the original with the bound inferred parameters and 431 the bound assertion parameters replaced by their bound values. 413 \Index{less polymorphic} by binding values to one or more of its \Index{inferred parameter}. 414 Any value that is legal for the inferred parameter may be used, including other inferred parameters. 415 416 If, after the inferred parameter binding, an \Index{assertion parameter} has no inferred parameters in its type, then an object or function must be visible at the point of the specialization that has the same identifier as the assertion parameter and has a type that is compatible\index{compatible 417 type} with or can be specialized to the type of the assertion parameter. The assertion parameter is bound to that object or function. 418 419 The type of the specialization is the type of the original with the bound inferred parameters and the bound assertion parameters replaced by their bound values. 432 420 433 421 \examples … … 438 426 can be specialized to (among other things) 439 427 \begin{lstlisting} 440 forall( type T ) void (*)( T, T ); // U bound to T 441 forall( type T ) void (*)( T, real ); // U bound to real 442 forall( type U ) void (*)( real, U ); // T bound to real 428 forall( type T ) void (*)( T, T ); // U bound to T 429 forall( type T ) void (*)( T, real ); // U bound to real 430 forall( type U ) void (*)( real, U ); // T bound to real 443 431 void f( real, real ); // both bound to real 444 432 \end{lstlisting} … … 446 434 The type 447 435 \begin{lstlisting} 448 forall( type T  T ?+?( T, T ) ) T (*)( T );436 forall( type T  T ?+?( T, T ) ) T (*)( T ); 449 437 \end{lstlisting} 450 438 can be specialized to (among other things) 451 439 \begin{lstlisting} 452 int (*)( int ); 440 int (*)( int ); // T bound to int, and T ?+?(T, T ) bound to int ?+?( int, int ) 453 441 \end{lstlisting} 454 442 … … 465 453 from a pointer to any non\lstinline$void$ type to a pointer to \lstinline$void$; 466 454 \item 467 from a pointer to any type to a pointer to a more qualified version of the type\index{qualified 468 type}; 469 \item 470 from a pointer to a structure or union type to a pointer to the type of a member of the structure or 471 union that is an \Index{anonymous structure} or an \Index{anonymous union}; 472 \item 473 within the scope of an initialized \Index{type declaration}, conversions between a type and its 474 implementation or between a pointer to a type and a pointer to its implementation. 455 from a pointer to any type to a pointer to a more qualified version of the type\index{qualified type}; 456 \item 457 from a pointer to a structure or union type to a pointer to the type of a member of the structure or union that is an \Index{anonymous structure} or an \Index{anonymous union}; 458 \item 459 within the scope of an initialized \Index{type declaration}, conversions between a type and its implementation or between a pointer to a type and a pointer to its implementation. 475 460 \end{itemize} 476 461 477 462 Conversions that are not safe conversions are \define{unsafe conversion}s. 478 463 \begin{rationale} 479 As in C, there is an implicit conversion from \lstinline$void *$ to any pointer type. This is 480 clearly dangerous, and {\CC} does not have this implicit conversion. 481 \CFA\index{deficiencies!void * conversion} keeps it, in the interest of remaining as pure a 482 superset of C as possible, but discourages it by making it unsafe. 464 As in C, there is an implicit conversion from \lstinline$void *$ to any pointer type. 465 This is clearly dangerous, and {\CC} does not have this implicit conversion. 466 \CFA\index{deficiencies!void * conversion} keeps it, in the interest of remaining as pure a superset of C as possible, but discourages it by making it unsafe. 483 467 \end{rationale} 484 468 … … 486 470 \subsection{Conversion cost} 487 471 488 The \define{conversion cost} of a safe\index{safe conversion} 489 conversion\footnote{Unsafe\index{unsafe conversion} conversions do not have defined conversion 490 costs.} is a measure of how desirable or undesirable it is. It is defined as follows. 472 The \define{conversion cost} of a safe\index{safe conversion} conversion\footnote{Unsafe\index{unsafe conversion} conversions do not have defined conversion costs.} is a measure of how desirable or undesirable it is. 473 It is defined as follows. 491 474 \begin{itemize} 492 475 \item … … 497 480 498 481 \item 499 The cost of an indirect safe arithmetic conversion is the smallest number of direct conversions 500 needed to make up the conversion. 482 The cost of an indirect safe arithmetic conversion is the smallest number of direct conversions needed to make up the conversion. 501 483 \end{itemize} 502 484 … … 506 488 \begin{itemize} 507 489 \item 508 The cost of an implicit conversion from \lstinline$int$ to \lstinline$long$ is 1. The cost of an 509 implicit conversion from \lstinline$long$ to \lstinline$double$ is 3, because it is defined in terms 510 of conversions from \lstinline$long$ to \lstinline$unsigned long$, then to \lstinline$float$, and 511 then to \lstinline$double$. 512 513 \item 514 If \lstinline$int$ can represent all the values of \lstinline$unsigned short$, then the cost of an 515 implicit conversion from \lstinline$unsigned short$ to \lstinline$unsigned$ is 2: 516 \lstinline$unsigned short$ to \lstinline$int$ to \lstinline$unsigned$. Otherwise, 490 The cost of an implicit conversion from \lstinline$int$ to \lstinline$long$ is 1. 491 The cost of an implicit conversion from \lstinline$long$ to \lstinline$double$ is 3, because it is defined in terms of conversions from \lstinline$long$ to \lstinline$unsigned long$, then to \lstinline$float$, and then to \lstinline$double$. 492 493 \item 494 If \lstinline$int$ can represent all the values of \lstinline$unsigned short$, then the cost of an implicit conversion from \lstinline$unsigned short$ to \lstinline$unsigned$ is 2: 495 \lstinline$unsigned short$ to \lstinline$int$ to \lstinline$unsigned$. 496 Otherwise, 517 497 \lstinline$unsigned short$ is converted directly to \lstinline$unsigned$, and the cost is 1. 518 498 519 499 \item 520 If \lstinline$long$ can represent all the values of \lstinline$unsigned$, then the conversion cost 521 of \lstinline$unsigned$ to \lstinline$long$ is 1. Otherwise, the conversion is an unsafe 522 conversion, and its conversion cost is undefined. 500 If \lstinline$long$ can represent all the values of \lstinline$unsigned$, then the conversion cost of \lstinline$unsigned$ to \lstinline$long$ is 1. 501 Otherwise, the conversion is an unsafe conversion, and its conversion cost is undefined. 523 502 \end{itemize} 524 503 … … 538 517 \subsection{Identifiers} 539 518 540 \CFA allows operator \Index{overloading} by associating operators with special function 541 identifiers. Furthermore, the constants ``\lstinline$0$'' and ``\lstinline$1$'' have special status 542 for many of C's data types (and for many programmerdefined data types as well), so \CFA treats them 543 as overloadable identifiers. Programmers can use these identifiers to declare functions and objects 544 that implement operators and constants for their own types. 519 \CFA allows operator \Index{overloading} by associating operators with special function identifiers. 520 Furthermore, the constants ``\lstinline$0$'' and ``\lstinline$1$'' have special status for many of C's data types (and for many programmerdefined data types as well), so \CFA treats them as overloadable identifiers. 521 Programmers can use these identifiers to declare functions and objects that implement operators and constants for their own types. 545 522 546 523 … … 554 531 \end{syntax} 555 532 556 \index{constant identifiers}\index{identifiers!for constants} The tokens ``\lstinline$0$''\impl{0} 557 and ``\lstinline$1$''\impl{1} are identifiers. No other tokens defined by the rules for integer 558 constants are considered to be identifiers. 559 \begin{rationale} 560 Why ``\lstinline$0$'' and ``\lstinline$1$''? Those integers have special status in C. All scalar 561 types can be incremented and decremented, which is defined in terms of adding or subtracting 1. The 562 operations ``\lstinline$&&$'', ``\lstinline$$'', and ``\lstinline$!$'' can be applied to any 563 scalar arguments, and are defined in terms of comparison against 0. A \nonterm{constantexpression} 564 that evaluates to 0 is effectively compatible with every pointer type. 565 566 In C, the integer constants 0 and 1 suffice because the integer promotion rules can convert them to 567 any arithmetic type, and the rules for pointer expressions treat constant expressions evaluating to 568 0 as a special case. However, userdefined arithmetic types often need the equivalent of a 1 or 0 569 for their functions or operators, polymorphic functions often need 0 and 1 constants of a type 570 matching their polymorphic parameters, and userdefined pointerlike types may need a null value. 571 Defining special constants for a userdefined type is more efficient than defining a conversion to 572 the type from \lstinline$_Bool$. 573 574 Why \emph{just} ``\lstinline$0$'' and ``\lstinline$1$''? Why not other integers? No other integers 575 have special status in C. A facility that let programmers declare specific 576 constants``\lstinline$const Rational 12$'', for instancewould not be much of an improvement. 577 Some facility for defining the creation of values of programmerdefined types from arbitrary integer 578 tokens would be needed. The complexity of such a feature doesn't seem worth the gain. 533 \index{constant identifiers}\index{identifiers!for constants} The tokens ``\lstinline$0$''\impl{0} and ``\lstinline$1$''\impl{1} are identifiers. 534 No other tokens defined by the rules for integer constants are considered to be identifiers. 535 \begin{rationale} 536 Why ``\lstinline$0$'' and ``\lstinline$1$''? Those integers have special status in C. 537 All scalar types can be incremented and decremented, which is defined in terms of adding or subtracting 1. 538 The operations ``\lstinline$&&$'', ``\lstinline$$'', and ``\lstinline$!$'' can be applied to any scalar arguments, and are defined in terms of comparison against 0. 539 A \nonterm{constantexpression} that evaluates to 0 is effectively compatible with every pointer type. 540 541 In C, the integer constants 0 and 1 suffice because the integer promotion rules can convert them to any arithmetic type, and the rules for pointer expressions treat constant expressions evaluating to 542 0 as a special case. 543 However, userdefined arithmetic types often need the equivalent of a 1 or 0 for their functions or operators, polymorphic functions often need 0 and 1 constants of a type matching their polymorphic parameters, and userdefined pointerlike types may need a null value. 544 Defining special constants for a userdefined type is more efficient than defining a conversion to the type from \lstinline$_Bool$. 545 546 Why \emph{just} ``\lstinline$0$'' and ``\lstinline$1$''? Why not other integers? No other integers have special status in C. 547 A facility that let programmers declare specific constants``\lstinline$const Rational 12$'', for instancewould not be much of an improvement. 548 Some facility for defining the creation of values of programmerdefined types from arbitrary integer tokens would be needed. 549 The complexity of such a feature doesn't seem worth the gain. 579 550 \end{rationale} 580 551 … … 582 553 \subsubsection{Operator identifiers} 583 554 584 \index{operator identifiers}\index{identifiers!for operators} Table \ref{opids} lists the 585 programmerdefinable operator identifiers and the operations they are associated with. Functions 586 that are declared with (or pointed at by function pointers that are declared with) these identifiers 587 can be called by expressions that use the operator tokens and syntax, or the operator identifiers 588 and ``function call'' syntax. The relationships between operators and function calls are discussed 589 in descriptions of the operators. 555 \index{operator identifiers}\index{identifiers!for operators} Table \ref{opids} lists the programmerdefinable operator identifiers and the operations they are associated with. 556 Functions that are declared with (or pointed at by function pointers that are declared with) these identifiers can be called by expressions that use the operator tokens and syntax, or the operator identifiers and ``function call'' syntax. 557 The relationships between operators and function calls are discussed in descriptions of the operators. 590 558 591 559 \begin{table}[hbt] … … 644 612 645 613 \begin{rationale} 646 Operator identifiers are made up of the characters of the operator token, with question marks added 647 to mark the positions of the arguments of operators. The question marks serve as mnemonic devices; 648 programmers can not create new operators by arbitrarily mixing question marks and other 649 nonalphabetic characters. Note that prefix and postfix versions of the increment and decrement 650 operators are distinguished by the position of the question mark. 651 \end{rationale} 652 653 \begin{rationale} 654 The use of ``\lstinline$?$'' in identifiers means that some C programs are not \CFA programs. For 655 instance, the sequence of characters ``\lstinline$(i < 0)?i:i$'' is legal in a C program, but a 656 \CFA compiler detects a syntax error because it treats ``\lstinline$?$'' as an identifier, not 657 as the two tokens ``\lstinline$?$'' and ``\lstinline$$''. 614 Operator identifiers are made up of the characters of the operator token, with question marks added to mark the positions of the arguments of operators. 615 The question marks serve as mnemonic devices; 616 programmers can not create new operators by arbitrarily mixing question marks and other nonalphabetic characters. 617 Note that prefix and postfix versions of the increment and decrement operators are distinguished by the position of the question mark. 618 \end{rationale} 619 620 \begin{rationale} 621 The use of ``\lstinline$?$'' in identifiers means that some C programs are not \CFA programs. For instance, the sequence of characters ``\lstinline$(i < 0)?i:i$'' is legal in a C program, but a 622 \CFA compiler detects a syntax error because it treats ``\lstinline$?$'' as an identifier, not as the two tokens ``\lstinline$?$'' and ``\lstinline$$''. 658 623 \end{rationale} 659 624 … … 663 628 \item 664 629 The logical operators ``\lstinline$&&$'' and ``\lstinline$$'', and the conditional operator 665 ``\lstinline$?:$''. These operators do not always evaluate their operands, and hence can not be 666 properly defined by functions unless some mechanism like callbyname is added to the language. 667 Note that the definitions of ``\lstinline$&&$'' and ``\lstinline$$'' say that they work by 668 checking that their arguments are unequal to 0, so defining ``\lstinline$!=$'' and ``\lstinline$0$'' 669 for userdefined types is enough to allow them to be used in logical expressions. 670 671 \item 672 The comma operator\index{comma expression}. It is a controlflow operator like those above. 630 ``\lstinline$?:$''. 631 These operators do not always evaluate their operands, and hence can not be properly defined by functions unless some mechanism like callbyname is added to the language. 632 Note that the definitions of ``\lstinline$&&$'' and ``\lstinline$$'' say that they work by checking that their arguments are unequal to 0, so defining ``\lstinline$!=$'' and ``\lstinline$0$'' for userdefined types is enough to allow them to be used in logical expressions. 633 634 \item 635 The comma operator\index{comma expression}. 636 It is a controlflow operator like those above. 673 637 Changing its meaning seems pointless and confusing. 674 638 675 639 \item 676 The ``address of'' operator. It would seem useful to define a unary ``\lstinline$&$'' operator that 677 returns values of some programmerdefined pointerlike type. The problem lies with the type of the 678 operator. Consider the expression ``\lstinline$p = &x$'', where \lstinline$x$ is of type 679 \lstinline$T$ and \lstinline$p$ has the programmerdefined type \lstinline$T_ptr$. The expression 680 might be treated as a call to the unary function ``\lstinline$&?$''. Now what is the type of the 681 function's parameter? It can not be \lstinline$T$, because then \lstinline$x$ would be passed by 682 value, and there is no way to create a useful pointerlike result from a value. Hence the parameter 683 must have type \lstinline$T *$. But then the expression must be rewritten as ``\lstinline$p = &?( &x )$'' 640 The ``address of'' operator. 641 It would seem useful to define a unary ``\lstinline$&$'' operator that returns values of some programmerdefined pointerlike type. 642 The problem lies with the type of the operator. 643 Consider the expression ``\lstinline$p = &x$'', where \lstinline$x$ is of type 644 \lstinline$T$ and \lstinline$p$ has the programmerdefined type \lstinline$T_ptr$. 645 The expression might be treated as a call to the unary function ``\lstinline$&?$''. 646 Now what is the type of the function's parameter? It can not be \lstinline$T$, because then \lstinline$x$ would be passed by value, and there is no way to create a useful pointerlike result from a value. 647 Hence the parameter must have type \lstinline$T *$. 648 But then the expression must be rewritten as ``\lstinline$p = &?( &x )$'' 684 649 which doesn't seem like progress! 685 650 686 The rule for addressof expressions would have to be something like ``keep applying addressof 687 functions until you get one that takes a pointer argument, then use the builtin operator and 688 stop''. It seems simpler to define a conversion function from \lstinline$T *$ to \lstinline$T_ptr$. 689 690 \item 691 The \lstinline$sizeof$ operator. It is already defined for every object type, and intimately tied 692 into the language's storage allocation model. Redefining it seems pointless. 693 694 \item 695 The ``member of'' operators ``\lstinline$.$'' and ``\lstinline$>$''. These are not really infix 696 operators, since their right ``operand'' is not a value or object. 697 698 \item 699 Cast operators\index{cast expression}. Anything that can be done with an explicit cast can be done 700 with a function call. The difference in syntax is small. 651 The rule for addressof expressions would have to be something like ``keep applying addressof functions until you get one that takes a pointer argument, then use the builtin operator and stop''. 652 It seems simpler to define a conversion function from \lstinline$T *$ to \lstinline$T_ptr$. 653 654 \item 655 The \lstinline$sizeof$ operator. 656 It is already defined for every object type, and intimately tied into the language's storage allocation model. 657 Redefining it seems pointless. 658 659 \item 660 The ``member of'' operators ``\lstinline$.$'' and ``\lstinline$>$''. 661 These are not really infix operators, since their right ``operand'' is not a value or object. 662 663 \item 664 Cast operators\index{cast expression}. 665 Anything that can be done with an explicit cast can be done with a function call. 666 The difference in syntax is small. 701 667 \end{itemize} 702 668 \end{rationale} … … 705 671 \section{Expressions} 706 672 707 \CFA allows operators and identifiers to be overloaded. Hence, each expression can have a number 708 of \define{interpretation}s, each of which has a different type. The interpretations that are 709 potentially executable are called \define{valid interpretation}s. The set of interpretations 710 depends on the kind of expression and on the interpretations of the subexpressions that it contains. 711 The rules for determining the valid interpretations of an expression are discussed below for each 712 kind of expression. Eventually the context of the outermost expression chooses one interpretation 713 of that expression. 714 715 An \define{ambiguous interpretation} is an interpretation which does not specify the exact object or 716 function denoted by every identifier in the expression. An expression can have some interpretations 717 that are ambiguous and others that are unambiguous. An expression that is chosen to be executed 718 shall not be ambiguous. 719 720 The \define{best valid interpretations} are the valid interpretations that use the fewest 721 unsafe\index{unsafe conversion} conversions. Of these, the best are those where the functions and 722 objects involved are the least polymorphic\index{less polymorphic}. Of these, the best have the 723 lowest total \Index{conversion cost}, including all implicit conversions in the argument 724 expressions. Of these, the best have the highest total conversion cost for the implicit conversions 725 (if any) applied to the argument expressions. If there is no single best valid interpretation, or if 726 the best valid interpretation is ambiguous, then the resulting interpretation is 727 ambiguous\index{ambiguous interpretation}. 728 729 \begin{rationale} 730 \CFA's rules for selecting the best interpretation are designed to allow overload resolution to 731 mimic C's operator semantics. In C, the ``usual arithmetic conversions'' are applied to the 732 operands of binary operators if necessary to convert the operands to types with a common real type. 733 In \CFA, those conversions are ``safe''. The ``fewest unsafe conversions'' rule ensures that the 734 usual conversions are done, if possible. The ``lowest total expression cost'' rule chooses the 735 proper common type. The oddlooking ``highest argument conversion cost'' rule ensures that, when 736 unary expressions must be converted, conversions of function results are preferred to conversion of 737 function arguments: \lstinline$(double)i$ will be preferred to \lstinline$(double)i$. 738 739 The ``least polymorphic'' rule reduces the number of polymorphic function calls, since such 740 functions are presumably more expensive than monomorphic functions and since the more specific 741 function is presumably more appropriate. It also gives preference to monomorphic values (such as the 673 \CFA allows operators and identifiers to be overloaded. 674 Hence, each expression can have a number of \define{interpretation}s, each of which has a different type. 675 The interpretations that are potentially executable are called \define{valid interpretation}s. 676 The set of interpretations depends on the kind of expression and on the interpretations of the subexpressions that it contains. 677 The rules for determining the valid interpretations of an expression are discussed below for each kind of expression. 678 Eventually the context of the outermost expression chooses one interpretation of that expression. 679 680 An \define{ambiguous interpretation} is an interpretation which does not specify the exact object or function denoted by every identifier in the expression. 681 An expression can have some interpretations that are ambiguous and others that are unambiguous. 682 An expression that is chosen to be executed shall not be ambiguous. 683 684 The \define{best valid interpretations} are the valid interpretations that use the fewest unsafe\index{unsafe conversion} conversions. 685 Of these, the best are those where the functions and objects involved are the least polymorphic\index{less polymorphic}. 686 Of these, the best have the lowest total \Index{conversion cost}, including all implicit conversions in the argument expressions. 687 Of these, the best have the highest total conversion cost for the implicit conversions 688 (if any) applied to the argument expressions. 689 If there is no single best valid interpretation, or if the best valid interpretation is ambiguous, then the resulting interpretation is ambiguous\index{ambiguous interpretation}. 690 691 \begin{rationale} 692 \CFA's rules for selecting the best interpretation are designed to allow overload resolution to mimic C's operator semantics. 693 In C, the ``usual arithmetic conversions'' are applied to the operands of binary operators if necessary to convert the operands to types with a common real type. 694 In \CFA, those conversions are ``safe''. 695 The ``fewest unsafe conversions'' rule ensures that the usual conversions are done, if possible. 696 The ``lowest total expression cost'' rule chooses the proper common type. 697 The oddlooking ``highest argument conversion cost'' rule ensures that, when unary expressions must be converted, conversions of function results are preferred to conversion of function arguments: \lstinline$(double)i$ will be preferred to \lstinline$(double)i$. 698 699 The ``least polymorphic'' rule reduces the number of polymorphic function calls, since such functions are presumably more expensive than monomorphic functions and since the more specific function is presumably more appropriate. 700 It also gives preference to monomorphic values (such as the 742 701 \lstinline$int$ \lstinline$0$) over polymorphic values (such as the \Index{null pointer} 743 \lstinline$0$\use{0}). However, interpretations that call polymorphic functions are preferred to 744 interpretations that perform unsafe conversions, because those conversions potentially lose accuracy 745 or violate strong typing. 702 \lstinline$0$\use{0}). 703 However, interpretations that call polymorphic functions are preferred to interpretations that perform unsafe conversions, because those conversions potentially lose accuracy or violate strong typing. 746 704 747 705 There are two notable differences between \CFA's overload resolution rules and the rules for 748 {\CC} defined in \cite{c++}. First, the result type of a function plays a role. In {\CC}, a 749 function call must be completely resolved based on the arguments to the call in most circumstances. 750 In \CFA, a function call may have several interpretations, each with a different result type, and 751 the interpretations of the containing context choose among them. Second, safe conversions are used 752 to choose among interpretations of all sorts of functions; in {\CC}, the ``usual arithmetic 753 conversions'' are a separate set of rules that apply only to the builtin operators. 754 \end{rationale} 755 756 Expressions involving certain operators\index{operator identifiers} are considered to be equivalent 757 to function calls. A transformation from ``operator'' syntax to ``function call'' syntax is defined 758 by \define{rewrite rules}. Each operator has a set of predefined functions that overload its 759 identifier. Overload resolution determines which member of the set is executed in a given 760 expression. The functions have \Index{internal linkage} and are implicitly declared with \Index{file 761 scope}. The predefined functions and rewrite rules are discussed below for each of these 762 operators. 763 \begin{rationale} 764 Predefined functions and constants have internal linkage because that simplifies optimization in 765 traditional compileandlink environments. For instance, ``\lstinline$an_int + an_int$'' is 766 equivalent to ``\lstinline$?+?(an_int, an_int)$''. If integer addition has not been redefined in 767 the current scope, a compiler can generate code to perform the addition directly. If predefined 768 functions had external linkage, this optimization would be difficult. 769 \end{rationale} 770 771 \begin{rationale} 772 Since each subsection describes the interpretations of an expression in terms of the interpretations 773 of its subexpressions, this chapter can be taken as describing an overload resolution algorithm that 774 uses one bottomup pass over an expression tree. Such an algorithm was first described (for Ada) by 775 Baker~\cite{Bak:overload}. It is extended here to handle polymorphic functions and arithmetic 776 conversions. The overload resolution rules and the predefined functions have been chosen so that, in 777 programs that do not introduce overloaded declarations, expressions will have the same meaning in C 778 and in \CFA. 779 \end{rationale} 780 781 \begin{rationale} 782 Expression syntax is quoted from the {\c11} standard. The syntax itself defines the precedence and 783 associativity of operators. The sections are arranged in decreasing order of precedence, with all 784 operators in a section having the same precedence. 706 {\CC} defined in \cite{c++}. 707 First, the result type of a function plays a role. 708 In {\CC}, a function call must be completely resolved based on the arguments to the call in most circumstances. 709 In \CFA, a function call may have several interpretations, each with a different result type, and the interpretations of the containing context choose among them. 710 Second, safe conversions are used to choose among interpretations of all sorts of functions; 711 in {\CC}, the ``usual arithmetic conversions'' are a separate set of rules that apply only to the builtin operators. 712 \end{rationale} 713 714 Expressions involving certain operators\index{operator identifiers} are considered to be equivalent to function calls. 715 A transformation from ``operator'' syntax to ``function call'' syntax is defined by \define{rewrite rules}. 716 Each operator has a set of predefined functions that overload its identifier. 717 Overload resolution determines which member of the set is executed in a given expression. 718 The functions have \Index{internal linkage} and are implicitly declared with \Index{file scope}. 719 The predefined functions and rewrite rules are discussed below for each of these operators. 720 \begin{rationale} 721 Predefined functions and constants have internal linkage because that simplifies optimization in traditional compileandlink environments. 722 For instance, ``\lstinline$an_int + an_int$'' is equivalent to ``\lstinline$?+?(an_int, an_int)$''. 723 If integer addition has not been redefined in the current scope, a compiler can generate code to perform the addition directly. 724 If predefined functions had external linkage, this optimization would be difficult. 725 \end{rationale} 726 727 \begin{rationale} 728 Since each subsection describes the interpretations of an expression in terms of the interpretations of its subexpressions, this chapter can be taken as describing an overload resolution algorithm that uses one bottomup pass over an expression tree. 729 Such an algorithm was first described (for Ada) by Baker~\cite{Bak:overload}. 730 It is extended here to handle polymorphic functions and arithmetic conversions. 731 The overload resolution rules and the predefined functions have been chosen so that, in programs that do not introduce overloaded declarations, expressions will have the same meaning in C and in \CFA. 732 \end{rationale} 733 734 \begin{rationale} 735 Expression syntax is quoted from the {\c11} standard. 736 The syntax itself defines the precedence and associativity of operators. 737 The sections are arranged in decreasing order of precedence, with all operators in a section having the same precedence. 785 738 \end{rationale} 786 739 … … 801 754 const int 1;@\use{1}@ 802 755 const int 0;@\use{0}@ 803 forall( dtype DT ) DT * const 0;804 forall( ftype FT ) FT * const 0;756 forall( dtype DT ) DT * const 0; 757 forall( ftype FT ) FT * const 0; 805 758 \end{lstlisting} 806 759 807 760 \semantics 808 The \Index{valid interpretation} of an \nonterm{identifier} are given by the visible\index{visible} 809 declarations of the identifier. 810 811 A \nonterm{constant} or \nonterm{stringliteral} has one valid interpretation, which has the type 812 and value defined by {\c11}. The predefined integer identifiers ``\lstinline$1$'' and 813 ``\lstinline$0$'' have the integer values 1 and 0, respectively. The other two predefined 814 ``\lstinline$0$'' identifiers are bound to polymorphic pointer values that, when 815 specialized\index{specialization} with a data type or function type respectively, produce a null 816 pointer of that type. 761 The \Index{valid interpretation} of an \nonterm{identifier} are given by the visible\index{visible} declarations of the identifier. 762 763 A \nonterm{constant} or \nonterm{stringliteral} has one valid interpretation, which has the type and value defined by {\c11}. 764 The predefined integer identifiers ``\lstinline$1$'' and ``\lstinline$0$'' have the integer values 1 and 0, respectively. 765 The other two predefined ``\lstinline$0$'' identifiers are bound to polymorphic pointer values that, when specialized\index{specialization} with a data type or function type respectively, produce a null pointer of that type. 817 766 818 767 A parenthesised expression has the same interpretations as the contained \nonterm{expression}. 819 768 820 769 \examples 821 The expression \lstinline$(void *)0$\use{0} specializes the (polymorphic) null pointer to a null 822 pointer to \lstinline$void$. \lstinline$(const void *)0$ does the same, and also uses a safe 823 conversion from \lstinline$void *$ to \lstinline$const void *$. In each case, the null pointer 824 conversion is better\index{best valid interpretations} than the unsafe conversion of the integer 770 The expression \lstinline$(void *)0$\use{0} specializes the (polymorphic) null pointer to a null pointer to \lstinline$void$. \lstinline$(const void *)0$ does the same, and also uses a safe conversion from \lstinline$void *$ to \lstinline$const void *$. 771 In each case, the null pointer conversion is better\index{best valid interpretations} than the unsafe conversion of the integer 825 772 \lstinline$0$ to a pointer. 826 773 … … 828 775 Note that the predefined identifiers have addresses. 829 776 830 \CFA does not have C's concept of ``null pointer constants'', which are not typed values but 831 special strings of tokens. The C token ``\lstinline$0$'' is an expression of type \lstinline$int$ 832 with the value ``zero'', and it \emph{also} is a null pointer constant. Similarly, 833 ``\lstinline$(void *)0$ is an expression of type \lstinline$(void *)$ whose value is a null pointer, 834 and it also is a null pointer constant. However, in C, ``\lstinline$(void *)(void *)0$'' is 835 \emph{not} a null pointer constant, even though it is nullvalued, a pointer, and constant! The 836 semantics of C expressions contain many special cases to deal with subexpressions that are null 837 pointer constants. 838 839 \CFA handles these cases through overload resolution. The declaration 840 \begin{lstlisting} 841 forall( dtype DT ) DT *const 0; 842 \end{lstlisting} 843 means that \lstinline$0$ is a polymorphic object, and contains a value that can have \emph{any} 844 pointertoobject type or pointertoincomplete type. The only such value is the null pointer. 845 Therefore the type \emph{alone} is enough to identify a null pointer. Where C defines an operator 846 with a special case for the null pointer constant, \CFA defines predefined functions with a 847 polymorphic object parameter. 777 \CFA does not have C's concept of ``null pointer constants'', which are not typed values but special strings of tokens. 778 The C token ``\lstinline$0$'' is an expression of type \lstinline$int$ with the value ``zero'', and it \emph{also} is a null pointer constant. 779 Similarly, 780 ``\lstinline$(void *)0$ is an expression of type \lstinline$(void *)$ whose value is a null pointer, and it also is a null pointer constant. 781 However, in C, ``\lstinline$(void *)(void *)0$'' is 782 \emph{not} a null pointer constant, even though it is nullvalued, a pointer, and constant! The semantics of C expressions contain many special cases to deal with subexpressions that are null pointer constants. 783 784 \CFA handles these cases through overload resolution. 785 The declaration 786 \begin{lstlisting} 787 forall( dtype DT ) DT * const 0; 788 \end{lstlisting} means that \lstinline$0$ is a polymorphic object, and contains a value that can have \emph{any} pointertoobject type or pointertoincomplete type. 789 The only such value is the null pointer. 790 Therefore the type \emph{alone} is enough to identify a null pointer. 791 Where C defines an operator with a special case for the null pointer constant, \CFA defines predefined functions with a polymorphic object parameter. 848 792 \end{rationale} 849 793 … … 851 795 \subsubsection{Generic selection} 852 796 853 \constraints The best interpretation of the controlling expression shall be 854 unambiguous\index{ambiguous interpretation}, and shall have type compatible with at most one of the 855 types named in its generic association list. If a generic selection has no \lstinline$default$ 856 generic association, the best interpretation of its controlling expression shall have type 857 compatible with exactly one of the types named in its generic association list. 797 \constraints The best interpretation of the controlling expression shall be unambiguous\index{ambiguous interpretation}, and shall have type compatible with at most one of the types named in its generic association list. 798 If a generic selection has no \lstinline$default$ generic association, the best interpretation of its controlling expression shall have type compatible with exactly one of the types named in its generic association list. 858 799 859 800 \semantics … … 883 824 \rewriterules 884 825 \begin{lstlisting} 885 a[b] @\rewrite@ ?[?]( b, a ) // if a has integer type */@\use{?[?]}@826 a[b] @\rewrite@ ?[?]( b, a ) // if a has integer type@\use{?[?]}@ 886 827 a[b] @\rewrite@ ?[?]( a, b ) // otherwise 887 a( ${\em arguments }$ ) @\rewrite@ ?()( a, ${\em arguments} )$@\use{?()}@828 a( @\emph{arguments}@ ) @\rewrite@ ?()( a, @\emph{arguments}@ )@\use{?()}@ 888 829 a++ @\rewrite@ ?++(&( a ))@\use{?++}@ 889 830 a @\rewrite@ ?(&( a ))@\use{?}@ … … 913 854 \end{lstlisting} 914 855 \semantics 915 The interpretations of subscript expressions are the interpretations of the corresponding function 916 call expressions. 856 The interpretations of subscript expressions are the interpretations of the corresponding function call expressions. 917 857 \begin{rationale} 918 858 C defines subscripting as pointer arithmetic in a way that makes \lstinline$a[i]$ and 919 \lstinline$i[a]$ equivalent. \CFA provides the equivalence through a rewrite rule to reduce the 920 number of overloadings of \lstinline$?[?]$. 921 922 Subscript expressions are rewritten as function calls that pass the first parameter by value. This 923 is somewhat unfortunate, since arraylike types tend to be large. The alternative is to use the 924 rewrite rule ``\lstinline$a[b]$ \rewrite \lstinline$?[?](&(a), b)$''. However, C semantics forbid 925 this approach: the \lstinline$a$ in ``\lstinline$a[b]$'' can be an arbitrary pointer value, which 926 does not have an address. 859 \lstinline$i[a]$ equivalent. \CFA provides the equivalence through a rewrite rule to reduce the number of overloadings of \lstinline$?[?]$. 860 861 Subscript expressions are rewritten as function calls that pass the first parameter by value. 862 This is somewhat unfortunate, since arraylike types tend to be large. 863 The alternative is to use the rewrite rule ``\lstinline$a[b]$ \rewrite \lstinline$?[?](&(a), b)$''. 864 However, C semantics forbid this approach: the \lstinline$a$ in ``\lstinline$a[b]$'' can be an arbitrary pointer value, which does not have an address. 927 865 928 866 The repetitive form of the predefined identifiers shows up a deficiency\index{deficiencies!pointers 929 to qualified types} of \CFA's type system. Type qualifiers are not included in type values, so 930 polymorphic functions that take pointers to arbitrary types often come in one flavor for each 931 possible qualification of the pointedat type. 867 to qualified types} of \CFA's type system. 868 Type qualifiers are not included in type values, so polymorphic functions that take pointers to arbitrary types often come in one flavor for each possible qualification of the pointedat type. 932 869 \end{rationale} 933 870 … … 936 873 937 874 \semantics 938 A \define{function designator} is an interpretation of an expression that has function type. The 939 \nonterm{postfixexpression} in a function call may have some interpretations that are function 940 designators and some that are not. 941 942 For those interpretations of the \nonterm{postfixexpression} that are not function designators, the 943 expression is rewritten and becomes a call of a function named ``\lstinline$?()$''. The valid 944 interpretations of the rewritten expression are determined in the manner described below. 945 946 Each combination of function designators and argument interpretations is considered. For those 947 interpretations of the \nonterm{postfixexpression} that are \Index{monomorphic function} 948 designators, the combination has a \Index{valid interpretation} if the function designator accepts 949 the number of arguments given, and each argument interpretation matches the corresponding explicit 950 parameter: 875 A \define{function designator} is an interpretation of an expression that has function type. 876 The 877 \nonterm{postfixexpression} in a function call may have some interpretations that are function designators and some that are not. 878 879 For those interpretations of the \nonterm{postfixexpression} that are not function designators, the expression is rewritten and becomes a call of a function named ``\lstinline$?()$''. 880 The valid interpretations of the rewritten expression are determined in the manner described below. 881 882 Each combination of function designators and argument interpretations is considered. 883 For those interpretations of the \nonterm{postfixexpression} that are \Index{monomorphic function} designators, the combination has a \Index{valid interpretation} if the function designator accepts the number of arguments given, and each argument interpretation matches the corresponding explicit parameter: 951 884 \begin{itemize} 952 \item 953 if the argument corresponds to a parameter in the function designator's prototype, the argument 954 interpretation must have the same type as the corresponding parameter, or be implicitly convertible 955 to the parameter's type 956 \item 957 if the function designator's type does not include a prototype or if the argument corresponds to 885 \item if the argument corresponds to a parameter in the function designator's prototype, the argument interpretation must have the same type as the corresponding parameter, or be implicitly convertible to the parameter's type 886 \item if the function designator's type does not include a prototype or if the argument corresponds to 958 887 ``\lstinline$...$'' in a prototype, a \Index{default argument promotion} is applied to it. 959 888 \end{itemize} … … 961 890 962 891 For those combinations where the interpretation of the \nonterm{postfixexpression} is a 963 \Index{polymorphic function} designator and the function designator accepts the number of arguments 964 given, there shall be at least one set of \define{implicit argument}s for the implicit parameters 965 such that 892 \Index{polymorphic function} designator and the function designator accepts the number of arguments given, there shall be at least one set of \define{implicit argument}s for the implicit parameters such that 966 893 \begin{itemize} 967 894 \item 968 If the declaration of the implicit parameter uses \Index{typeclass} \lstinline$type$\use{type}, the 969 implicit argument must be an object type; if it uses \lstinline$dtype$, the implicit argument must 970 be an object type or an incomplete type; and if it uses \lstinline$ftype$, the implicit argument 971 must be a function type. 972 973 \item 974 if an explicit parameter's type uses any implicit parameters, then the corresponding explicit 975 argument must have a type that is (or can be safely converted\index{safe conversion} to) the type 976 produced by substituting the implicit arguments for the implicit parameters in the explicit 977 parameter type. 978 979 \item 980 the remaining explicit arguments must match the remaining explicit parameters, as described for 981 monomorphic function designators. 982 983 \item 984 for each \Index{assertion parameter} in the function designator's type, there must be an object or 985 function with the same identifier that is visible at the call site and whose type is compatible with 986 or can be specialized to the type of the assertion declaration. 895 If the declaration of the implicit parameter uses \Index{typeclass} \lstinline$type$\use{type}, the implicit argument must be an object type; 896 if it uses \lstinline$dtype$, the implicit argument must be an object type or an incomplete type; 897 and if it uses \lstinline$ftype$, the implicit argument must be a function type. 898 899 \item if an explicit parameter's type uses any implicit parameters, then the corresponding explicit argument must have a type that is (or can be safely converted\index{safe conversion} to) the type produced by substituting the implicit arguments for the implicit parameters in the explicit parameter type. 900 901 \item the remaining explicit arguments must match the remaining explicit parameters, as described for monomorphic function designators. 902 903 \item for each \Index{assertion parameter} in the function designator's type, there must be an object or function with the same identifier that is visible at the call site and whose type is compatible with or can be specialized to the type of the assertion declaration. 987 904 \end{itemize} 988 There is a valid interpretation for each such set of implicit parameters. The type of each valid 989 interpretation is the return type of the function designator with implicit parameter values 990 substituted for the implicit arguments. 991 992 A valid interpretation is ambiguous\index{ambiguous interpretation} if the function designator or 993 any of the argument interpretations is ambiguous. 994 995 Every valid interpretation whose return type is not compatible with any other valid interpretation's 996 return type is an interpretation of the function call expression. 997 998 Every set of valid interpretations that have mutually compatible\index{compatible type} result types 999 also produces an interpretation of the function call expression. The type of the interpretation is 1000 the \Index{composite type} of the types of the valid interpretations, and the value of the 1001 interpretation is that of the \Index{best valid interpretation}. 1002 \begin{rationale} 1003 One desirable property of a polymorphic programming language is \define{generalizability}: the 1004 ability to replace an abstraction with a more general but equivalent abstraction without requiring 1005 changes in any of the uses of the original\cite{Cormack90}. For instance, it should be possible to 1006 replace a function ``\lstinline$int f( int );$'' with ``\lstinline$forall( type T ) T f( T );$'' 1007 without affecting any calls of \lstinline$f$. 905 There is a valid interpretation for each such set of implicit parameters. 906 The type of each valid interpretation is the return type of the function designator with implicit parameter values substituted for the implicit arguments. 907 908 A valid interpretation is ambiguous\index{ambiguous interpretation} if the function designator or any of the argument interpretations is ambiguous. 909 910 Every valid interpretation whose return type is not compatible with any other valid interpretation's return type is an interpretation of the function call expression. 911 912 Every set of valid interpretations that have mutually compatible\index{compatible type} result types also produces an interpretation of the function call expression. 913 The type of the interpretation is the \Index{composite type} of the types of the valid interpretations, and the value of the interpretation is that of the \Index{best valid interpretation}. 914 \begin{rationale} 915 One desirable property of a polymorphic programming language is \define{generalizability}: the ability to replace an abstraction with a more general but equivalent abstraction without requiring changes in any of the uses of the original\cite{Cormack90}. 916 For instance, it should be possible to replace a function ``\lstinline$int f( int );$'' with ``\lstinline$forall( type T ) T f( T );$'' without affecting any calls of \lstinline$f$. 1008 917 1009 918 \CFA\index{deficiencies!generalizability} does not fully possess this property, because … … 1015 924 float f; 1016 925 double d; 1017 f = g( f, f ); // (1) 1018 f = g( i, f ); // (2) (safe conversion to float) 1019 f = g( d, f ); // (3) (unsafe conversion to float) 1020 \end{lstlisting} 1021 If \lstinline$g$ was replaced by ``\lstinline$forall( type T ) T g( T, T );$'', the first and second 1022 calls would be unaffected, but the third would change: \lstinline$f$ would be converted to 926 f = g( f, f ); // (1) 927 f = g( i, f ); // (2) (safe conversion to float) 928 f = g( d, f ); // (3) (unsafe conversion to float) 929 \end{lstlisting} 930 If \lstinline$g$ was replaced by ``\lstinline$forall( type T ) T g( T, T );$'', the first and second calls would be unaffected, but the third would change: \lstinline$f$ would be converted to 1023 931 \lstinline$double$, and the result would be a \lstinline$double$. 1024 932 1025 Another example is the function ``\lstinline$void h( int *);$''. This function can be passed a1026 \lstinline$void *$ argument, but the generalization ``\lstinline$forall( type T ) void h( T *);$'' 1027 can not. In this case, \lstinline$void$ is not a valid value for \lstinline$T$ because it is not an 1028 object type. If unsafe conversions were allowed, \lstinline$T$ could be inferred to be \emph{any} 1029 object type, which is undesirable.933 Another example is the function ``\lstinline$void h( int *);$''. 934 This function can be passed a 935 \lstinline$void *$ argument, but the generalization ``\lstinline$forall( type T ) void h( T *);$'' can not. 936 In this case, \lstinline$void$ is not a valid value for \lstinline$T$ because it is not an object type. 937 If unsafe conversions were allowed, \lstinline$T$ could be inferred to be \emph{any} object type, which is undesirable. 1030 938 \end{rationale} 1031 939 … … 1045 953 For that interpretation, the function call is treated as ``\lstinline$?()( sin_dx, 12.9 )$''. 1046 954 \begin{lstlisting} 1047 int f( long ); // (1) 1048 int f( int, int ); // (2) 955 int f( long ); // (1) 956 int f( int, int ); // (2) 1049 957 int f( int *); // (3) 1050 1051 958 int i = f( 5 ); // calls (1) 1052 959 \end{lstlisting} 1053 Function (1) provides a valid interpretation of ``\lstinline$f( 5 )$'', using an implicit 1054 \lstinline$int$ to \lstinline$long$ conversion. The other functions do not, since the second 1055 requires two arguments, and since there is no implicit conversion from \lstinline$int$ to 1056 \lstinline$int *$ that could be used with the third function. 960 Function (1) provides a valid interpretation of ``\lstinline$f( 5 )$'', using an implicit \lstinline$int$ to \lstinline$long$ conversion. 961 The other functions do not, since the second requires two arguments, and since there is no implicit conversion from \lstinline$int$ to \lstinline$int *$ that could be used with the third function. 1057 962 1058 963 \begin{lstlisting} … … 1064 969 1065 970 \begin{lstlisting} 1066 forall( type T, type U ) void g( T, U ); // (4) 1067 forall( type T ) void g( T, T ); // (5) 1068 forall( type T ) void g( T, long ); // (6) 1069 void g( long, long ); // (7) 971 forall( type T, type U ) void g( T, U ); // (4) 972 forall( type T ) void g( T, T ); // (5) 973 forall( type T ) void g( T, long ); // (6) 974 void g( long, long ); // (7) 1070 975 double d; 1071 976 int i; 1072 977 int *p; 1073 1074 g( d, d ); // calls (5) 1075 g( d, i ); // calls (6) 1076 g( i, i ); // calls (7) 978 g( d, d ); // calls (5) 979 g( d, i ); // calls (6) 980 g( i, i ); // calls (7) 1077 981 g( i, p ); // calls (4) 1078 982 \end{lstlisting} 1079 The first call has valid interpretations for all four versions of \lstinline$g$. (6) and (7) are 1080 discarded because they involve unsafe \lstinline$double$to\lstinline$long$ conversions. (5) is 1081 chosen because it is less polymorphic than (4). 1082 1083 For the second call, (7) is again discarded. Of the remaining interpretations for (4), (5), and (6) 1084 (with \lstinline$i$ converted to \lstinline$long$), (6) is chosen because it is the least 1085 polymorphic. 1086 1087 The third call has valid interpretations for all of the functions; (7) is chosen since it is not 1088 polymorphic at all. 1089 1090 The fourth call has no interpretation for (5), because its arguments must have compatible type. (4) 1091 is chosen because it does not involve unsafe conversions. 983 The first call has valid interpretations for all four versions of \lstinline$g$. (6) and (7) are discarded because they involve unsafe \lstinline$double$to\lstinline$long$ conversions. (5) is chosen because it is less polymorphic than (4). 984 985 For the second call, (7) is again discarded. 986 Of the remaining interpretations for (4), (5), and (6) (with \lstinline$i$ converted to \lstinline$long$), (6) is chosen because it is the least polymorphic. 987 988 The third call has valid interpretations for all of the functions; 989 (7) is chosen since it is not polymorphic at all. 990 991 The fourth call has no interpretation for (5), because its arguments must have compatible type. (4) is chosen because it does not involve unsafe conversions. 1092 992 \begin{lstlisting} 1093 993 forall( type T ) T min( T, T ); … … 1098 998 } 1099 999 forall( type U  min_max( U ) ) void shuffle( U, U ); 1100 shuffle(9, 10); 1101 \end{lstlisting} 1102 The only possibility for \lstinline$U$ is \lstinline$double$, because that is the type used in the 1103 only visible \lstinline$max$ function. 9 and 10 must be converted to \lstinline$double$, and 1000 shuffle( 9, 10 ); 1001 \end{lstlisting} 1002 The only possibility for \lstinline$U$ is \lstinline$double$, because that is the type used in the only visible \lstinline$max$ function. 9 and 10 must be converted to \lstinline$double$, and 1104 1003 \lstinline$min$ must be specialized with \lstinline$T$ bound to \lstinline$double$. 1105 1004 \begin{lstlisting} 1106 extern void q( int ); // (8) 1107 extern void q( void * ); // (9) 1005 extern void q( int ); // (8) 1006 extern void q( void * ); // (9) 1108 1007 extern void r(); 1109 1008 q( 0 ); 1110 1009 r( 0 ); 1111 1010 \end{lstlisting} 1112 The \lstinline$int 0$ could be passed to (8), or the \lstinline$(void *)$ \Index{specialization} of 1113 the null pointer\index{null pointer} \lstinline$0$\use{0} could be passed to (9). The former is 1114 chosen because the \lstinline$int$ \lstinline$0$ is \Index{less polymorphic}. For 1115 the same reason, \lstinline$int$ \lstinline$0$ is passed to \lstinline$r()$, even though it has 1116 \emph{no} declared parameter types. 1011 The \lstinline$int 0$ could be passed to (8), or the \lstinline$(void *)$ \Index{specialization} of the null pointer\index{null pointer} \lstinline$0$\use{0} could be passed to (9). 1012 The former is chosen because the \lstinline$int$ \lstinline$0$ is \Index{less polymorphic}. 1013 For the same reason, \lstinline$int$ \lstinline$0$ is passed to \lstinline$r()$, even though it has \emph{no} declared parameter types. 1117 1014 1118 1015 1119 1016 \subsubsection{Structure and union members} 1120 1017 1121 \semantics In the member selection expression ``\lstinline$s$.\lstinline$m$'', there shall be at 1122 least one interpretation of \lstinline$s$ whose type is a structure type or union type containing a 1123 member named \lstinline$m$. If two or more interpretations of \lstinline$s$ have members named 1124 \lstinline$m$ with mutually compatible types, then the expression has an \Index{ambiguous 1125 interpretation} whose type is the composite type of the types of the members. If an interpretation 1126 of \lstinline$s$ has a member \lstinline$m$ whose type is not compatible with any other 1127 \lstinline$s$'s \lstinline$m$, then the expression has an interpretation with the member's type. The 1128 expression has no other interpretations. 1018 \semantics In the member selection expression ``\lstinline$s$.\lstinline$m$'', there shall be at least one interpretation of \lstinline$s$ whose type is a structure type or union type containing a member named \lstinline$m$. 1019 If two or more interpretations of \lstinline$s$ have members named 1020 \lstinline$m$ with mutually compatible types, then the expression has an \Index{ambiguous interpretation} whose type is the composite type of the types of the members. 1021 If an interpretation of \lstinline$s$ has a member \lstinline$m$ whose type is not compatible with any other 1022 \lstinline$s$'s \lstinline$m$, then the expression has an interpretation with the member's type. 1023 The expression has no other interpretations. 1129 1024 1130 1025 The expression ``\lstinline$p>m$'' has the same interpretations as the expression … … 1136 1031 \predefined 1137 1032 \begin{lstlisting} 1138 _Bool ?++( volatile _Bool * ), 1139 ?++( _Atomic volatile _Bool * ); 1140 char ?++( volatile char * ), 1141 ?++( _Atomic volatile char * ); 1142 signed char ?++( volatile signed char * ), 1143 ?++( _Atomic volatile signed char * ); 1144 unsigned char ?++( volatile signed char * ), 1145 ?++( _Atomic volatile signed char * ); 1146 short int ?++( volatile short int * ), 1147 ?++( _Atomic volatile short int * ); 1148 unsigned short int ?++( volatile unsigned short int * ), 1149 ?++( _Atomic volatile unsigned short int * ); 1150 int ?++( volatile int * ), 1151 ?++( _Atomic volatile int * ); 1152 unsigned int ?++( volatile unsigned int * ), 1153 ?++( _Atomic volatile unsigned int * ); 1154 long int ?++( volatile long int * ), 1155 ?++( _Atomic volatile long int * ); 1156 long unsigned int ?++( volatile long unsigned int * ), 1157 ?++( _Atomic volatile long unsigned int * ); 1158 long long int ?++( volatile long long int * ), 1159 ?++( _Atomic volatile long long int * ); 1160 long long unsigned ?++( volatile long long unsigned int * ), 1161 ?++( _Atomic volatile long long unsigned int * ); 1162 float ?++( volatile float * ), 1163 ?++( _Atomic volatile float * ); 1164 double ?++( volatile double * ), 1165 ?++( _Atomic volatile double * ); 1166 long double ?++( volatile long double * ), 1167 ?++( _Atomic volatile long double * ); 1168 1169 forall( type T ) T * ?++( T * restrict volatile * ), 1170 * ?++( T * _Atomic restrict volatile * ); 1171 1172 forall( type T ) _Atomic T * ?++( _Atomic T * restrict volatile * ), 1173 * ?++( _Atomic T * _Atomic restrict volatile * ); 1174 1175 forall( type T ) const T * ?++( const T * restrict volatile * ), 1176 * ?++( const T * _Atomic restrict volatile * ); 1177 1178 forall( type T ) volatile T * ?++( volatile T * restrict volatile * ), 1179 * ?++( volatile T * _Atomic restrict volatile * ); 1180 1181 forall( type T ) restrict T * ?++( restrict T * restrict volatile * ), 1182 * ?++( restrict T * _Atomic restrict volatile * ); 1183 1033 _Bool ?++( volatile _Bool * ), ?++( _Atomic volatile _Bool * ); 1034 char ?++( volatile char * ), ?++( _Atomic volatile char * ); 1035 signed char ?++( volatile signed char * ), ?++( _Atomic volatile signed char * ); 1036 unsigned char ?++( volatile signed char * ), ?++( _Atomic volatile signed char * ); 1037 short int ?++( volatile short int * ), ?++( _Atomic volatile short int * ); 1038 unsigned short int ?++( volatile unsigned short int * ), ?++( _Atomic volatile unsigned short int * ); 1039 int ?++( volatile int * ), ?++( _Atomic volatile int * ); 1040 unsigned int ?++( volatile unsigned int * ), ?++( _Atomic volatile unsigned int * ); 1041 long int ?++( volatile long int * ), ?++( _Atomic volatile long int * ); 1042 long unsigned int ?++( volatile long unsigned int * ), ?++( _Atomic volatile long unsigned int * ); 1043 long long int ?++( volatile long long int * ), ?++( _Atomic volatile long long int * ); 1044 long long unsigned ?++( volatile long long unsigned int * ), ?++( _Atomic volatile long long unsigned int * ); 1045 float ?++( volatile float * ), ?++( _Atomic volatile float * ); 1046 double ?++( volatile double * ), ?++( _Atomic volatile double * ); 1047 long double ?++( volatile long double * ), ?++( _Atomic volatile long double * ); 1048 1049 forall( type T ) T * ?++( T * restrict volatile * ), * ?++( T * _Atomic restrict volatile * ); 1050 forall( type T ) _Atomic T * ?++( _Atomic T * restrict volatile * ), * ?++( _Atomic T * _Atomic restrict volatile * ); 1051 forall( type T ) const T * ?++( const T * restrict volatile * ), * ?++( const T * _Atomic restrict volatile * ); 1052 forall( type T ) volatile T * ?++( volatile T * restrict volatile * ), * ?++( volatile T * _Atomic restrict volatile * ); 1053 forall( type T ) restrict T * ?++( restrict T * restrict volatile * ), * ?++( restrict T * _Atomic restrict volatile * ); 1184 1054 forall( type T ) _Atomic const T * ?++( _Atomic const T * restrict volatile * ), 1185 1055 * ?++( _Atomic const T * _Atomic restrict volatile * ); 1186 1187 1056 forall( type T ) _Atomic restrict T * ?++( _Atomic restrict T * restrict volatile * ), 1188 1057 * ?++( _Atomic restrict T * _Atomic restrict volatile * ); 1189 1190 1058 forall( type T ) _Atomic volatile T * ?++( _Atomic volatile T * restrict volatile * ), 1191 1059 * ?++( _Atomic volatile T * _Atomic restrict volatile * ); 1192 1193 1060 forall( type T ) const restrict T * ?++( const restrict T * restrict volatile * ), 1194 1061 * ?++( const restrict T * _Atomic restrict volatile * ); 1195 1196 1062 forall( type T ) const volatile T * ?++( const volatile T * restrict volatile * ), 1197 1063 * ?++( const volatile T * _Atomic restrict volatile * ); 1198 1199 1064 forall( type T ) restrict volatile T * ?++( restrict volatile T * restrict volatile * ), 1200 1065 * ?++( restrict volatile T * _Atomic restrict volatile * ); 1201 1202 1066 forall( type T ) _Atomic const restrict T * ?++( _Atomic const restrict T * restrict volatile * ), 1203 1067 * ?++( _Atomic const restrict T * _Atomic restrict volatile * ); 1204 1205 1068 forall( type T ) _Atomic const volatile T * ?++( _Atomic const volatile T * restrict volatile * ), 1206 1069 * ?++( _Atomic const volatile T * _Atomic restrict volatile * ); 1207 1208 1070 forall( type T ) _Atomic restrict volatile T * ?++( _Atomic restrict volatile T * restrict volatile * ), 1209 1071 * ?++( _Atomic restrict volatile T * _Atomic restrict volatile * ); 1210 1211 1072 forall( type T ) const restrict volatile T * ?++( const restrict volatile T * restrict volatile * ), 1212 1073 * ?++( const restrict volatile T * _Atomic restrict volatile * ); 1213 1214 1074 forall( type T ) _Atomic const restrict volatile T * ?++( _Atomic const restrict volatile T * restrict volatile * ), 1215 1075 * ?++( _Atomic const restrict volatile T * _Atomic restrict volatile * ); 1216 1076 1217 _Bool ?( volatile _Bool * ), 1218 ?( _Atomic volatile _Bool * ); 1219 char ?( volatile char * ), 1220 ?( _Atomic volatile char * ); 1221 signed char ?( volatile signed char * ), 1222 ?( _Atomic volatile signed char * ); 1223 unsigned char ?( volatile signed char * ), 1224 ?( _Atomic volatile signed char * ); 1225 short int ?( volatile short int * ), 1226 ?( _Atomic volatile short int * ); 1227 unsigned short int ?( volatile unsigned short int * ), 1228 ?( _Atomic volatile unsigned short int * ); 1229 int ?( volatile int * ), 1230 ?( _Atomic volatile int * ); 1231 unsigned int ?( volatile unsigned int * ), 1232 ?( _Atomic volatile unsigned int * ); 1233 long int ?( volatile long int * ), 1234 ?( _Atomic volatile long int * ); 1235 long unsigned int ?( volatile long unsigned int * ), 1236 ?( _Atomic volatile long unsigned int * ); 1237 long long int ?( volatile long long int * ), 1238 ?( _Atomic volatile long long int * ); 1239 long long unsigned ?( volatile long long unsigned int * ), 1240 ?( _Atomic volatile long long unsigned int * ); 1241 float ?( volatile float * ), 1242 ?( _Atomic volatile float * ); 1243 double ?( volatile double * ), 1244 ?( _Atomic volatile double * ); 1245 long double ?( volatile long double * ), 1246 ?( _Atomic volatile long double * ); 1247 1248 forall( type T ) T * ?( T * restrict volatile * ), 1249 * ?( T * _Atomic restrict volatile * ); 1250 1251 forall( type T ) _Atomic T * ?( _Atomic T * restrict volatile * ), 1252 * ?( _Atomic T * _Atomic restrict volatile * ); 1253 1254 forall( type T ) const T * ?( const T * restrict volatile * ), 1255 * ?( const T * _Atomic restrict volatile * ); 1256 1257 forall( type T ) volatile T * ?( volatile T * restrict volatile * ), 1258 * ?( volatile T * _Atomic restrict volatile * ); 1259 1260 forall( type T ) restrict T * ?( restrict T * restrict volatile * ), 1261 * ?( restrict T * _Atomic restrict volatile * ); 1262 1077 _Bool ?( volatile _Bool * ), ?( _Atomic volatile _Bool * ); 1078 char ?( volatile char * ), ?( _Atomic volatile char * ); 1079 signed char ?( volatile signed char * ), ?( _Atomic volatile signed char * ); 1080 unsigned char ?( volatile signed char * ), ?( _Atomic volatile signed char * ); 1081 short int ?( volatile short int * ), ?( _Atomic volatile short int * ); 1082 unsigned short int ?( volatile unsigned short int * ), ?( _Atomic volatile unsigned short int * ); 1083 int ?( volatile int * ), ?( _Atomic volatile int * ); 1084 unsigned int ?( volatile unsigned int * ), ?( _Atomic volatile unsigned int * ); 1085 long int ?( volatile long int * ), ?( _Atomic volatile long int * ); 1086 long unsigned int ?( volatile long unsigned int * ), ?( _Atomic volatile long unsigned int * ); 1087 long long int ?( volatile long long int * ), ?( _Atomic volatile long long int * ); 1088 long long unsigned ?( volatile long long unsigned int * ), ?( _Atomic volatile long long unsigned int * ); 1089 float ?( volatile float * ), ?( _Atomic volatile float * ); 1090 double ?( volatile double * ), ?( _Atomic volatile double * ); 1091 long double ?( volatile long double * ), ?( _Atomic volatile long double * ); 1092 1093 forall( type T ) T * ?( T * restrict volatile * ), * ?( T * _Atomic restrict volatile * ); 1094 forall( type T ) _Atomic T * ?( _Atomic T * restrict volatile * ), * ?( _Atomic T * _Atomic restrict volatile * ); 1095 forall( type T ) const T * ?( const T * restrict volatile * ), * ?( const T * _Atomic restrict volatile * ); 1096 forall( type T ) volatile T * ?( volatile T * restrict volatile * ), * ?( volatile T * _Atomic restrict volatile * ); 1097 forall( type T ) restrict T * ?( restrict T * restrict volatile * ), * ?( restrict T * _Atomic restrict volatile * ); 1263 1098 forall( type T ) _Atomic const T * ?( _Atomic const T * restrict volatile * ), 1264 1099 * ?( _Atomic const T * _Atomic restrict volatile * ); 1265 1266 1100 forall( type T ) _Atomic restrict T * ?( _Atomic restrict T * restrict volatile * ), 1267 1101 * ?( _Atomic restrict T * _Atomic restrict volatile * ); 1268 1269 1102 forall( type T ) _Atomic volatile T * ?( _Atomic volatile T * restrict volatile * ), 1270 1103 * ?( _Atomic volatile T * _Atomic restrict volatile * ); 1271 1272 1104 forall( type T ) const restrict T * ?( const restrict T * restrict volatile * ), 1273 1105 * ?( const restrict T * _Atomic restrict volatile * ); 1274 1275 1106 forall( type T ) const volatile T * ?( const volatile T * restrict volatile * ), 1276 1107 * ?( const volatile T * _Atomic restrict volatile * ); 1277 1278 1108 forall( type T ) restrict volatile T * ?( restrict volatile T * restrict volatile * ), 1279 1109 * ?( restrict volatile T * _Atomic restrict volatile * ); 1280 1281 1110 forall( type T ) _Atomic const restrict T * ?( _Atomic const restrict T * restrict volatile * ), 1282 1111 * ?( _Atomic const restrict T * _Atomic restrict volatile * ); 1283 1284 1112 forall( type T ) _Atomic const volatile T * ?( _Atomic const volatile T * restrict volatile * ), 1285 1113 * ?( _Atomic const volatile T * _Atomic restrict volatile * ); 1286 1287 1114 forall( type T ) _Atomic restrict volatile T * ?( _Atomic restrict volatile T * restrict volatile * ), 1288 1115 * ?( _Atomic restrict volatile T * _Atomic restrict volatile * ); 1289 1290 1116 forall( type T ) const restrict volatile T * ?( const restrict volatile T * restrict volatile * ), 1291 1117 * ?( const restrict volatile T * _Atomic restrict volatile * ); 1292 1293 1118 forall( type T ) _Atomic const restrict volatile T * ?( _Atomic const restrict volatile T * restrict volatile * ), 1294 1119 * ?( _Atomic const restrict volatile T * _Atomic restrict volatile * ); … … 1308 1133 1309 1134 \begin{rationale} 1310 Note that ``\lstinline$++$'' and ``\lstinline$$'' are rewritten as function calls that are given a 1311 pointer to that operand. (This is true of all operators that modify an operand.) As Hamish Macdonald 1312 has pointed out, this forces the modified operand of such expressions to be an lvalue. This 1313 partially enforces the C semantic rule that such operands must be \emph{modifiable} lvalues. 1314 \end{rationale} 1315 1316 \begin{rationale} 1317 In C, a semantic rule requires that pointer operands of increment and decrement be pointers to 1318 object types. Hence, \lstinline$void *$ objects cannot be incremented. In \CFA, the restriction 1319 follows from the use of a \lstinline$type$ parameter in the predefined function definitions, as 1320 opposed to \lstinline$dtype$, since only object types can be inferred arguments corresponding to the 1321 type parameter \lstinline$T$. 1135 Note that ``\lstinline$++$'' and ``\lstinline$$'' are rewritten as function calls that are given a pointer to that operand. (This is true of all operators that modify an operand.) As Hamish Macdonald has pointed out, this forces the modified operand of such expressions to be an lvalue. 1136 This partially enforces the C semantic rule that such operands must be \emph{modifiable} lvalues. 1137 \end{rationale} 1138 1139 \begin{rationale} 1140 In C, a semantic rule requires that pointer operands of increment and decrement be pointers to object types. 1141 Hence, \lstinline$void *$ objects cannot be incremented. 1142 In \CFA, the restriction follows from the use of a \lstinline$type$ parameter in the predefined function definitions, as opposed to \lstinline$dtype$, since only object types can be inferred arguments corresponding to the type parameter \lstinline$T$. 1322 1143 \end{rationale} 1323 1144 1324 1145 \semantics 1325 First, each interpretation of the operand of an increment or decrement expression is considered 1326 separately. For each interpretation that is a bitfield or is declared with the 1327 \lstinline$register$\index{register@{\lstinline$register$}} \index{Itorageclass specifier}, the 1328 expression has one valid interpretation, with the type of the operand, and the expression is 1329 ambiguous if the operand is. 1330 1331 For the remaining interpretations, the expression is rewritten, and the interpretations of the 1332 expression are the interpretations of the corresponding function call. Finally, all interpretations 1333 of the expression produced for the different interpretations of the operand are combined to produce 1334 the interpretations of the expression as a whole; where interpretations have compatible result 1335 types, the best interpretations are selected in the manner described for function call expressions. 1146 First, each interpretation of the operand of an increment or decrement expression is considered separately. 1147 For each interpretation that is a bitfield or is declared with the 1148 \lstinline$register$\index{register@{\lstinline$register$}} \index{Itorageclass specifier}, the expression has one valid interpretation, with the type of the operand, and the expression is ambiguous if the operand is. 1149 1150 For the remaining interpretations, the expression is rewritten, and the interpretations of the expression are the interpretations of the corresponding function call. 1151 Finally, all interpretations of the expression produced for the different interpretations of the operand are combined to produce the interpretations of the expression as a whole; where interpretations have compatible result types, the best interpretations are selected in the manner described for function call expressions. 1336 1152 1337 1153 \examples … … 1346 1162 \lstinline$vs++$ calls the \lstinline$?++$ function with the \lstinline$volatile short *$ parameter. 1347 1163 \lstinline$s++$ does the same, applying the safe conversion from \lstinline$short int *$ to 1348 \lstinline$volatile short int *$. Note that there is no conversion that adds an \lstinline$_Atomic$ 1349 qualifier, so the \lstinline$_Atomic volatile short int$ overloading does not provide a valid 1350 interpretation. 1164 \lstinline$volatile short int *$. 1165 Note that there is no conversion that adds an \lstinline$_Atomic$ qualifier, so the \lstinline$_Atomic volatile short int$ overloading does not provide a valid interpretation. 1351 1166 \end{sloppypar} 1352 1167 1353 There is no safe conversion from \lstinline$const short int *$ to \lstinline$volatile short int *$, 1354 and no \lstinline$?++$ function that accepts a \lstinline$const *$ parameter, so \lstinline$cs++$ 1355 has no valid interpretations. 1356 1357 The best valid interpretation of \lstinline$as++$ calls the \lstinline$short ?++$ function with the 1358 \lstinline$_Atomic volatile short int *$ parameter, applying a safe conversion to add the 1359 \lstinline$volatile$ qualifier. 1360 1361 \begin{lstlisting} 1362 char * const restrict volatile * restrict volatile pqpc; pqpc++ 1363 char * * restrict volatile ppc; ppc++; 1364 \end{lstlisting} 1365 Since \lstinline$&(pqpc)$ has type \lstinline$char * const restrict volatile * restrict volatile *$, 1366 the best valid interpretation of \lstinline$pqpc++$ calls the polymorphic \lstinline$?++$ function 1367 with the \lstinline$const restrict volatile T * restrict volatile *$ parameter, inferring 1368 \lstinline$T$ to be \lstinline$char *$. 1369 1370 \begin{sloppypar} 1371 \lstinline$ppc++$ calls the same function, again inferring \lstinline$T$ to be \lstinline$char *$, 1372 and using the safe conversions from \lstinline$T$ to \lstinline$T const restrict volatile$. 1373 \end{sloppypar} 1374 1375 \begin{rationale} 1376 Increment and decrement expressions show up a deficiency of \CFA's type system. There is no such 1377 thing as a pointer to a register object or bitfield\index{deficiencies!pointers to bitfields}. 1378 Therefore, there is no way to define a function that alters them, and hence no way to define 1379 increment and decrement functions for them. As a result, the semantics of increment and decrement 1380 expressions must treat them specially. This holds true for all of the operators that may modify 1381 such objects. 1382 \end{rationale} 1383 1384 \begin{rationale} 1385 The polymorphic overloadings for pointer increment and decrement can be understood by considering 1386 increasingly complex types. 1168 There is no safe conversion from \lstinline$const short int *$ to \lstinline$volatile short int *$, and no \lstinline$?++$ function that accepts a \lstinline$const *$ parameter, so \lstinline$cs++$ has no valid interpretations. 1169 1170 The best valid interpretation of \lstinline$as++$ calls the \lstinline$short ?++$ function with the \lstinline$_Atomic volatile short int *$ parameter, applying a safe conversion to add the \lstinline$volatile$ qualifier. 1171 \begin{lstlisting} 1172 char * const restrict volatile * restrict volatile pqpc; 1173 pqpc++ 1174 char * * restrict volatile ppc; 1175 ppc++; 1176 \end{lstlisting} 1177 Since \lstinline$&(pqpc)$ has type \lstinline$char * const restrict volatile * restrict volatile *$, the best valid interpretation of \lstinline$pqpc++$ calls the polymorphic \lstinline$?++$ function with the \lstinline$const restrict volatile T * restrict volatile *$ parameter, inferring \lstinline$T$ to be \lstinline$char *$. 1178 1179 \lstinline$ppc++$ calls the same function, again inferring \lstinline$T$ to be \lstinline$char *$, and using the safe conversions from \lstinline$T$ to \lstinline$T const$ \lstinline$restrict volatile$. 1180 1181 \begin{rationale} 1182 Increment and decrement expressions show up a deficiency of \CFA's type system. 1183 There is no such thing as a pointer to a register object or bitfield\index{deficiencies!pointers to bitfields}. 1184 Therefore, there is no way to define a function that alters them, and hence no way to define increment and decrement functions for them. 1185 As a result, the semantics of increment and decrement expressions must treat them specially. 1186 This holds true for all of the operators that may modify such objects. 1187 \end{rationale} 1188 1189 \begin{rationale} 1190 The polymorphic overloadings for pointer increment and decrement can be understood by considering increasingly complex types. 1387 1191 \begin{enumerate} 1388 1192 \item 1389 ``\lstinline$char * p; p++;$''. The argument to \lstinline$?++$ has type \lstinline$char * *$, and1390 the result has type \lstinline$char *$. The expression would be valid if \lstinline$?++$ were 1391 declared by1193 ``\lstinline$char * p; p++;$''. 1194 The argument to \lstinline$?++$ has type \lstinline$char * *$, and the result has type \lstinline$char *$. 1195 The expression would be valid if \lstinline$?++$ were declared by 1392 1196 \begin{lstlisting} 1393 1197 forall( type T ) T * ?++( T * * ); 1394 \end{lstlisting} 1395 with \lstinline$T$ inferred to be \lstinline$char$. 1396 1397 \item 1398 ``\lstinline$char *restrict volatile qp; qp++$''. The result again has type \lstinline$char *$, but 1399 the argument now has type \lstinline$char *restrict volatile *$, so it cannot be passed to the 1400 hypothetical function declared in point 1. Hence the actual predefined function is 1198 \end{lstlisting} with \lstinline$T$ inferred to be \lstinline$char$. 1199 1200 \item 1201 ``\lstinline$char *restrict volatile qp; qp++$''. 1202 The result again has type \lstinline$char *$, but the argument now has type \lstinline$char *restrict volatile *$, so it cannot be passed to the hypothetical function declared in point 1. 1203 Hence the actual predefined function is 1401 1204 \begin{lstlisting} 1402 1205 forall( type T ) T * ?++( T * restrict volatile * ); 1403 \end{lstlisting} 1404 which also accepts a \lstinline$char * *$ argument, because of the safe conversions that add 1405 \lstinline$volatile$ and \lstinline$restrict$ qualifiers. (The parameter is not constqualified, so 1406 constant pointers cannot be incremented.) 1407 1408 \item 1409 ``\lstinline$char *_Atomic ap; ap++$''. The result again has type \lstinline$char *$, but no safe 1410 conversion adds an \lstinline$_Atomic$ qualifier, so the function in point 2 is not applicable. A 1411 separate overloading of \lstinline$?++$ is required. 1412 1413 \item 1414 ``\lstinline$char const volatile * pq; pq++$''. Here the result has type 1206 \end{lstlisting} which also accepts a \lstinline$char * *$ argument, because of the safe conversions that add 1207 \lstinline$volatile$ and \lstinline$restrict$ qualifiers. (The parameter is not constqualified, so constant pointers cannot be incremented.) 1208 1209 \item 1210 ``\lstinline$char *_Atomic ap; ap++$''. 1211 The result again has type \lstinline$char *$, but no safe conversion adds an \lstinline$_Atomic$ qualifier, so the function in point 2 is not applicable. 1212 A separate overloading of \lstinline$?++$ is required. 1213 1214 \item 1215 ``\lstinline$char const volatile * pq; pq++$''. 1216 Here the result has type 1415 1217 \lstinline$char const volatile *$, so a new overloading is needed: 1416 1218 \begin{lstlisting} 1417 1219 forall( type T ) T const volatile * ?++( T const volatile *restrict volatile * ); 1418 1220 \end{lstlisting} 1419 One overloading is needed for each combination of qualifiers in the pointedat 1420 type\index{deficiencies!pointers to qualified types}. 1221 One overloading is needed for each combination of qualifiers in the pointedat type\index{deficiencies!pointers to qualified types}. 1421 1222 1422 1223 \item 1423 ``\lstinline$float *restrict * prp; prp++$''. The \lstinline$restrict$ qualifier is handled just1424 like \lstinline$const$ and \lstinline$volatile$ in the previous case:1224 ``\lstinline$float *restrict * prp; prp++$''. 1225 The \lstinline$restrict$ qualifier is handled just like \lstinline$const$ and \lstinline$volatile$ in the previous case: 1425 1226 \begin{lstlisting} 1426 1227 forall( type T ) T restrict * ?++( T restrict *restrict volatile * ); 1427 \end{lstlisting} 1428 with \lstinline$T$ inferred to be \lstinline$float *$. This looks odd, because {\c11} contains a 1429 constraint that requires restrictqualified types to be pointertoobject types, and \lstinline$T$ 1430 is not syntactically a pointer type. \CFA loosens the constraint. 1228 \end{lstlisting} with \lstinline$T$ inferred to be \lstinline$float *$. 1229 This looks odd, because {\c11} contains a constraint that requires restrictqualified types to be pointertoobject types, and \lstinline$T$ is not syntactically a pointer type. \CFA loosens the constraint. 1431 1230 \end{enumerate} 1432 1231 \end{rationale} … … 1436 1235 1437 1236 \semantics 1438 A compound literal has one interpretation, with the type given by the \nonterm{typename} of the 1439 compound literal. 1237 A compound literal has one interpretation, with the type given by the \nonterm{typename} of the compound literal. 1440 1238 1441 1239 … … 1455 1253 \rewriterules 1456 1254 \begin{lstlisting} 1457 *a @\rewrite@ *?( a) @\use{*?}@1458 +a @\rewrite@ +?( a) @\use{+?}@1459 a @\rewrite@ ?( a) @\use{?}@1460 ~a @\rewrite@ ~?( a) @\use{~?}@1461 !a @\rewrite@ !?( a) @\use{"!?}@1462 ++a @\rewrite@ ++?(&( a)) @\use{++?}@1463 a @\rewrite@ ?(&( a)) @\use{?}@1255 *a @\rewrite@ *?( a ) @\use{*?}@ 1256 +a @\rewrite@ +?( a ) @\use{+?}@ 1257 a @\rewrite@ ?( a ) @\use{?}@ 1258 ~a @\rewrite@ ~?( a ) @\use{~?}@ 1259 !a @\rewrite@ !?( a ) @\use{"!?}@ 1260 ++a @\rewrite@ ++?(&( a )) @\use{++?}@ 1261 a @\rewrite@ ?(&( a )) @\use{?}@ 1464 1262 \end{lstlisting} 1465 1263 … … 1469 1267 \predefined 1470 1268 \begin{lstlisting} 1471 _Bool ++?( volatile _Bool * ), 1472 ++?( _Atomic volatile _Bool * ); 1473 char ++?( volatile char * ), 1474 ++?( _Atomic volatile char * ); 1475 signed char ++?( volatile signed char * ), 1476 ++?( _Atomic volatile signed char * ); 1477 unsigned char ++?( volatile signed char * ), 1478 ++?( _Atomic volatile signed char * ); 1479 short int ++?( volatile short int * ), 1480 ++?( _Atomic volatile short int * ); 1481 unsigned short int ++?( volatile unsigned short int * ), 1482 ++?( _Atomic volatile unsigned short int * ); 1483 int ++?( volatile int * ), 1484 ++?( _Atomic volatile int * ); 1485 unsigned int ++?( volatile unsigned int * ), 1486 ++?( _Atomic volatile unsigned int * ); 1487 long int ++?( volatile long int * ), 1488 ++?( _Atomic volatile long int * ); 1489 long unsigned int ++?( volatile long unsigned int * ), 1490 ++?( _Atomic volatile long unsigned int * ); 1491 long long int ++?( volatile long long int * ), 1492 ++?( _Atomic volatile long long int * ); 1493 long long unsigned ++?( volatile long long unsigned int * ), 1494 ++?( _Atomic volatile long long unsigned int * ); 1495 float ++?( volatile float * ), 1496 ++?( _Atomic volatile float * ); 1497 double ++?( volatile double * ), 1498 ++?( _Atomic volatile double * ); 1499 long double ++?( volatile long double * ), 1500 ++?( _Atomic volatile long double * ); 1501 1502 forall( type T ) T * ++?( T * restrict volatile * ), 1503 * ++?( T * _Atomic restrict volatile * ); 1504 1505 forall( type T ) _Atomic T * ++?( _Atomic T * restrict volatile * ), 1506 * ++?( _Atomic T * _Atomic restrict volatile * ); 1507 1508 forall( type T ) const T * ++?( const T * restrict volatile * ), 1509 * ++?( const T * _Atomic restrict volatile * ); 1510 1511 forall( type T ) volatile T * ++?( volatile T * restrict volatile * ), 1512 * ++?( volatile T * _Atomic restrict volatile * ); 1513 1514 forall( type T ) restrict T * ++?( restrict T * restrict volatile * ), 1515 * ++?( restrict T * _Atomic restrict volatile * ); 1516 1269 _Bool ++?( volatile _Bool * ), ++?( _Atomic volatile _Bool * ); 1270 char ++?( volatile char * ), ++?( _Atomic volatile char * ); 1271 signed char ++?( volatile signed char * ), ++?( _Atomic volatile signed char * ); 1272 unsigned char ++?( volatile signed char * ), ++?( _Atomic volatile signed char * ); 1273 short int ++?( volatile short int * ), ++?( _Atomic volatile short int * ); 1274 unsigned short int ++?( volatile unsigned short int * ), ++?( _Atomic volatile unsigned short int * ); 1275 int ++?( volatile int * ), ++?( _Atomic volatile int * ); 1276 unsigned int ++?( volatile unsigned int * ), ++?( _Atomic volatile unsigned int * ); 1277 long int ++?( volatile long int * ), ++?( _Atomic volatile long int * ); 1278 long unsigned int ++?( volatile long unsigned int * ), ++?( _Atomic volatile long unsigned int * ); 1279 long long int ++?( volatile long long int * ), ++?( _Atomic volatile long long int * ); 1280 long long unsigned ++?( volatile long long unsigned int * ), ++?( _Atomic volatile long long unsigned int * ); 1281 float ++?( volatile float * ), ++?( _Atomic volatile float * ); 1282 double ++?( volatile double * ), ++?( _Atomic volatile double * ); 1283 long double ++?( volatile long double * ), ++?( _Atomic volatile long double * ); 1284 1285 forall( type T ) T * ++?( T * restrict volatile * ), * ++?( T * _Atomic restrict volatile * ); 1286 forall( type T ) _Atomic T * ++?( _Atomic T * restrict volatile * ), * ++?( _Atomic T * _Atomic restrict volatile * ); 1287 forall( type T ) const T * ++?( const T * restrict volatile * ), * ++?( const T * _Atomic restrict volatile * ); 1288 forall( type T ) volatile T * ++?( volatile T * restrict volatile * ), * ++?( volatile T * _Atomic restrict volatile * ); 1289 forall( type T ) restrict T * ++?( restrict T * restrict volatile * ), * ++?( restrict T * _Atomic restrict volatile * ); 1517 1290 forall( type T ) _Atomic const T * ++?( _Atomic const T * restrict volatile * ), 1518 1291 * ++?( _Atomic const T * _Atomic restrict volatile * ); 1519 1520 1292 forall( type T ) _Atomic volatile T * ++?( _Atomic volatile T * restrict volatile * ), 1521 1293 * ++?( _Atomic volatile T * _Atomic restrict volatile * ); 1522 1523 1294 forall( type T ) _Atomic restrict T * ++?( _Atomic restrict T * restrict volatile * ), 1524 1295 * ++?( _Atomic restrict T * _Atomic restrict volatile * ); 1525 1526 1296 forall( type T ) const volatile T * ++?( const volatile T * restrict volatile * ), 1527 1297 * ++?( const volatile T * _Atomic restrict volatile * ); 1528 1529 1298 forall( type T ) const restrict T * ++?( const restrict T * restrict volatile * ), 1530 1299 * ++?( const restrict T * _Atomic restrict volatile * ); 1531 1532 1300 forall( type T ) restrict volatile T * ++?( restrict volatile T * restrict volatile * ), 1533 1301 * ++?( restrict volatile T * _Atomic restrict volatile * ); 1534 1535 1302 forall( type T ) _Atomic const volatile T * ++?( _Atomic const volatile T * restrict volatile * ), 1536 1303 * ++?( _Atomic const volatile T * _Atomic restrict volatile * ); 1537 1538 1304 forall( type T ) _Atomic const restrict T * ++?( _Atomic const restrict T * restrict volatile * ), 1539 1305 * ++?( _Atomic const restrict T * _Atomic restrict volatile * ); 1540 1541 1306 forall( type T ) _Atomic restrict volatile T * ++?( _Atomic restrict volatile T * restrict volatile * ), 1542 1307 * ++?( _Atomic restrict volatile T * _Atomic restrict volatile * ); 1543 1544 1308 forall( type T ) const restrict volatile T * ++?( const restrict volatile T * restrict volatile * ), 1545 1309 * ++?( const restrict volatile T * _Atomic restrict volatile * ); 1546 1547 1310 forall( type T ) _Atomic const restrict volatile T * ++?( _Atomic const restrict volatile T * restrict volatile * ), 1548 1311 * ++?( _Atomic const restrict volatile T * _Atomic restrict volatile * ); 1549 1312 1550 _Bool ?( volatile _Bool * ), 1551 ?( _Atomic volatile _Bool * ); 1552 char ?( volatile char * ), 1553 ?( _Atomic volatile char * ); 1554 signed char ?( volatile signed char * ), 1555 ?( _Atomic volatile signed char * ); 1556 unsigned char ?( volatile signed char * ), 1557 ?( _Atomic volatile signed char * ); 1558 short int ?( volatile short int * ), 1559 ?( _Atomic volatile short int * ); 1560 unsigned short int ?( volatile unsigned short int * ), 1561 ?( _Atomic volatile unsigned short int * ); 1562 int ?( volatile int * ), 1563 ?( _Atomic volatile int * ); 1564 unsigned int ?( volatile unsigned int * ), 1565 ?( _Atomic volatile unsigned int * ); 1566 long int ?( volatile long int * ), 1567 ?( _Atomic volatile long int * ); 1568 long unsigned int ?( volatile long unsigned int * ), 1569 ?( _Atomic volatile long unsigned int * ); 1570 long long int ?( volatile long long int * ), 1571 ?( _Atomic volatile long long int * ); 1572 long long unsigned ?( volatile long long unsigned int * ), 1573 ?( _Atomic volatile long long unsigned int * ); 1574 float ?( volatile float * ), 1575 ?( _Atomic volatile float * ); 1576 double ?( volatile double * ), 1577 ?( _Atomic volatile double * ); 1578 long double ?( volatile long double * ), 1579 ?( _Atomic volatile long double * ); 1580 1581 forall( type T ) T * ?( T * restrict volatile * ), 1582 * ?( T * _Atomic restrict volatile * ); 1583 1584 forall( type T ) _Atomic T * ?( _Atomic T * restrict volatile * ), 1585 * ?( _Atomic T * _Atomic restrict volatile * ); 1586 1587 forall( type T ) const T * ?( const T * restrict volatile * ), 1588 * ?( const T * _Atomic restrict volatile * ); 1589 1590 forall( type T ) volatile T * ?( volatile T * restrict volatile * ), 1591 * ?( volatile T * _Atomic restrict volatile * ); 1592 1593 forall( type T ) restrict T * ?( restrict T * restrict volatile * ), 1594 * ?( restrict T * _Atomic restrict volatile * ); 1595 1313 _Bool ?( volatile _Bool * ), ?( _Atomic volatile _Bool * ); 1314 char ?( volatile char * ), ?( _Atomic volatile char * ); 1315 signed char ?( volatile signed char * ), ?( _Atomic volatile signed char * ); 1316 unsigned char ?( volatile signed char * ), ?( _Atomic volatile signed char * ); 1317 short int ?( volatile short int * ), ?( _Atomic volatile short int * ); 1318 unsigned short int ?( volatile unsigned short int * ), ?( _Atomic volatile unsigned short int * ); 1319 int ?( volatile int * ), ?( _Atomic volatile int * ); 1320 unsigned int ?( volatile unsigned int * ), ?( _Atomic volatile unsigned int * ); 1321 long int ?( volatile long int * ), ?( _Atomic volatile long int * ); 1322 long unsigned int ?( volatile long unsigned int * ), ?( _Atomic volatile long unsigned int * ); 1323 long long int ?( volatile long long int * ), ?( _Atomic volatile long long int * ); 1324 long long unsigned ?( volatile long long unsigned int * ), ?( _Atomic volatile long long unsigned int * ); 1325 float ?( volatile float * ), ?( _Atomic volatile float * ); 1326 double ?( volatile double * ), ?( _Atomic volatile double * ); 1327 long double ?( volatile long double * ), ?( _Atomic volatile long double * ); 1328 1329 forall( type T ) T * ?( T * restrict volatile * ), * ?( T * _Atomic restrict volatile * ); 1330 forall( type T ) _Atomic T * ?( _Atomic T * restrict volatile * ), * ?( _Atomic T * _Atomic restrict volatile * ); 1331 forall( type T ) const T * ?( const T * restrict volatile * ), * ?( const T * _Atomic restrict volatile * ); 1332 forall( type T ) volatile T * ?( volatile T * restrict volatile * ), * ?( volatile T * _Atomic restrict volatile * ); 1333 forall( type T ) restrict T * ?( restrict T * restrict volatile * ), * ?( restrict T * _Atomic restrict volatile * ); 1596 1334 forall( type T ) _Atomic const T * ?( _Atomic const T * restrict volatile * ), 1597 1335 * ?( _Atomic const T * _Atomic restrict volatile * ); 1598 1599 1336 forall( type T ) _Atomic volatile T * ?( _Atomic volatile T * restrict volatile * ), 1600 1337 * ?( _Atomic volatile T * _Atomic restrict volatile * ); 1601 1602 1338 forall( type T ) _Atomic restrict T * ?( _Atomic restrict T * restrict volatile * ), 1603 1339 * ?( _Atomic restrict T * _Atomic restrict volatile * ); 1604 1605 1340 forall( type T ) const volatile T * ?( const volatile T * restrict volatile * ), 1606 1341 * ?( const volatile T * _Atomic restrict volatile * ); 1607 1608 1342 forall( type T ) const restrict T * ?( const restrict T * restrict volatile * ), 1609 1343 * ?( const restrict T * _Atomic restrict volatile * ); 1610 1611 1344 forall( type T ) restrict volatile T * ?( restrict volatile T * restrict volatile * ), 1612 1345 * ?( restrict volatile T * _Atomic restrict volatile * ); 1613 1614 1346 forall( type T ) _Atomic const volatile T * ?( _Atomic const volatile T * restrict volatile * ), 1615 1347 * ?( _Atomic const volatile T * _Atomic restrict volatile * ); 1616 1617 1348 forall( type T ) _Atomic const restrict T * ?( _Atomic const restrict T * restrict volatile * ), 1618 1349 * ?( _Atomic const restrict T * _Atomic restrict volatile * ); 1619 1620 1350 forall( type T ) _Atomic restrict volatile T * ?( _Atomic restrict volatile T * restrict volatile * ), 1621 1351 * ?( _Atomic restrict volatile T * _Atomic restrict volatile * ); 1622 1623 1352 forall( type T ) const restrict volatile T * ?( const restrict volatile T * restrict volatile * ), 1624 1353 * ?( const restrict volatile T * _Atomic restrict volatile * ); 1625 1626 1354 forall( type T ) _Atomic const restrict volatile T * ?( _Atomic const restrict volatile T * restrict volatile * ), 1627 1355 * ?( _Atomic const restrict volatile T * _Atomic restrict volatile * ); … … 1645 1373 1646 1374 \semantics 1647 The interpretations of prefix increment and decrement expressions are 1648 determined in the same way as the interpretations of postfix increment and 1649 decrement expressions. 1375 The interpretations of prefix increment and decrement expressions are determined in the same way as the interpretations of postfix increment and decrement expressions. 1650 1376 1651 1377 … … 1670 1396 forall( type T ) const restrict volatile lvalue T *?( const restrict volatile T * ); 1671 1397 forall( type T ) _Atomic const restrict volatile lvalue T *?( _Atomic const restrict volatile T * ); 1672 1673 1398 forall( ftype FT ) FT *?( FT * ); 1674 1399 \end{lstlisting} … … 1682 1407 \lstinline$T$ is the type of the operand. 1683 1408 1684 The interpretations of an indirection expression are the interpretations of the corresponding 1685 function call. 1409 The interpretations of an indirection expression are the interpretations of the corresponding function call. 1686 1410 1687 1411 … … 1690 1414 \predefined 1691 1415 \begin{lstlisting} 1692 int 1693 +?( int ), 1694 ?( int ), 1695 ~?( int ); 1696 unsigned int 1697 +?( unsigned int ), 1698 ?( unsigned int ), 1699 ~?( unsigned int ); 1700 long int 1701 +?( long int ), 1702 ?( long int ), 1703 ~?( long int ); 1704 long unsigned int 1705 +?( long unsigned int ), 1706 ?( long unsigned int ), 1707 ~?( long unsigned int ); 1708 long long int 1709 +?( long long int ), 1710 ?( long long int ), 1711 ~?( long long int ); 1712 long long unsigned int 1713 +?( long long unsigned int ), 1714 ?( long long unsigned int ), 1715 ~?( long long unsigned int ); 1716 float 1717 +?( float ), 1718 ?( float ); 1719 double 1720 +?( double ), 1721 ?( double ); 1722 long double 1723 +?( long double ), 1724 ?( long double ); 1725 _Complex float 1726 +?( _Complex float ), 1727 ?( _Complex float ); 1728 _Complex double 1729 +?( _Complex double ), 1730 ?( _Complex double ); 1731 _Complex long double 1732 +?( _Complex long double ), 1733 ?( _Complex long double ); 1734 1735 int !?( int ), 1736 !?( unsigned int ), 1737 !?( long ), 1738 !?( long unsigned int ), 1739 !?( long long int ), 1740 !?( long long unsigned int ), 1741 !?( float ), 1742 !?( double ), 1743 !?( long double ), 1744 !?( _Complex float ), 1745 !?( _Complex double ), 1746 !?( _Complex long double ); 1747 1416 int +?( int ), ?( int ), ~?( int ); 1417 unsigned int +?( unsigned int ), ?( unsigned int ), ~?( unsigned int ); 1418 long int +?( long int ), ?( long int ), ~?( long int ); 1419 long unsigned int +?( long unsigned int ), ?( long unsigned int ), ~?( long unsigned int ); 1420 long long int +?( long long int ), ?( long long int ), ~?( long long int ); 1421 long long unsigned int +?( long long unsigned int ), ?( long long unsigned int ), ~?( long long unsigned int ); 1422 float +?( float ), ?( float ); 1423 double +?( double ), ?( double ); 1424 long double +?( long double ), ?( long double ); 1425 _Complex float +?( _Complex float ), ?( _Complex float ); 1426 _Complex double +?( _Complex double ), ?( _Complex double ); 1427 _Complex long double +?( _Complex long double ), ?( _Complex long double ); 1428 int !?( int ), !?( unsigned int ), !?( long ), !?( long unsigned int ), 1429 !?( long long int ), !?( long long unsigned int ), 1430 !?( float ), !?( double ), !?( long double ), 1431 !?( _Complex float ), !?( _Complex double ), !?( _Complex long double ); 1748 1432 forall( dtype DT ) int !?( const restrict volatile DT * ); 1749 1433 forall( dtype DT ) int !?( _Atomic const restrict volatile DT * ); 1750 1434 forall( ftype FT ) int !?( FT * ); 1751 1435 \end{lstlisting} 1752 For every extended integer type \lstinline$X$ with \Index{integer conversion rank} greater than the 1753 rank of \lstinline$int$ there exist 1436 For every extended integer type \lstinline$X$ with \Index{integer conversion rank} greater than the rank of \lstinline$int$ there exist 1754 1437 % Don't use predefined: keep this out of prelude.cf. 1755 1438 \begin{lstlisting} … … 1759 1442 1760 1443 \semantics 1761 The interpretations of a unary arithmetic expression are the interpretations of the corresponding 1762 function call. 1444 The interpretations of a unary arithmetic expression are the interpretations of the corresponding function call. 1763 1445 1764 1446 \examples … … 1766 1448 long int li; 1767 1449 void eat_double( double );@\use{eat_double}@ 1768 1769 eat_double(li ); // @\rewrite@ eat_double( ?( li ) ); 1450 eat_double(li ); // @\rewrite@ eat_double( ?( li ) ); 1770 1451 \end{lstlisting} 1771 1452 The valid interpretations of ``\lstinline$li$'' (assuming no extended integer types exist) are 1772 1453 \begin{center} 1773 \begin{tabular}{llc} 1774 interpretation & result type & expression conversion cost \\ 1454 \begin{tabular}{llc} interpretation & result type & expression conversion cost \\ 1775 1455 \hline 1776 1456 \lstinline$?( (int)li )$ & \lstinline$int$ & (unsafe) \\ … … 1788 1468 \end{tabular} 1789 1469 \end{center} 1790 The valid interpretations of the \lstinline$eat_double$ call, with the cost of the argument 1791 conversion and the cost of the entire expression, are 1470 The valid interpretations of the \lstinline$eat_double$ call, with the cost of the argument conversion and the cost of the entire expression, are 1792 1471 \begin{center} 1793 \begin{tabular}{lcc} 1794 interpretation & argument cost & expression cost \\ 1472 \begin{tabular}{lcc} interpretation & argument cost & expression cost \\ 1795 1473 \hline 1796 1474 \lstinline$eat_double( (double)?( (int)li) )$ & 7 & (unsafe) \\ … … 1808 1486 \end{tabular} 1809 1487 \end{center} 1810 Each has result type \lstinline$void$, so the best must be selected. The interpretations involving 1811 unsafe conversions are discarded. The remainder have equal expression conversion costs, so the 1488 Each has result type \lstinline$void$, so the best must be selected. 1489 The interpretations involving unsafe conversions are discarded. 1490 The remainder have equal expression conversion costs, so the 1812 1491 ``highest argument conversion cost'' rule is invoked, and the chosen interpretation is 1813 1492 \lstinline$eat_double( (double)?(li) )$. … … 1820 1499 \lstinline$dtype$, or \lstinline$ftype$. 1821 1500 1822 When the \lstinline$sizeof$\use{sizeof} operator is applied to an expression, the expression shall 1823 have exactly one \Index{interpretation}\index{ambiguous interpretation}, which shall 1824 be unambiguous. \semantics A \lstinline$sizeof$ or \lstinline$_Alignof$ expression has one 1825 interpretation, of type \lstinline$size_t$. 1501 When the \lstinline$sizeof$\use{sizeof} operator is applied to an expression, the expression shall have exactly one \Index{interpretation}\index{ambiguous interpretation}, which shall be unambiguous. \semantics A \lstinline$sizeof$ or \lstinline$_Alignof$ expression has one interpretation, of type \lstinline$size_t$. 1826 1502 1827 1503 When \lstinline$sizeof$ is applied to an identifier declared by a \nonterm{typedeclaration} or a 1828 \nonterm{typeparameter}, it yields the size in bytes of the type that implements the operand. When 1829 the operand is an opaque type or an inferred type parameter\index{inferred parameter}, the 1830 expression is not a constant expression. 1504 \nonterm{typeparameter}, it yields the size in bytes of the type that implements the operand. 1505 When the operand is an opaque type or an inferred type parameter\index{inferred parameter}, the expression is not a constant expression. 1831 1506 1832 1507 When \lstinline$_Alignof$ is applied to an identifier declared by a \nonterm{typedeclaration} or a 1833 \nonterm{typeparameter}, it yields the alignment requirement of the type that implements the 1834 operand. When the operand is an opaque type or an inferred type parameter\index{inferred 1835 parameter}, the expression is not a constant expression. 1508 \nonterm{typeparameter}, it yields the alignment requirement of the type that implements the operand. 1509 When the operand is an opaque type or an inferred type parameter\index{inferred parameter}, the expression is not a constant expression. 1836 1510 \begin{rationale} 1837 1511 \begin{lstlisting} 1838 1512 type Pair = struct { int first, second; }; 1839 1513 size_t p_size = sizeof(Pair); // constant expression 1840 1841 1514 extern type Rational;@\use{Rational}@ 1842 1515 size_t c_size = sizeof(Rational); // nonconstant expression 1843 1844 1516 forall(type T) T f(T p1, T p2) { 1845 1517 size_t t_size = sizeof(T); // nonconstant expression … … 1847 1519 } 1848 1520 \end{lstlisting} 1849 ``\lstinline$sizeof Rational$'', although not statically known, is fixed. Within \lstinline$f()$, 1521 ``\lstinline$sizeof Rational$'', although not statically known, is fixed. 1522 Within \lstinline$f()$, 1850 1523 ``\lstinline$sizeof(T)$'' is fixed for each call of \lstinline$f()$, but may vary from call to call. 1851 1524 \end{rationale} … … 1867 1540 1868 1541 In a \Index{cast expression} ``\lstinline$($\nonterm{typename}\lstinline$)e$'', if 1869 \nonterm{typename} is the type of an interpretation of \lstinline$e$, then that interpretation is 1870 the only interpretation of the cast expression; otherwise, \lstinline$e$ shall have some 1871 interpretation that can be converted to \nonterm{typename}, and the interpretation of the cast 1872 expression is the cast of the interpretation that can be converted at the lowest cost. The cast 1873 expression's interpretation is ambiguous\index{ambiguous interpretation} if more than one 1874 interpretation can be converted at the lowest cost or if the selected interpretation is ambiguous. 1875 1876 \begin{rationale} 1877 Casts can be used to eliminate ambiguity in expressions by selecting interpretations of 1878 subexpressions, and to specialize polymorphic functions and values. 1542 \nonterm{typename} is the type of an interpretation of \lstinline$e$, then that interpretation is the only interpretation of the cast expression; 1543 otherwise, \lstinline$e$ shall have some interpretation that can be converted to \nonterm{typename}, and the interpretation of the cast expression is the cast of the interpretation that can be converted at the lowest cost. 1544 The cast expression's interpretation is ambiguous\index{ambiguous interpretation} if more than one interpretation can be converted at the lowest cost or if the selected interpretation is ambiguous. 1545 1546 \begin{rationale} 1547 Casts can be used to eliminate ambiguity in expressions by selecting interpretations of subexpressions, and to specialize polymorphic functions and values. 1879 1548 \end{rationale} 1880 1549 … … 1899 1568 \predefined 1900 1569 \begin{lstlisting} 1901 int?*?( int, int ), 1902 ?/?( int, int ), 1903 ?%?( int, int ); 1904 unsigned int?*?( unsigned int, unsigned int ), 1905 ?/?( unsigned int, unsigned int ), 1906 ?%?( unsigned int, unsigned int ); 1907 long int?*?( long int, long int ), 1908 ?/?( long, long ), 1909 ?%?( long, long ); 1570 int?*?( int, int ), ?/?( int, int ), ?%?( int, int ); 1571 unsigned int?*?( unsigned int, unsigned int ), ?/?( unsigned int, unsigned int ), ?%?( unsigned int, unsigned int ); 1572 long int?*?( long int, long int ), ?/?( long, long ), ?%?( long, long ); 1910 1573 long unsigned int?*?( long unsigned int, long unsigned int ), 1911 ?/?( long unsigned int, long unsigned int ), 1912 ?%?( long unsigned int, long unsigned int ); 1913 long long int?*?( long long int, long long int ), 1914 ?/?( long long int, long long int ), 1574 ?/?( long unsigned int, long unsigned int ), ?%?( long unsigned int, long unsigned int ); 1575 long long int?*?( long long int, long long int ), ?/?( long long int, long long int ), 1915 1576 ?%?( long long int, long long int ); 1916 1577 long long unsigned int ?*?( long long unsigned int, long long unsigned int ), 1917 ?/?( long long unsigned int, long long unsigned int ), 1918 ?%?( long long unsigned int, long long unsigned int ); 1919 float?*?( float, float ), 1920 ?/?( float, float ); 1921 double?*?( double, double ), 1922 ?/?( double, double ); 1923 long double?*?( long double, long double ), 1924 ?/?( long double, long double ); 1925 _Complex float?*?( float, _Complex float ), 1926 ?/?( float, _Complex float ), 1927 ?*?( _Complex float, float ), 1928 ?/?( _Complex float, float ), 1929 ?*?( _Complex float, _Complex float ), 1930 ?/?( _Complex float, _Complex float ); 1931 _Complex double?*?( double, _Complex double ), 1932 ?/?( double, _Complex double ), 1933 ?*?( _Complex double, double ), 1934 ?/?( _Complex double, double ), 1935 ?*?( _Complex double, _Complex double ), 1936 ?/?( _Complex double, _Complex double ); 1937 _Complex long double?*?( long double, _Complex long double ), 1938 ?/?( long double, _Complex long double ), 1939 ?*?( _Complex long double, long double ), 1940 ?/?( _Complex long double, long double ), 1941 ?*?( _Complex long double, _Complex long double ), 1942 ?/?( _Complex long double, _Complex long double ); 1943 \end{lstlisting} 1944 For every extended integer type \lstinline$X$ with \Index{integer conversion rank} greater than the 1945 rank of \lstinline$int$ there exist 1578 ?/?( long long unsigned int, long long unsigned int ), ?%?( long long unsigned int, long long unsigned int ); 1579 float?*?( float, float ), ?/?( float, float ); 1580 double?*?( double, double ), ?/?( double, double ); 1581 long double?*?( long double, long double ), ?/?( long double, long double ); 1582 _Complex float?*?( float, _Complex float ), ?/?( float, _Complex float ), 1583 ?*?( _Complex float, float ), ?/?( _Complex float, float ), 1584 ?*?( _Complex float, _Complex float ), ?/?( _Complex float, _Complex float ); 1585 _Complex double?*?( double, _Complex double ), ?/?( double, _Complex double ), 1586 ?*?( _Complex double, double ), ?/?( _Complex double, double ), 1587 ?*?( _Complex double, _Complex double ), ?/?( _Complex double, _Complex double ); 1588 _Complex long double?*?( long double, _Complex long double ), ?/?( long double, _Complex long double ), 1589 ?*?( _Complex long double, long double ), ?/?( _Complex long double, long double ), 1590 ?*?( _Complex long double, _Complex long double ), ?/?( _Complex long double, _Complex long double ); 1591 \end{lstlisting} 1592 For every extended integer type \lstinline$X$ with \Index{integer conversion rank} greater than the rank of \lstinline$int$ there exist 1946 1593 % Don't use predefined: keep this out of prelude.cf. 1947 1594 \begin{lstlisting} … … 1951 1598 \begin{rationale} 1952 1599 {\c11} does not include conversions from the \Index{real type}s to \Index{complex type}s in the 1953 \Index{usual arithmetic conversion}s. Instead it specifies conversion of the result of binary 1954 operations on arguments from mixed type domains. \CFA's predefined operators match that pattern. 1600 \Index{usual arithmetic conversion}s. Instead it specifies conversion of the result of binary operations on arguments from mixed type domains. \CFA's predefined operators match that pattern. 1955 1601 \end{rationale} 1956 1602 1957 1603 \semantics 1958 The interpretations of multiplicative expressions are the interpretations of the corresponding 1959 function call. 1604 The interpretations of multiplicative expressions are the interpretations of the corresponding function call. 1960 1605 1961 1606 \examples … … 1966 1611 eat_double( li % i ); 1967 1612 \end{lstlisting} 1968 ``\lstinline$li % i$'' is rewritten as ``\lstinline$?%?(li, i )$''. The valid interpretations 1969 of \lstinline$?%?(li, i )$, the cost\index{conversion cost} of converting their arguments, and 1970 the cost of converting the result to \lstinline$double$ (assuming no extended integer types are 1971 present ) are 1613 ``\lstinline$li % i$'' is rewritten as ``\lstinline$?%?(li, i )$''. 1614 The valid interpretations of \lstinline$?%?(li, i )$, the cost\index{conversion cost} of converting their arguments, and the cost of converting the result to \lstinline$double$ (assuming no extended integer types are present ) are 1972 1615 \begin{center} 1973 \begin{tabular}{lcc} 1974 interpretation & argument cost & result cost \\ 1616 \begin{tabular}{lcc} interpretation & argument cost & result cost \\ 1975 1617 \hline 1976 1618 \lstinline$ ?%?( (int)li, i )$ & (unsafe) & 6 \\ 1977 1619 \lstinline$ ?%?( (unsigned)li,(unsigned)i )$ & (unsafe) & 5 \\ 1978 \lstinline$ ?%?( li,(long)i )$ & 1 & 4 \\1620 \lstinline$ ?%?( li, (long)i )$ & 1 & 4 \\ 1979 1621 \lstinline$ ?%?( (long unsigned)li,(long unsigned)i )$ & 3 & 3 \\ 1980 1622 \lstinline$ ?%?( (long long)li,(long long)i )$ & 5 & 2 \\ … … 1983 1625 \end{center} 1984 1626 The best interpretation of \lstinline$eat_double( li, i )$ is 1985 \lstinline$eat_double( (double)?%?(li, (long)i ))$, which has no unsafe conversions and the 1986 lowest total cost. 1987 1988 \begin{rationale} 1989 {\c11} defines most arithmetic operations to apply an \Index{integer promotion} to any argument that 1990 belongs to a type that has an \Index{integer conversion rank} less than that of \lstinline$int$.If 1627 \lstinline$eat_double( (double)?%?(li, (long)i ))$, which has no unsafe conversions and the lowest total cost. 1628 1629 \begin{rationale} 1630 {\c11} defines most arithmetic operations to apply an \Index{integer promotion} to any argument that belongs to a type that has an \Index{integer conversion rank} less than that of \lstinline$int$.If 1991 1631 \lstinline$s$ is a \lstinline$short int$, ``\lstinline$s *s$'' does not have type \lstinline$short int$; 1992 it is treated as ``\lstinline$( (int)s ) * ( (int)s )$'', and has type \lstinline$int$. \CFA matches 1993 that pattern; it does not predefine ``\lstinline$short ?*?( short, short )$''. 1994 1995 These ``missing'' operators limit polymorphism. Consider 1632 it is treated as ``\lstinline$( (int)s ) * ( (int)s )$'', and has type \lstinline$int$. \CFA matches that pattern; 1633 it does not predefine ``\lstinline$short ?*?( short, short )$''. 1634 1635 These ``missing'' operators limit polymorphism. 1636 Consider 1996 1637 \begin{lstlisting} 1997 1638 forall( type T  T ?*?( T, T ) ) T square( T ); … … 2001 1642 Since \CFA does not define a multiplication operator for \lstinline$short int$, 2002 1643 \lstinline$square( s )$ is treated as \lstinline$square( (int)s )$, and the result has type 2003 \lstinline$int$. This is mildly surprising, but it follows the {\c11} operator pattern. 1644 \lstinline$int$. 1645 This is mildly surprising, but it follows the {\c11} operator pattern. 2004 1646 2005 1647 A more troubling example is … … 2010 1652 \end{lstlisting} 2011 1653 This has no valid interpretations, because \CFA has no conversion from ``array of 2012 \lstinline$short int$'' to ``array of \lstinline$int$''. The alternatives in such situations2013 include1654 \lstinline$short int$'' to ``array of \lstinline$int$''. 1655 The alternatives in such situations include 2014 1656 \begin{itemize} 2015 1657 \item … … 2020 1662 \lstinline$product$. 2021 1663 \item 2022 Defining \lstinline$product$ to take as an argument a conversion function from the ``small'' type to 2023 the operator's argument type. 1664 Defining \lstinline$product$ to take as an argument a conversion function from the ``small'' type to the operator's argument type. 2024 1665 \end{itemize} 2025 1666 \end{rationale} … … 2043 1684 \predefined 2044 1685 \begin{lstlisting} 2045 int?+?( int, int ), 2046 ??( int, int ); 2047 unsigned int?+?( unsigned int, unsigned int ), 2048 ??( unsigned int, unsigned int ); 2049 long int?+?( long int, long int ), 2050 ??( long int, long int ); 2051 long unsigned int?+?( long unsigned int, long unsigned int ), 2052 ??( long unsigned int, long unsigned int ); 2053 long long int?+?( long long int, long long int ), 2054 ??( long long int, long long int ); 1686 int?+?( int, int ), ??( int, int ); 1687 unsigned int?+?( unsigned int, unsigned int ), ??( unsigned int, unsigned int ); 1688 long int?+?( long int, long int ), ??( long int, long int ); 1689 long unsigned int?+?( long unsigned int, long unsigned int ), ??( long unsigned int, long unsigned int ); 1690 long long int?+?( long long int, long long int ), ??( long long int, long long int ); 2055 1691 long long unsigned int ?+?( long long unsigned int, long long unsigned int ), 2056 1692 ??( long long unsigned int, long long unsigned int ); 2057 float?+?( float, float ), 2058 ??( float, float ); 2059 double?+?( double, double ), 2060 ??( double, double ); 2061 long double?+?( long double, long double ), 2062 ??( long double, long double ); 2063 _Complex float?+?( _Complex float, float ), 2064 ??( _Complex float, float ), 2065 ?+?( float, _Complex float ), 2066 ??( float, _Complex float ), 2067 ?+?( _Complex float, _Complex float ), 2068 ??( _Complex float, _Complex float ); 2069 _Complex double?+?( _Complex double, double ), 2070 ??( _Complex double, double ), 2071 ?+?( double, _Complex double ), 2072 ??( double, _Complex double ), 2073 ?+?( _Complex double, _Complex double ), 2074 ??( _Complex double, _Complex double ); 2075 _Complex long double?+?( _Complex long double, long double ), 2076 ??( _Complex long double, long double ), 2077 ?+?( long double, _Complex long double ), 2078 ??( long double, _Complex long double ), 2079 ?+?( _Complex long double, _Complex long double ), 2080 ??( _Complex long double, _Complex long double ); 2081 2082 forall( type T ) T 2083 * ?+?( T *, ptrdiff_t ), 2084 * ?+?( ptrdiff_t, T * ), 2085 * ??( T *, ptrdiff_t ); 2086 2087 forall( type T ) _Atomic T 2088 * ?+?( _Atomic T *, ptrdiff_t ), 2089 * ?+?( ptrdiff_t, _Atomic T * ), 1693 float?+?( float, float ), ??( float, float ); 1694 double?+?( double, double ), ??( double, double ); 1695 long double?+?( long double, long double ), ??( long double, long double ); 1696 _Complex float?+?( _Complex float, float ), ??( _Complex float, float ), 1697 ?+?( float, _Complex float ), ??( float, _Complex float ), 1698 ?+?( _Complex float, _Complex float ), ??( _Complex float, _Complex float ); 1699 _Complex double?+?( _Complex double, double ), ??( _Complex double, double ), 1700 ?+?( double, _Complex double ), ??( double, _Complex double ), 1701 ?+?( _Complex double, _Complex double ), ??( _Complex double, _Complex double ); 1702 _Complex long double?+?( _Complex long double, long double ), ??( _Complex long double, long double ), 1703 ?+?( long double, _Complex long double ), ??( long double, _Complex long double ), 1704 ?+?( _Complex long double, _Complex long double ), ??( _Complex long double, _Complex long double ); 1705 1706 forall( type T ) T * ?+?( T *, ptrdiff_t ), * ?+?( ptrdiff_t, T * ), * ??( T *, ptrdiff_t ); 1707 forall( type T ) _Atomic T * ?+?( _Atomic T *, ptrdiff_t ), * ?+?( ptrdiff_t, _Atomic T * ), 2090 1708 * ??( _Atomic T *, ptrdiff_t ); 2091 2092 forall( type T ) const T 2093 * ?+?( const T *, ptrdiff_t ), 2094 * ?+?( ptrdiff_t, const T * ), 1709 forall( type T ) const T * ?+?( const T *, ptrdiff_t ), * ?+?( ptrdiff_t, const T * ), 2095 1710 * ??( const T *, ptrdiff_t ); 2096 2097 forall( type T ) restrict T 2098 * ?+?( restrict T *, ptrdiff_t ), 2099 * ?+?( ptrdiff_t, restrict T * ), 1711 forall( type T ) restrict T * ?+?( restrict T *, ptrdiff_t ), * ?+?( ptrdiff_t, restrict T * ), 2100 1712 * ??( restrict T *, ptrdiff_t ); 2101 2102 forall( type T ) volatile T 2103 * ?+?( volatile T *, ptrdiff_t ), 2104 * ?+?( ptrdiff_t, volatile T * ), 1713 forall( type T ) volatile T * ?+?( volatile T *, ptrdiff_t ), * ?+?( ptrdiff_t, volatile T * ), 2105 1714 * ??( volatile T *, ptrdiff_t ); 2106 2107 forall( type T ) _Atomic const T 2108 * ?+?( _Atomic const T *, ptrdiff_t ), 2109 * ?+?( ptrdiff_t, _Atomic const T * ), 1715 forall( type T ) _Atomic const T * ?+?( _Atomic const T *, ptrdiff_t ), * ?+?( ptrdiff_t, _Atomic const T * ), 2110 1716 * ??( _Atomic const T *, ptrdiff_t ); 2111 2112 forall( type T ) _Atomic restrict T 2113 * ?+?( _Atomic restrict T *, ptrdiff_t ), 2114 * ?+?( ptrdiff_t, _Atomic restrict T * ), 1717 forall( type T ) _Atomic restrict T * ?+?( _Atomic restrict T *, ptrdiff_t ), * ?+?( ptrdiff_t, _Atomic restrict T * ), 2115 1718 * ??( _Atomic restrict T *, ptrdiff_t ); 2116 2117 forall( type T ) _Atomic volatile T 2118 * ?+?( _Atomic volatile T *, ptrdiff_t ), 2119 * ?+?( ptrdiff_t, _Atomic volatile T * ), 1719 forall( type T ) _Atomic volatile T * ?+?( _Atomic volatile T *, ptrdiff_t ), * ?+?( ptrdiff_t, _Atomic volatile T * ), 2120 1720 * ??( _Atomic volatile T *, ptrdiff_t ); 2121 2122 forall( type T ) const restrict T 2123 * ?+?( const restrict T *, ptrdiff_t ), 2124 * ?+?( ptrdiff_t, const restrict T * ), 1721 forall( type T ) const restrict T * ?+?( const restrict T *, ptrdiff_t ), * ?+?( ptrdiff_t, const restrict T * ), 2125 1722 * ??( const restrict T *, ptrdiff_t ); 2126 2127 forall( type T ) const volatile T 2128 * ?+?( const volatile T *, ptrdiff_t ), 2129 * ?+?( ptrdiff_t, const volatile T * ), 1723 forall( type T ) const volatile T * ?+?( const volatile T *, ptrdiff_t ), * ?+?( ptrdiff_t, const volatile T * ), 2130 1724 * ??( const volatile T *, ptrdiff_t ); 2131 2132 forall( type T ) restrict volatile T 2133 * ?+?( restrict volatile T *, ptrdiff_t ), 2134 * ?+?( ptrdiff_t, restrict volatile T * ), 1725 forall( type T ) restrict volatile T * ?+?( restrict volatile T *, ptrdiff_t ), * ?+?( ptrdiff_t, restrict volatile T * ), 2135 1726 * ??( restrict volatile T *, ptrdiff_t ); 2136 2137 forall( type T ) _Atomic const restrict T 2138 * ?+?( _Atomic const restrict T *, ptrdiff_t ), 1727 forall( type T ) _Atomic const restrict T * ?+?( _Atomic const restrict T *, ptrdiff_t ), 2139 1728 * ?+?( ptrdiff_t, _Atomic const restrict T * ), 2140 1729 * ??( _Atomic const restrict T *, ptrdiff_t ); 2141 2142 1730 forall( type T ) ptrdiff_t 2143 1731 * ??( const restrict volatile T *, const restrict volatile T * ), 2144 1732 * ??( _Atomic const restrict volatile T *, _Atomic const restrict volatile T * ); 2145 1733 \end{lstlisting} 2146 For every extended integer type \lstinline$X$ with \Index{integer conversion rank} greater than the 2147 rank of \lstinline$int$ there exist 1734 For every extended integer type \lstinline$X$ with \Index{integer conversion rank} greater than the rank of \lstinline$int$ there exist 2148 1735 % Don't use predefined: keep this out of prelude.cf. 2149 1736 \begin{lstlisting} … … 2152 1739 2153 1740 \semantics 2154 The interpretations of additive expressions are the interpretations of the corresponding function 2155 calls. 2156 2157 \begin{rationale} 2158 \lstinline$ptrdiff_t$ is an implementationdefined identifier defined in \lstinline$<stddef.h>$ that 2159 is synonymous with a signed integral type that is large enough to hold the difference between two 2160 pointers. It seems reasonable to use it for pointer addition as well. (This is technically a 2161 difference between \CFA and C, which only specifies that pointer addition uses an \emph{integral} 2162 argument.) Hence it is also used for subscripting, which is defined in terms of pointer addition. 2163 The {\c11} standard uses \lstinline$size_t$ in several cases where a library function takes an 2164 argument that is used as a subscript, but \lstinline$size_t$ is unsuitable here because it is an 2165 unsigned type. 1741 The interpretations of additive expressions are the interpretations of the corresponding function calls. 1742 1743 \begin{rationale} 1744 \lstinline$ptrdiff_t$ is an implementationdefined identifier defined in \lstinline$<stddef.h>$ that is synonymous with a signed integral type that is large enough to hold the difference between two pointers. 1745 It seems reasonable to use it for pointer addition as well. (This is technically a difference between \CFA and C, which only specifies that pointer addition uses an \emph{integral} argument.) Hence it is also used for subscripting, which is defined in terms of pointer addition. 1746 The {\c11} standard uses \lstinline$size_t$ in several cases where a library function takes an argument that is used as a subscript, but \lstinline$size_t$ is unsuitable here because it is an unsigned type. 2166 1747 \end{rationale} 2167 1748 … … 2184 1765 \predefined 2185 1766 \begin{lstlisting} 2186 int ?<<?( int, int ), 2187 ?>>?( int, int ); 2188 unsigned int ?<<?( unsigned int, int ), 2189 ?>>?( unsigned int, int ); 2190 long int ?<<?( long int, int ), 2191 ?>>?( long int, int ); 2192 long unsigned int ?<<?( long unsigned int, int ), 2193 ?>>?( long unsigned int, int ); 2194 long long int ?<<?( long long int, int ), 2195 ?>>?( long long int, int ); 2196 long long unsigned int ?<<?( long long unsigned int, int ), 2197 ?>>?( long long unsigned int, int); 2198 \end{lstlisting} 2199 For every extended integer type \lstinline$X$ with \Index{integer conversion rank} greater than the 2200 rank of \lstinline$int$ there exist 1767 int ?<<?( int, int ), ?>>?( int, int ); 1768 unsigned int ?<<?( unsigned int, int ), ?>>?( unsigned int, int ); 1769 long int ?<<?( long int, int ), ?>>?( long int, int ); 1770 long unsigned int ?<<?( long unsigned int, int ), ?>>?( long unsigned int, int ); 1771 long long int ?<<?( long long int, int ), ?>>?( long long int, int ); 1772 long long unsigned int ?<<?( long long unsigned int, int ), ?>>?( long long unsigned int, int); 1773 \end{lstlisting} 1774 For every extended integer type \lstinline$X$ with \Index{integer conversion rank} greater than the rank of \lstinline$int$ there exist 2201 1775 % Don't use predefined: keep this out of prelude.cf. 2202 1776 \begin{lstlisting} … … 2205 1779 2206 1780 \begin{rationale} 2207 The bitwise shift operators break the usual pattern: they do not convert both operands to a common 2208 type.The right operand only undergoes \Index{integer promotion}.1781 The bitwise shift operators break the usual pattern: they do not convert both operands to a common type. 1782 The right operand only undergoes \Index{integer promotion}. 2209 1783 \end{rationale} 2210 1784 2211 1785 \semantics 2212 The interpretations of a bitwise shift expression are the interpretations of the corresponding 2213 function calls. 1786 The interpretations of a bitwise shift expression are the interpretations of the corresponding function calls. 2214 1787 2215 1788 … … 2235 1808 \predefined 2236 1809 \begin{lstlisting} 2237 int ?<?( int, int ), 2238 ?<=?( int, int ), 2239 ?>?( int, int ), 2240 ?>=?( int, int ); 2241 int ?<?( unsigned int, unsigned int ), 2242 ?<=?( unsigned int, unsigned int ), 2243 ?>?( unsigned int, unsigned int ), 2244 ?>=?( unsigned int, unsigned int ); 2245 int ?<?( long int, long int ), 2246 ?<=?( long int, long int ), 2247 ?>?( long int, long int ), 2248 ?>=?( long int, long int ); 2249 int ?<?( long unsigned int, long unsigned ), 2250 ?<=?( long unsigned int, long unsigned ), 2251 ?>?( long unsigned int, long unsigned ), 2252 ?>=?( long unsigned int, long unsigned ); 2253 int ?<?( long long int, long long int ), 2254 ?<=?( long long int, long long int ), 2255 ?>?( long long int, long long int ), 2256 ?>=?( long long int, long long int ); 2257 int ?<?( long long unsigned int, long long unsigned ), 2258 ?<=?( long long unsigned int, long long unsigned ), 2259 ?>?( long long unsigned int, long long unsigned ), 2260 ?>=?( long long unsigned int, long long unsigned ); 2261 int ?<?( float, float ), 2262 ?<=?( float, float ), 2263 ?>?( float, float ), 2264 ?>=?( float, float ); 2265 int ?<?( double, double ), 2266 ?<=?( double, double ), 2267 ?>?( double, double ), 2268 ?>=?( double, double ); 2269 int ?<?( long double, long double ), 2270 ?<=?( long double, long double ), 2271 ?>?( long double, long double ), 2272 ?>=?( long double, long double ); 2273 2274 forall( dtype DT ) int 2275 ?<?( const restrict volatile DT *, const restrict volatile DT * ), 1810 int ?<?( int, int ), ?<=?( int, int ), 1811 ?>?( int, int ), ?>=?( int, int ); 1812 int ?<?( unsigned int, unsigned int ), ?<=?( unsigned int, unsigned int ), 1813 ?>?( unsigned int, unsigned int ), ?>=?( unsigned int, unsigned int ); 1814 int ?<?( long int, long int ), ?<=?( long int, long int ), 1815 ?>?( long int, long int ), ?>=?( long int, long int ); 1816 int ?<?( long unsigned int, long unsigned ), ?<=?( long unsigned int, long unsigned ), 1817 ?>?( long unsigned int, long unsigned ), ?>=?( long unsigned int, long unsigned ); 1818 int ?<?( long long int, long long int ), ?<=?( long long int, long long int ), 1819 ?>?( long long int, long long int ), ?>=?( long long int, long long int ); 1820 int ?<?( long long unsigned int, long long unsigned ), ?<=?( long long unsigned int, long long unsigned ), 1821 ?>?( long long unsigned int, long long unsigned ), ?>=?( long long unsigned int, long long unsigned ); 1822 int ?<?( float, float ), ?<=?( float, float ), 1823 ?>?( float, float ), ?>=?( float, float ); 1824 int ?<?( double, double ), ?<=?( double, double ), 1825 ?>?( double, double ), ?>=?( double, double ); 1826 int ?<?( long double, long double ), ?<=?( long double, long double ), 1827 ?>?( long double, long double ), ?>=?( long double, long double ); 1828 forall( dtype DT ) int ?<?( const restrict volatile DT *, const restrict volatile DT * ), 2276 1829 ?<?( _Atomic const restrict volatile DT *, _Atomic const restrict volatile DT * ), 2277 1830 ?<=?( const restrict volatile DT *, const restrict volatile DT * ), … … 2282 1835 ?>=?( _Atomic const restrict volatile DT *, _Atomic const restrict volatile DT * ); 2283 1836 \end{lstlisting} 2284 For every extended integer type \lstinline$X$ with \Index{integer conversion rank} greater than the 2285 rank of \lstinline$int$ there exist 1837 For every extended integer type \lstinline$X$ with \Index{integer conversion rank} greater than the rank of \lstinline$int$ there exist 2286 1838 % Don't use predefined: keep this out of prelude.cf. 2287 1839 \begin{lstlisting} … … 2293 1845 2294 1846 \semantics 2295 The interpretations of a relational expression are the interpretations of the corresponding function 2296 call. 1847 The interpretations of a relational expression are the interpretations of the corresponding function call. 2297 1848 2298 1849 … … 2314 1865 \predefined 2315 1866 \begin{lstlisting} 2316 int ?==?( int, int ), 2317 ?!=?( int, int ), 2318 ?==?( unsigned int, unsigned int ), 2319 ?!=?( unsigned int, unsigned int ), 2320 ?==?( long int, long int ), 2321 ?!=?( long int, long int ), 2322 ?==?( long unsigned int, long unsigned int ), 2323 ?!=?( long unsigned int, long unsigned int ), 2324 ?==?( long long int, long long int ), 2325 ?!=?( long long int, long long int ), 2326 ?==?( long long unsigned int, long long unsigned int ), 2327 ?!=?( long long unsigned int, long long unsigned int ), 2328 ?==?( float, float ), 2329 ?!=?( float, float ), 2330 ?==?( _Complex float, float ), 2331 ?!=?( _Complex float, float ), 2332 ?==?( float, _Complex float ), 2333 ?!=?( float, _Complex float ), 2334 ?==?( _Complex float, _Complex float ), 2335 ?!=?( _Complex float, _Complex float ), 2336 ?==?( double, double ), 2337 ?!=?( double, double ), 2338 ?==?( _Complex double, double ), 2339 ?!=?( _Complex double, double ), 2340 ?==?( double, _Complex double ), 2341 ?!=?( double, _Complex double ), 2342 ?==?( _Complex double, _Complex double ), 2343 ?!=?( _Complex double, _Complex double ), 2344 ?==?( long double, long double ), 2345 ?!=?( long double, long double ), 2346 ?==?( _Complex long double, long double ), 2347 ?!=?( _Complex long double, long double ), 2348 ?==?( long double, _Complex long double ), 2349 ?!=?( long double, _Complex long double ), 2350 ?==?( _Complex long double, _Complex long double ), 2351 ?!=?( _Complex long double, _Complex long double ); 2352 1867 int ?==?( int, int ), ?!=?( int, int ), 1868 ?==?( unsigned int, unsigned int ), ?!=?( unsigned int, unsigned int ), 1869 ?==?( long int, long int ), ?!=?( long int, long int ), 1870 ?==?( long unsigned int, long unsigned int ), ?!=?( long unsigned int, long unsigned int ), 1871 ?==?( long long int, long long int ), ?!=?( long long int, long long int ), 1872 ?==?( long long unsigned int, long long unsigned int ), ?!=?( long long unsigned int, long long unsigned int ), 1873 ?==?( float, float ), ?!=?( float, float ), 1874 ?==?( _Complex float, float ), ?!=?( _Complex float, float ), 1875 ?==?( float, _Complex float ), ?!=?( float, _Complex float ), 1876 ?==?( _Complex float, _Complex float ), ?!=?( _Complex float, _Complex float ), 1877 ?==?( double, double ), ?!=?( double, double ), 1878 ?==?( _Complex double, double ), ?!=?( _Complex double, double ), 1879 ?==?( double, _Complex double ), ?!=?( double, _Complex double ), 1880 ?==?( _Complex double, _Complex double ), ?!=?( _Complex double, _Complex double ), 1881 ?==?( long double, long double ), ?!=?( long double, long double ), 1882 ?==?( _Complex long double, long double ), ?!=?( _Complex long double, long double ), 1883 ?==?( long double, _Complex long double ), ?!=?( long double, _Complex long double ), 1884 ?==?( _Complex long double, _Complex long double ), ?!=?( _Complex long double, _Complex long double ); 2353 1885 forall( dtype DT ) int 2354 1886 ?==?( const restrict volatile DT *, const restrict volatile DT * ), … … 2375 1907 ?==?( forall( dtype DT2) const DT2*, _Atomic const restrict volatile DT * ), 2376 1908 ?!=?( forall( dtype DT2) const DT2*, _Atomic const restrict volatile DT * ); 2377 2378 1909 forall( ftype FT ) int 2379 ?==?( FT *, FT * ), 2380 ?!=?( FT *, FT * ), 2381 ?==?( FT *, forall( ftype FT2) FT2 * ), 2382 ?!=?( FT *, forall( ftype FT2) FT2 * ), 2383 ?==?( forall( ftype FT2) FT2*, FT * ), 2384 ?!=?( forall( ftype FT2) FT2*, FT * ), 2385 ?==?( forall( ftype FT2) FT2*, forall( ftype FT3) FT3 * ), 2386 ?!=?( forall( ftype FT2) FT2*, forall( ftype FT3) FT3 * ); 2387 \end{lstlisting} 2388 For every extended integer type \lstinline$X$ with \Index{integer conversion rank} greater than the 2389 rank of \lstinline$int$ there exist 1910 ?==?( FT *, FT * ), ?!=?( FT *, FT * ), 1911 ?==?( FT *, forall( ftype FT2) FT2 * ), ?!=?( FT *, forall( ftype FT2) FT2 * ), 1912 ?==?( forall( ftype FT2) FT2*, FT * ), ?!=?( forall( ftype FT2) FT2*, FT * ), 1913 ?==?( forall( ftype FT2) FT2*, forall( ftype FT3) FT3 * ), ?!=?( forall( ftype FT2) FT2*, forall( ftype FT3) FT3 * ); 1914 \end{lstlisting} 1915 For every extended integer type \lstinline$X$ with \Index{integer conversion rank} greater than the rank of \lstinline$int$ there exist 2390 1916 % Don't use predefined: keep this out of prelude.cf. 2391 1917 \begin{lstlisting} … … 2395 1921 2396 1922 \begin{rationale} 2397 The polymorphic equality operations come in three styles: comparisons between pointers of compatible 2398 types, between pointers to \lstinline$void$ and pointers to object types or incomplete types, and 2399 between the \Index{null pointer} constant and pointers to any type. In the last case, a special 2400 constraint rule for null pointer constant operands has been replaced by a consequence of the \CFA 2401 type system. 1923 The polymorphic equality operations come in three styles: comparisons between pointers of compatible types, between pointers to \lstinline$void$ and pointers to object types or incomplete types, and between the \Index{null pointer} constant and pointers to any type. 1924 In the last case, a special constraint rule for null pointer constant operands has been replaced by a consequence of the \CFA type system. 2402 1925 \end{rationale} 2403 1926 2404 1927 \semantics 2405 The interpretations of an equality expression are the interpretations of the corresponding function 2406 call. 1928 The interpretations of an equality expression are the interpretations of the corresponding function call. 2407 1929 2408 1930 \begin{sloppypar} 2409 The result of an equality comparison between two pointers to predefined functions or predefined 2410 values is implementationdefined. 1931 The result of an equality comparison between two pointers to predefined functions or predefined values is implementationdefined. 2411 1932 \end{sloppypar} 2412 1933 \begin{rationale} 2413 The implementationdefined status of equality comparisons allows implementations to use one library 2414 routine to implement many predefined functions. These optimization are particularly important when 2415 the predefined functions are polymorphic, as is the case for most pointer operations 1934 The implementationdefined status of equality comparisons allows implementations to use one library routine to implement many predefined functions. 1935 These optimization are particularly important when the predefined functions are polymorphic, as is the case for most pointer operations 2416 1936 \end{rationale} 2417 1937 … … 2439 1959 long long unsigned int ?&?( long long unsigned int, long long unsigned int ); 2440 1960 \end{lstlisting} 2441 For every extended integer type \lstinline$X$ with \Index{integer conversion rank} greater than the 2442 rank of \lstinline$int$ there exist 1961 For every extended integer type \lstinline$X$ with \Index{integer conversion rank} greater than the rank of \lstinline$int$ there exist 2443 1962 % Don't use predefined: keep this out of prelude.cf. 2444 1963 \begin{lstlisting} … … 2447 1966 2448 1967 \semantics 2449 The interpretations of a bitwise AND expression are the interpretations of the corresponding 2450 function call. 1968 The interpretations of a bitwise AND expression are the interpretations of the corresponding function call. 2451 1969 2452 1970 … … 2473 1991 long long unsigned int ?^?( long long unsigned int, long long unsigned int ); 2474 1992 \end{lstlisting} 2475 For every extended integer type \lstinline$X$ with \Index{integer conversion rank} greater than the 2476 rank of \lstinline$int$ there exist 1993 For every extended integer type \lstinline$X$ with \Index{integer conversion rank} greater than the rank of \lstinline$int$ there exist 2477 1994 % Don't use predefined: keep this out of prelude.cf. 2478 1995 \begin{lstlisting} … … 2481 1998 2482 1999 \semantics 2483 The interpretations of a bitwise exclusive OR expression are the interpretations of the 2484 corresponding function call. 2000 The interpretations of a bitwise exclusive OR expression are the interpretations of the corresponding function call. 2485 2001 2486 2002 … … 2507 2023 long long unsigned int ??( long long unsigned int, long long unsigned int ); 2508 2024 \end{lstlisting} 2509 For every extended integer type \lstinline$X$ with \Index{integer conversion rank} greater than the 2510 rank of \lstinline$int$ there exist 2025 For every extended integer type \lstinline$X$ with \Index{integer conversion rank} greater than the rank of \lstinline$int$ there exist 2511 2026 % Don't use predefined: keep this out of prelude.cf. 2512 2027 \begin{lstlisting} … … 2515 2030 2516 2031 \semantics 2517 The interpretations of a bitwise inclusive OR expression are the interpretations of the 2518 corresponding function call. 2032 The interpretations of a bitwise inclusive OR expression are the interpretations of the corresponding function call. 2519 2033 2520 2034 … … 2528 2042 2529 2043 \semantics The operands of the expression ``\lstinline$a && b$'' are treated as 2530 ``\lstinline$(int)((a)!=0)$'' and ``\lstinline$(int)((b)!=0)$'', which shall both be 2531 unambiguous. The expression has only one interpretation, which is of type \lstinline$int$. 2532 \begin{rationale} 2533 When the operands of a logical expression are values of builtin types, and ``\lstinline$!=$'' has 2534 not been redefined for those types, the compiler can optimize away the function calls. 2044 ``\lstinline$(int)((a)!=0)$'' and ``\lstinline$(int)((b)!=0)$'', which shall both be unambiguous. 2045 The expression has only one interpretation, which is of type \lstinline$int$. 2046 \begin{rationale} 2047 When the operands of a logical expression are values of builtin types, and ``\lstinline$!=$'' has not been redefined for those types, the compiler can optimize away the function calls. 2535 2048 2536 2049 A common C idiom omits comparisons to \lstinline$0$ in the controlling expressions of loops and 2537 \lstinline$if$ statements. For instance, the loop below iterates as long as \lstinline$rp$ points2538 at a \lstinline$Rational$ value that is nonzero.2050 \lstinline$if$ statements. 2051 For instance, the loop below iterates as long as \lstinline$rp$ points at a \lstinline$Rational$ value that is nonzero. 2539 2052 2540 2053 \begin{lstlisting} … … 2543 2056 extern int ?!=?( Rational, Rational ); 2544 2057 Rational *rp; 2545 2546 2058 while ( rp && *rp ) { ... } 2547 2059 \end{lstlisting} 2548 The logical expression calls the \lstinline$Rational$ inequality operator, passing 2549 it \lstinline$*rp$ and the \lstinline$Rational 0$, and getting a 1 or 0 as a result. In 2550 contrast, {\CC} would apply a programmerdefined \lstinline$Rational$to\lstinline$int$ 2551 conversion to \lstinline$*rp$ in the equivalent situation. The conversion to \lstinline$int$ would 2552 produce a general integer value, which is unfortunate, and possibly dangerous if the conversion was 2553 not written with this situation in mind. 2060 The logical expression calls the \lstinline$Rational$ inequality operator, passing it \lstinline$*rp$ and the \lstinline$Rational 0$, and getting a 1 or 0 as a result. 2061 In contrast, {\CC} would apply a programmerdefined \lstinline$Rational$to\lstinline$int$ conversion to \lstinline$*rp$ in the equivalent situation. 2062 The conversion to \lstinline$int$ would produce a general integer value, which is unfortunate, and possibly dangerous if the conversion was not written with this situation in mind. 2554 2063 \end{rationale} 2555 2064 … … 2565 2074 \semantics 2566 2075 2567 The operands of the expression ``\lstinline$a  b$'' are treated as ``\lstinline$(int)((a)!=0)$'' 2568 and ``\lstinline$(int)((b))!=0)$'', which shall both be unambiguous. The expression has only one 2569 interpretation, which is of type \lstinline$int$. 2076 The operands of the expression ``\lstinline$a  b$'' are treated as ``\lstinline$(int)((a)!=0)$'' and ``\lstinline$(int)((b))!=0)$'', which shall both be unambiguous. 2077 The expression has only one interpretation, which is of type \lstinline$int$. 2570 2078 2571 2079 … … 2580 2088 2581 2089 \semantics 2582 In the conditional expression\use{?:} ``\lstinline$a?b:c$'', if the second and 2583 third operands both have an interpretation with \lstinline$void$ type, then the expression has an 2584 interpretation with type \lstinline$void$, equivalent to 2090 In the conditional expression\use{?:} ``\lstinline$a?b:c$'', if the second and third operands both have an interpretation with \lstinline$void$ type, then the expression has an interpretation with type \lstinline$void$, equivalent to 2585 2091 \begin{lstlisting} 2586 2092 ( int)(( a)!=0) ? ( void)( b) : ( void)( c) 2587 2093 \end{lstlisting} 2588 2094 2589 If the second and third operands both have interpretations with non\lstinline$void$ types, the 2590 expression is treated as if it were the call ``\lstinline$cond((a)!=0, b, c)$'', 2591 with \lstinline$cond$ declared as 2095 If the second and third operands both have interpretations with non\lstinline$void$ types, the expression is treated as if it were the call ``\lstinline$cond((a)!=0, b, c)$'', with \lstinline$cond$ declared as 2592 2096 \begin{lstlisting} 2593 2097 forall( type T ) T cond( int, T, T ); 2594 2595 forall( dtype D ) void 2596 * cond( int, D *, void * ), 2597 * cond( int, void *, D * ); 2598 2599 forall( dtype D ) _atomic void 2600 * cond( int, _Atomic D *, _Atomic void * ), 2601 * cond( int, _Atomic void *, _Atomic D * ); 2602 2603 forall( dtype D ) const void 2604 * cond( int, const D *, const void * ), 2605 * cond( int, const void *, const D * ); 2606 2607 forall( dtype D ) restrict void 2608 * cond( int, restrict D *, restrict void * ), 2609 * cond( int, restrict void *, restrict D * ); 2610 2611 forall( dtype D ) volatile void 2612 * cond( int, volatile D *, volatile void * ), 2613 * cond( int, volatile void *, volatile D * ); 2614 2615 forall( dtype D ) _Atomic const void 2616 * cond( int, _Atomic const D *, _Atomic const void * ), 2617 * cond( int, _Atomic const void *, _Atomic const D * ); 2618 2619 forall( dtype D ) _Atomic restrict void 2620 * cond( int, _Atomic restrict D *, _Atomic restrict void * ), 2621 * cond( int, _Atomic restrict void *, _Atomic restrict D * ); 2622 2623 forall( dtype D ) _Atomic volatile void 2624 * cond( int, _Atomic volatile D *, _Atomic volatile void * ), 2625 * cond( int, _Atomic volatile void *, _Atomic volatile D * ); 2626 2627 forall( dtype D ) const restrict void 2628 * cond( int, const restrict D *, const restrict void * ), 2629 * cond( int, const restrict void *, const restrict D * ); 2630 2631 forall( dtype D ) const volatile void 2632 * cond( int, const volatile D *, const volatile void * ), 2633 * cond( int, const volatile void *, const volatile D * ); 2634 2635 forall( dtype D ) restrict volatile void 2636 * cond( int, restrict volatile D *, restrict volatile void * ), 2637 * cond( int, restrict volatile void *, restrict volatile D * ); 2638 2639 forall( dtype D ) _Atomic const restrict void 2640 * cond( int, _Atomic const restrict D *, _Atomic const restrict void * ), 2098 forall( dtype D ) void * cond( int, D *, void * ), * cond( int, void *, D * ); 2099 forall( dtype D ) _atomic void * cond( 2100 int, _Atomic D *, _Atomic void * ), * cond( int, _Atomic void *, _Atomic D * ); 2101 forall( dtype D ) const void * cond( 2102 int, const D *, const void * ), * cond( int, const void *, const D * ); 2103 forall( dtype D ) restrict void * cond( 2104 int, restrict D *, restrict void * ), * cond( int, restrict void *, restrict D * ); 2105 forall( dtype D ) volatile void * cond( 2106 int, volatile D *, volatile void * ), * cond( int, volatile void *, volatile D * ); 2107 forall( dtype D ) _Atomic const void * cond( 2108 int, _Atomic const D *, _Atomic const void * ), * cond( int, _Atomic const void *, _Atomic const D * ); 2109 forall( dtype D ) _Atomic restrict void * cond( 2110 int, _Atomic restrict D *, _Atomic restrict void * ), * cond( int, _Atomic restrict void *, _Atomic restrict D * ); 2111 forall( dtype D ) _Atomic volatile void * cond( 2112 int, _Atomic volatile D *, _Atomic volatile void * ), * cond( int, _Atomic volatile void *, _Atomic volatile D * ); 2113 forall( dtype D ) const restrict void * cond( 2114 int, const restrict D *, const restrict void * ), * cond( int, const restrict void *, const restrict D * ); 2115 forall( dtype D ) const volatile void * cond( 2116 int, const volatile D *, const volatile void * ), * cond( int, const volatile void *, const volatile D * ); 2117 forall( dtype D ) restrict volatile void * cond( 2118 int, restrict volatile D *, restrict volatile void * ), * cond( int, restrict volatile void *, restrict volatile D * ); 2119 forall( dtype D ) _Atomic const restrict void * cond( 2120 int, _Atomic const restrict D *, _Atomic const restrict void * ), 2641 2121 * cond( int, _Atomic const restrict void *, _Atomic const restrict D * ); 2642 2643 forall( dtype D ) _Atomic const volatile void 2644 * cond( int, _Atomic const volatile D *, _Atomic const volatile void * ), 2122 forall( dtype D ) _Atomic const volatile void * cond( 2123 int, _Atomic const volatile D *, _Atomic const volatile void * ), 2645 2124 * cond( int, _Atomic const volatile void *, _Atomic const volatile D * ); 2646 2647 forall( dtype D ) _Atomic restrict volatile void 2648 * cond( int, _Atomic restrict volatile D *, 2649 _Atomic restrict volatile void * ), 2650 * cond( int, _Atomic restrict volatile void *, 2651 _Atomic restrict volatile D * ); 2652 2653 forall( dtype D ) const restrict volatile void 2654 * cond( int, const restrict volatile D *, 2655 const restrict volatile void * ), 2656 * cond( int, const restrict volatile void *, 2657 const restrict volatile D * ); 2658 2659 forall( dtype D ) _Atomic const restrict volatile void 2660 * cond( int, _Atomic const restrict volatile D *, 2661 _Atomic const restrict volatile void * ), 2662 * cond( int, _Atomic const restrict volatile void *, 2663 _Atomic const restrict volatile D * ); 2664 \end{lstlisting} 2665 2666 \begin{rationale} 2667 The object of the above is to apply the \Index{usual arithmetic conversion}s when the second and 2668 third operands have arithmetic type, and to combine the qualifiers of the second and third operands 2669 if they are pointers. 2125 forall( dtype D ) _Atomic restrict volatile void * cond( 2126 int, _Atomic restrict volatile D *, _Atomic restrict volatile void * ), 2127 * cond( int, _Atomic restrict volatile void *, _Atomic restrict volatile D * ); 2128 forall( dtype D ) const restrict volatile void * cond( 2129 int, const restrict volatile D *, const restrict volatile void * ), 2130 * cond( int, const restrict volatile void *, const restrict volatile D * ); 2131 forall( dtype D ) _Atomic const restrict volatile void * cond( 2132 int, _Atomic const restrict volatile D *, _Atomic const restrict volatile void * ), 2133 * cond( int, _Atomic const restrict volatile void *, _Atomic const restrict volatile D * ); 2134 \end{lstlisting} 2135 2136 \begin{rationale} 2137 The object of the above is to apply the \Index{usual arithmetic conversion}s when the second and third operands have arithmetic type, and to combine the qualifiers of the second and third operands if they are pointers. 2670 2138 \end{rationale} 2671 2139 … … 2685 2153 rand() ? cip : vip; 2686 2154 \end{lstlisting} 2687 The expression has type \lstinline$const volatile int *$, with safe conversions applied to the second 2688 and third operands to add \lstinline$volatile$ and \lstinline$const$ qualifiers, respectively. 2155 The expression has type \lstinline$const volatile int *$, with safe conversions applied to the second and third operands to add \lstinline$volatile$ and \lstinline$const$ qualifiers, respectively. 2689 2156 2690 2157 \begin{lstlisting} … … 2708 2175 2709 2176 \rewriterules 2710 Let ``\(\leftarrow\)'' be any of the assignment operators. Then 2177 Let ``\(\leftarrow\)'' be any of the assignment operators. 2178 Then 2711 2179 \use{?=?}\use{?*=?}\use{?/=?}\use{?%=?}\use{?+=?}\use{?=?} 2712 2180 \use{?>>=?}\use{?&=?}\use{?^=?}\use{?"=?}%use{?<<=?} … … 2716 2184 2717 2185 \semantics 2718 Each interpretation of the left operand of an assignment expression is considered separately. For 2719 each interpretation that is a bitfield or is declared with the \lstinline$register$ storage class 2720 specifier, the expression has one valid interpretation, with the type of the left operand. The 2721 right operand is cast to that type, and the assignment expression is ambiguous if either operand is. 2722 For the remaining interpretations, the expression is rewritten, and the interpretations of the 2723 assignment expression are the interpretations of the corresponding function call. Finally, all 2724 interpretations of the expression produced for the different interpretations of the left operand are 2725 combined to produce the interpretations of the expression as a whole; where interpretations have 2726 compatible result types, the best interpretations are selected in the manner described for function 2727 call expressions. 2186 Each interpretation of the left operand of an assignment expression is considered separately. 2187 For each interpretation that is a bitfield or is declared with the \lstinline$register$ storage class specifier, the expression has one valid interpretation, with the type of the left operand. 2188 The right operand is cast to that type, and the assignment expression is ambiguous if either operand is. 2189 For the remaining interpretations, the expression is rewritten, and the interpretations of the assignment expression are the interpretations of the corresponding function call. 2190 Finally, all interpretations of the expression produced for the different interpretations of the left operand are combined to produce the interpretations of the expression as a whole; 2191 where interpretations have compatible result types, the best interpretations are selected in the manner described for function call expressions. 2728 2192 2729 2193 … … 2790 2254 ?=?( volatile _Complex long double *, _Complex long double ), 2791 2255 ?=?( _Atomic volatile _Complex long double *, _Atomic _Complex long double ); 2792 2793 2256 forall( ftype FT ) FT 2794 2257 * ?=?( FT * volatile *, FT * ), 2795 2258 * ?=?( FT * volatile *, forall( ftype F ) F * ); 2796 2797 2259 forall( ftype FT ) FT const 2798 2260 * ?=?( FT const * volatile *, FT const * ), 2799 2261 * ?=?( FT const * volatile *, forall( ftype F ) F * ); 2800 2801 2262 forall( ftype FT ) FT volatile 2802 2263 * ?=?( FT volatile * volatile *, FT * ), 2803 2264 * ?=?( FT volatile * volatile *, forall( ftype F ) F * ); 2804 2805 2265 forall( ftype FT ) FT const 2806 2266 * ?=?( FT const volatile * volatile *, FT const * ), 2807 2267 * ?=?( FT const volatile * volatile *, forall( ftype F ) F * ); 2808 2809 2268 forall( dtype DT ) DT 2810 2269 * ?=?( DT * restrict volatile *, DT * ), … … 2814 2273 * ?=?( DT * _Atomic restrict volatile *, void * ), 2815 2274 * ?=?( DT * _Atomic restrict volatile *, forall( dtype D ) D * ); 2816 2817 2275 forall( dtype DT ) DT _Atomic 2818 2276 * ?=?( _Atomic DT * restrict volatile *, DT _Atomic * ), … … 2822 2280 * ?=?( _Atomic DT * _Atomic restrict volatile *, void * ), 2823 2281 * ?=?( _Atomic DT * _Atomic restrict volatile *, forall( dtype D ) D * ); 2824 2825 2282 forall( dtype DT ) DT const 2826 2283 * ?=?( DT const * restrict volatile *, DT const * ), … … 2830 2287 * ?=?( DT const * _Atomic restrict volatile *, void const * ), 2831 2288 * ?=?( DT const * _Atomic restrict volatile *, forall( dtype D ) D * ); 2832 2833 2289 forall( dtype DT ) DT restrict 2834 2290 * ?=?( restrict DT * restrict volatile *, DT restrict * ), … … 2838 2294 * ?=?( restrict DT * _Atomic restrict volatile *, void * ), 2839 2295 * ?=?( restrict DT * _Atomic restrict volatile *, forall( dtype D ) D * ); 2840 2841 2296 forall( dtype DT ) DT volatile 2842 2297 * ?=?( DT volatile * restrict volatile *, DT volatile * ), … … 2846 2301 * ?=?( DT volatile * _Atomic restrict volatile *, void volatile * ), 2847 2302 * ?=?( DT volatile * _Atomic restrict volatile *, forall( dtype D ) D * ); 2848 2849 2303 forall( dtype DT ) DT _Atomic const 2850 2304 * ?=?( DT _Atomic const * restrict volatile *, DT _Atomic const * ), … … 2854 2308 * ?=?( DT _Atomic const * _Atomic restrict volatile *, void const * ), 2855 2309 * ?=?( DT _Atomic const * _Atomic restrict volatile *, forall( dtype D ) D * ); 2856 2857 2310 forall( dtype DT ) DT _Atomic restrict 2858 2311 * ?=?( _Atomic restrict DT * restrict volatile *, DT _Atomic restrict * ), … … 2862 2315 * ?=?( _Atomic restrict DT * _Atomic restrict volatile *, void * ), 2863 2316 * ?=?( _Atomic restrict DT * _Atomic restrict volatile *, forall( dtype D ) D * ); 2864 2865 2317 forall( dtype DT ) DT _Atomic volatile 2866 2318 * ?=?( DT _Atomic volatile * restrict volatile *, DT _Atomic volatile * ), … … 2870 2322 * ?=?( DT _Atomic volatile * _Atomic restrict volatile *, void volatile * ), 2871 2323 * ?=?( DT _Atomic volatile * _Atomic restrict volatile *, forall( dtype D ) D * ); 2872 2873 2324 forall( dtype DT ) DT const restrict 2874 2325 * ?=?( DT const restrict * restrict volatile *, DT const restrict * ), … … 2878 2329 * ?=?( DT const restrict * _Atomic restrict volatile *, void const * ), 2879 2330 * ?=?( DT const restrict * _Atomic restrict volatile *, forall( dtype D ) D * ); 2880 2881 2331 forall( dtype DT ) DT const volatile 2882 2332 * ?=?( DT const volatile * restrict volatile *, DT const volatile * ), … … 2886 2336 * ?=?( DT const volatile * _Atomic restrict volatile *, void const volatile * ), 2887 2337 * ?=?( DT const volatile * _Atomic restrict volatile *, forall( dtype D ) D * ); 2888 2889 2338 forall( dtype DT ) DT restrict volatile 2890 2339 * ?=?( DT restrict volatile * restrict volatile *, DT restrict volatile * ), … … 2894 2343 * ?=?( DT restrict volatile * _Atomic restrict volatile *, void volatile * ), 2895 2344 * ?=?( DT restrict volatile * _Atomic restrict volatile *, forall( dtype D ) D * ); 2896 2897 2345 forall( dtype DT ) DT _Atomic const restrict 2898 2346 * ?=?( DT _Atomic const restrict * restrict volatile *, … … 2908 2356 * ?=?( DT _Atomic const restrict * _Atomic restrict volatile *, 2909 2357 forall( dtype D ) D * ); 2910 2911 2358 forall( dtype DT ) DT _Atomic const volatile 2912 2359 * ?=?( DT _Atomic const volatile * restrict volatile *, … … 2922 2369 * ?=?( DT _Atomic const volatile * _Atomic restrict volatile *, 2923 2370 forall( dtype D ) D * ); 2924 2925 2371 forall( dtype DT ) DT _Atomic restrict volatile 2926 2372 * ?=?( DT _Atomic restrict volatile * restrict volatile *, … … 2936 2382 * ?=?( DT _Atomic restrict volatile * _Atomic restrict volatile *, 2937 2383 forall( dtype D ) D * ); 2938 2939 2384 forall( dtype DT ) DT const restrict volatile 2940 2385 * ?=?( DT const restrict volatile * restrict volatile *, … … 2950 2395 * ?=?( DT const restrict volatile * _Atomic restrict volatile *, 2951 2396 forall( dtype D ) D * ); 2952 2953 2397 forall( dtype DT ) DT _Atomic const restrict volatile 2954 2398 * ?=?( DT _Atomic const restrict volatile * restrict volatile *, … … 2964 2408 * ?=?( DT _Atomic const restrict volatile * _Atomic restrict volatile *, 2965 2409 forall( dtype D ) D * ); 2966 2967 2410 forall( dtype DT ) void 2968 2411 * ?=?( void * restrict volatile *, DT * ); 2969 2970 2412 forall( dtype DT ) void const 2971 2413 * ?=?( void const * restrict volatile *, DT const * ); 2972 2973 2414 forall( dtype DT ) void volatile 2974 2415 * ?=?( void volatile * restrict volatile *, DT volatile * ); 2975 2976 2416 forall( dtype DT ) void const volatile 2977 2417 * ?=?( void const volatile * restrict volatile *, DT const volatile * ); 2978 2418 \end{lstlisting} 2979 2419 \begin{rationale} 2980 The pattern of overloadings for simple assignment resembles that of pointer increment and decrement, 2981 except that the polymorphic pointer assignment functions declare a \lstinline$dtype$ parameter, 2982 instead of a \lstinline$type$ parameter, because the left operand may be a pointer to an incomplete 2983 type. 2420 The pattern of overloadings for simple assignment resembles that of pointer increment and decrement, except that the polymorphic pointer assignment functions declare a \lstinline$dtype$ parameter, instead of a \lstinline$type$ parameter, because the left operand may be a pointer to an incomplete type. 2984 2421 \end{rationale} 2985 2422 … … 3006 2443 3007 2444 \semantics 3008 The structure assignment functions provide memberwise assignment; each nonarray member and each 3009 element of each array member of the right argument is assigned to the corresponding member or 3010 element of the left argument using the assignment function defined for its type. All other 3011 assignment functions have the same effect as the corresponding C assignment expression. 3012 \begin{rationale} 3013 Note that, by default, union assignment\index{deficiencies!union assignment} uses C semanticsthat 3014 is, bitwise copyeven if some of the union members have programmerdefined assignment functions. 2445 The structure assignment functions provide memberwise assignment; 2446 each nonarray member and each element of each array member of the right argument is assigned to the corresponding member or element of the left argument using the assignment function defined for its type. 2447 All other assignment functions have the same effect as the corresponding C assignment expression. 2448 \begin{rationale} 2449 Note that, by default, union assignment\index{deficiencies!union assignment} uses C semanticsthat is, bitwise copyeven if some of the union members have programmerdefined assignment functions. 3015 2450 \end{rationale} 3016 2451 … … 3025 2460 * ?+=?( T * _Atomic restrict volatile *, ptrdiff_t ), 3026 2461 * ?=?( T * _Atomic restrict volatile *, ptrdiff_t ); 3027 3028 2462 forall( type T ) T _Atomic 3029 2463 * ?+=?( T _Atomic * restrict volatile *, ptrdiff_t ), … … 3031 2465 * ?+=?( T _Atomic * _Atomic restrict volatile *, ptrdiff_t ), 3032 2466 * ?=?( T _Atomic * _Atomic restrict volatile *, ptrdiff_t ); 3033 3034 2467 forall( type T ) T const 3035 2468 * ?+=?( T const * restrict volatile *, ptrdiff_t ), … … 3037 2470 * ?+=?( T const * _Atomic restrict volatile *, ptrdiff_t ), 3038 2471 * ?=?( T const * _Atomic restrict volatile *, ptrdiff_t ); 3039 3040 2472 forall( type T ) T restrict 3041 2473 * ?+=?( T restrict * restrict volatile *, ptrdiff_t ), … … 3043 2475 * ?+=?( T restrict * _Atomic restrict volatile *, ptrdiff_t ), 3044 2476 * ?=?( T restrict * _Atomic restrict volatile *, ptrdiff_t ); 3045 3046 2477 forall( type T ) T volatile 3047 2478 * ?+=?( T volatile * restrict volatile *, ptrdiff_t ), … … 3049 2480 * ?+=?( T volatile * _Atomic restrict volatile *, ptrdiff_t ), 3050 2481 * ?=?( T volatile * _Atomic restrict volatile *, ptrdiff_t ); 3051 3052 2482 forall( type T ) T _Atomic const 3053 2483 * ?+=?( T _Atomic const restrict volatile *, ptrdiff_t ), … … 3055 2485 * ?+=?( T _Atomic const _Atomic restrict volatile *, ptrdiff_t ), 3056 2486 * ?=?( T _Atomic const _Atomic restrict volatile *, ptrdiff_t ); 3057 3058 2487 forall( type T ) T _Atomic restrict 3059 2488 * ?+=?( T _Atomic restrict * restrict volatile *, ptrdiff_t ), … … 3061 2490 * ?+=?( T _Atomic restrict * _Atomic restrict volatile *, ptrdiff_t ), 3062 2491 * ?=?( T _Atomic restrict * _Atomic restrict volatile *, ptrdiff_t ); 3063 3064 2492 forall( type T ) T _Atomic volatile 3065 2493 * ?+=?( T _Atomic volatile * restrict volatile *, ptrdiff_t ), … … 3067 2495 * ?+=?( T _Atomic volatile * _Atomic restrict volatile *, ptrdiff_t ), 3068 2496 * ?=?( T _Atomic volatile * _Atomic restrict volatile *, ptrdiff_t ); 3069 3070 2497 forall( type T ) T const restrict 3071 2498 * ?+=?( T const restrict * restrict volatile *, ptrdiff_t ), … … 3073 2500 * ?+=?( T const restrict * _Atomic restrict volatile *, ptrdiff_t ), 3074 2501 * ?=?( T const restrict * _Atomic restrict volatile *, ptrdiff_t ); 3075 3076 2502 forall( type T ) T const volatile 3077 2503 * ?+=?( T const volatile * restrict volatile *, ptrdiff_t ), … … 3079 2505 * ?+=?( T const volatile * _Atomic restrict volatile *, ptrdiff_t ), 3080 2506 * ?=?( T const volatile * _Atomic restrict volatile *, ptrdiff_t ); 3081 3082 2507 forall( type T ) T restrict volatile 3083 2508 * ?+=?( T restrict volatile * restrict volatile *, ptrdiff_t ), … … 3085 2510 * ?+=?( T restrict volatile * _Atomic restrict volatile *, ptrdiff_t ), 3086 2511 * ?=?( T restrict volatile * _Atomic restrict volatile *, ptrdiff_t ); 3087 3088 2512 forall( type T ) T _Atomic const restrict 3089 2513 * ?+=?( T _Atomic const restrict * restrict volatile *, ptrdiff_t ), … … 3091 2515 * ?+=?( T _Atomic const restrict * _Atomic restrict volatile *, ptrdiff_t ), 3092 2516 * ?=?( T _Atomic const restrict * _Atomic restrict volatile *, ptrdiff_t ); 3093 3094 2517 forall( type T ) T _Atomic const volatile 3095 2518 * ?+=?( T _Atomic const volatile * restrict volatile *, ptrdiff_t ), … … 3097 2520 * ?+=?( T _Atomic const volatile * _Atomic restrict volatile *, ptrdiff_t ), 3098 2521 * ?=?( T _Atomic const volatile * _Atomic restrict volatile *, ptrdiff_t ); 3099 3100 2522 forall( type T ) T _Atomic restrict volatile 3101 2523 * ?+=?( T _Atomic restrict volatile * restrict volatile *, ptrdiff_t ), … … 3103 2525 * ?+=?( T _Atomic restrict volatile * _Atomic restrict volatile *, ptrdiff_t ), 3104 2526 * ?=?( T _Atomic restrict volatile * _Atomic restrict volatile *, ptrdiff_t ); 3105 3106 2527 forall( type T ) T const restrict volatile 3107 2528 * ?+=?( T const restrict volatile * restrict volatile *, ptrdiff_t ), … … 3109 2530 * ?+=?( T const restrict volatile * _Atomic restrict volatile *, ptrdiff_t ), 3110 2531 * ?=?( T const restrict volatile * _Atomic restrict volatile *, ptrdiff_t ); 3111 3112 2532 forall( type T ) T _Atomic const restrict volatile 3113 2533 * ?+=?( T _Atomic const restrict volatile * restrict volatile *, ptrdiff_t ), … … 3321 2741 \semantics 3322 2742 In the comma expression ``\lstinline$a, b$'', the first operand is interpreted as 3323 ``\lstinline$( void )(a)$'', which shall be unambiguous\index{ambiguous interpretation}. The3324 interpretations of the expression are the interpretations of the second operand.2743 ``\lstinline$( void )(a)$'', which shall be unambiguous\index{ambiguous interpretation}. 2744 The interpretations of the expression are the interpretations of the second operand. 3325 2745 3326 2746 … … 3337 2757 3338 2758 \constraints 3339 If an identifier has \Index{no linkage}, there shall be no more than one declaration of the 3340 identifier ( in a declarator or type specifier ) with compatible types in the same scope and in the 3341 same name space, except that: 2759 If an identifier has \Index{no linkage}, there shall be no more than one declaration of the identifier ( in a declarator or type specifier ) with compatible types in the same scope and in the same name space, except that: 3342 2760 \begin{itemize} 3343 \item 3344 a typedef name may be redefined to denote the same type as it currently does, provided that type is 3345 not a variably modified type; 3346 \item 3347 tags may be redeclared as specified in section 6.7.2.3 of the {\c11} standard. 2761 \item a typedef name may be redefined to denote the same type as it currently does, provided that type is not a variably modified type; 2762 \item tags may be redeclared as specified in section 6.7.2.3 of the {\c11} standard. 3348 2763 \end{itemize} 3349 2764 \begin{rationale} 3350 This constraint adds the phrase ``with compatible types'' to the {\c11} constraint, to allow 3351 overloading. 3352 \end{rationale} 3353 3354 An identifier declared by a type declaration shall not be redeclared as a parameter in a function 3355 definition whose declarator includes an identifier list. 3356 \begin{rationale} 3357 This restriction echos {\c11}'s ban on the redeclaration of typedef names as parameters. This 3358 avoids an ambiguity between oldstyle function declarations and newstyle function prototypes: 2765 This constraint adds the phrase ``with compatible types'' to the {\c11} constraint, to allow overloading. 2766 \end{rationale} 2767 2768 An identifier declared by a type declaration shall not be redeclared as a parameter in a function definition whose declarator includes an identifier list. 2769 \begin{rationale} 2770 This restriction echos {\c11}'s ban on the redeclaration of typedef names as parameters. 2771 This avoids an ambiguity between oldstyle function declarations and newstyle function prototypes: 3359 2772 \begin{lstlisting} 3360 2773 void f( Complex, // ... 3000 characters ... 3361 2774 void g( Complex, // ... 3000 characters ... 3362 int Complex; { ... }3363 \end{lstlisting}3364 Without the rule, \lstinline$Complex$ would be a type in the first case, and a parameter name in the 3365 second.2775 int Complex; 2776 { ... } 2777 \end{lstlisting} 2778 Without the rule, \lstinline$Complex$ would be a type in the first case, and a parameter name in the second. 3366 2779 \end{rationale} 3367 2780 … … 3382 2795 3383 2796 \semantics 3384 \CFA extends the {\c11} definition of \define{anonymous structure} to include structure 3385 specifiers with tags, and extends the {\c11} definition of \define{anonymous union} to include union 3386 specifiers with tags. 2797 \CFA extends the {\c11} definition of \define{anonymous structure} to include structure specifiers with tags, and extends the {\c11} definition of \define{anonymous union} to include union specifiers with tags. 3387 2798 \begin{rationale} 3388 2799 This extension imitates an extension in the Plan 9 C compiler \cite{Thompson90new}. … … 3401 2812 cp.x = 0; 3402 2813 cp.color = RED; 3403 3404 2814 struct literal {@\impl{literal}@ 3405 2815 enum { NUMBER, STRING } tag; 3406 2816 union { 3407 3408 2817 double n; 2818 char *s; 3409 2819 }; 3410 2820 }; … … 3428 2838 \begin{comment} 3429 2839 \constraints 3430 If the \nonterm{declarationspecifiers} of a declaration that contains a \nonterm{forallspecifier} 3431 declares a structure or union tag, the types of the members of the structure or union shall not use 3432 any of the type identifiers declared by the \nonterm{typeparameterlist}. 3433 \begin{rationale} 3434 This sort of declaration is illegal because the scope of the type identifiers ends at the end of the 3435 declaration, but the scope of the structure tag does not. 3436 \begin{lstlisting} 3437 forall( type T ) struct Pair { T a, b; } mkPair( T, T ); // illegal 3438 \end{lstlisting} 3439 If an instance of \lstinline$struct Pair$ was declared later in the current scope, what would the 3440 members' type be? 2840 If the \nonterm{declarationspecifiers} of a declaration that contains a \nonterm{forallspecifier} declares a structure or union tag, the types of the members of the structure or union shall not use any of the type identifiers declared by the \nonterm{typeparameterlist}. 2841 \begin{rationale} 2842 This sort of declaration is illegal because the scope of the type identifiers ends at the end of the declaration, but the scope of the structure tag does not. 2843 \begin{lstlisting} 2844 forall( type T ) struct Pair { T a, b; 2845 } mkPair( T, T ); // illegal 2846 \end{lstlisting} 2847 If an instance of \lstinline$struct Pair$ was declared later in the current scope, what would the members' type be? 3441 2848 \end{rationale} 3442 2849 \end{comment} 3443 2850 3444 2851 \semantics 3445 The \nonterm{typeparameterlist}s and assertions of the \nonterm{forallspecifier}s declare type 3446 identifiers, function and object identifiers with \Index{no linkage}. 2852 The \nonterm{typeparameterlist}s and assertions of the \nonterm{forallspecifier}s declare type identifiers, function and object identifiers with \Index{no linkage}. 3447 2853 3448 2854 If, in the declaration ``\lstinline$T D$'', \lstinline$T$ contains \nonterm{forallspecifier}s and … … 3450 2856 \begin{lstlisting} 3451 2857 D( @\normalsize\nonterm{parametertypelist}@ ) 3452 \end{lstlisting} 3453 then a type identifier declared by one of the \nonterm{forallspecifier}s is an \define{inferred 3454 parameter} of the function declarator if and only if it is not an inferred parameter of a function 3455 declarator in \lstinline$D$, and it is used in the type of a parameter in the following 2858 \end{lstlisting} then a type identifier declared by one of the \nonterm{forallspecifier}s is an \define{inferred parameter} of the function declarator if and only if it is not an inferred parameter of a function declarator in \lstinline$D$, and it is used in the type of a parameter in the following 3456 2859 \nonterm{typeparameterlist} or it and an inferred parameter are used as arguments of a 3457 \Index{specification} in one of the \nonterm{forallspecifier}s. The identifiers declared by 3458 assertions that use an inferred parameter of a function declarator are \Index{assertion parameter}s 3459 of that function declarator. 2860 \Index{specification} in one of the \nonterm{forallspecifier}s. 2861 The identifiers declared by assertions that use an inferred parameter of a function declarator are \Index{assertion parameter}s of that function declarator. 3460 2862 3461 2863 \begin{comment} 3462 2864 \begin{rationale} 3463 Since every inferred parameter is used by some parameter, inference can be understood as a single 3464 bottomup pass over the expression tree, that only needs to apply local reasoning at each node. 2865 Since every inferred parameter is used by some parameter, inference can be understood as a single bottomup pass over the expression tree, that only needs to apply local reasoning at each node. 3465 2866 3466 2867 If this restriction were lifted, it would be possible to write 3467 2868 \begin{lstlisting} 3468 forall( type T ) T * alloc( void );@\use{alloc}@ 3469 int *p = alloc(); 2869 forall( type T ) T * alloc( void );@\use{alloc}@ int *p = alloc(); 3470 2870 \end{lstlisting} 3471 2871 Here \lstinline$alloc()$ would receive \lstinline$int$ as an inferred argument, and return an 3472 \lstinline$int *$. In general, if a call to \lstinline$alloc()$ is a subexpression of an expression 3473 involving polymorphic functions and overloaded identifiers, there could be considerable distance 3474 between the call and the subexpression that causes \lstinline$T$ to be bound. 2872 \lstinline$int *$. 2873 In general, if a call to \lstinline$alloc()$ is a subexpression of an expression involving polymorphic functions and overloaded identifiers, there could be considerable distance between the call and the subexpression that causes \lstinline$T$ to be bound. 3475 2874 3476 2875 With the current restriction, \lstinline$alloc()$ must be given an argument that determines … … 3482 2881 \end{comment} 3483 2882 3484 If a function declarator is part of a function definition, its inferred parameters and assertion 3485 parameters have \Index{block scope};otherwise, identifiers declared by assertions have a2883 If a function declarator is part of a function definition, its inferred parameters and assertion parameters have \Index{block scope}; 2884 otherwise, identifiers declared by assertions have a 3486 2885 \define{declaration scope}, which terminates at the end of the \nonterm{declaration}. 3487 2886 3488 2887 A function type that has at least one inferred parameter is a \define{polymorphic function} type. 3489 Function types with no inferred parameters are \define{monomorphic function} types. One function 3490 type is \define{less polymorphic} than another if it has fewer inferred parameters, or if it has the 3491 same number of inferred parameters and fewer of its explicit parameters have types that depend on an 3492 inferred parameter. 3493 3494 The names of inferred parameters and the order of identifiers in forall specifiers are not relevant 3495 to polymorphic function type compatibility. Let $f$ and $g$ be two polymorphic function types with 3496 the same number of inferred parameters, and let $f_i$ and $g_i$ be the inferred parameters of $f$ 3497 and $g$ in their order of occurance in the function types' \nonterm{parametertypelist}s. Let $f'$ 3498 be $f$ with every occurrence of $f_i$ replaced by $g_i$, for all $i$. Then $f$ and $g$ are 3499 \Index{compatible type}s if $f'$'s and $g$'s return types and parameter lists are compatible, and if 3500 for every assertion parameter of $f'$ there is an assertion parameter in $g$ with the same 3501 identifier and compatible type, and vice versa. 2888 Function types with no inferred parameters are \define{monomorphic function} types. 2889 One function type is \define{less polymorphic} than another if it has fewer inferred parameters, or if it has the same number of inferred parameters and fewer of its explicit parameters have types that depend on an inferred parameter. 2890 2891 The names of inferred parameters and the order of identifiers in forall specifiers are not relevant to polymorphic function type compatibility. 2892 Let $f$ and $g$ be two polymorphic function types with the same number of inferred parameters, and let $f_i$ and $g_i$ be the inferred parameters of $f$ and $g$ in their order of occurance in the function types' \nonterm{parametertypelist}s. 2893 Let $f'$ be $f$ with every occurrence of $f_i$ replaced by $g_i$, for all $i$. 2894 Then $f$ and $g$ are 2895 \Index{compatible type}s if $f'$'s and $g$'s return types and parameter lists are compatible, and if for every assertion parameter of $f'$ there is an assertion parameter in $g$ with the same identifier and compatible type, and vice versa. 3502 2896 3503 2897 \examples … … 3513 2907 forall( type T ) T (*pfT )( T ) = fT; 3514 2908 \end{lstlisting} 3515 \lstinline$pfi$ and \lstinline$pfT$ are pointers to functions. \lstinline$pfT$ is not 3516 polymorphic, but the function it points at is. 2909 \lstinline$pfi$ and \lstinline$pfT$ are pointers to functions. \lstinline$pfT$ is not polymorphic, but the function it points at is. 3517 2910 \begin{lstlisting} 3518 2911 int (*fvpfi( void ))( int ) { … … 3523 2916 } 3524 2917 \end{lstlisting} 3525 \lstinline$fvpfi()$ and \lstinline$fvpfT()$ are functions taking no arguments and returning pointers 3526 to functions. \lstinline$fvpfT()$ is monomorphic, but the function that its return value points 3527 at is polymorphic. 2918 \lstinline$fvpfi()$ and \lstinline$fvpfT()$ are functions taking no arguments and returning pointers to functions. \lstinline$fvpfT()$ is monomorphic, but the function that its return value points at is polymorphic. 3528 2919 \begin{lstlisting} 3529 2920 forall( type T ) int ( *fTpfi( T ) )( int ); … … 3531 2922 forall( type T, type U ) U ( *fTpfU( T ) )( U ); 3532 2923 \end{lstlisting} 3533 \lstinline$fTpfi()$ is a polymorphic function that returns a pointer to a monomorphic function 3534 taking an integer and returning an integer. It could return \lstinline$pfi$. \lstinline$fTpfT()$ 3535 is subtle: it is a polymorphic function returning a \emph{monomorphic} function taking and returning 3536 \lstinline$T$, where \lstinline$T$ is an inferred parameter of \lstinline$fTpfT()$. For instance, 3537 in the expression ``\lstinline$fTpfT(17)$'', \lstinline$T$ is inferred to be \lstinline$int$, and 3538 the returned value would have type \lstinline$int ( * )( int )$. ``\lstinline$fTpfT(17)(13)$'' and 2924 \lstinline$fTpfi()$ is a polymorphic function that returns a pointer to a monomorphic function taking an integer and returning an integer. 2925 It could return \lstinline$pfi$. \lstinline$fTpfT()$ is subtle: it is a polymorphic function returning a \emph{monomorphic} function taking and returning 2926 \lstinline$T$, where \lstinline$T$ is an inferred parameter of \lstinline$fTpfT()$. 2927 For instance, in the expression ``\lstinline$fTpfT(17)$'', \lstinline$T$ is inferred to be \lstinline$int$, and the returned value would have type \lstinline$int ( * )( int )$. ``\lstinline$fTpfT(17)(13)$'' and 3539 2928 ``\lstinline$fTpfT("yes")("no")$'' are legal, but ``\lstinline$fTpfT(17)("no")$'' is illegal. 3540 \lstinline$fTpfU()$ is polymorphic ( in type \lstinline$T$), and returns a pointer to a function that 3541 is polymorphic ( in type \lstinline$U$). ``\lstinline$f5(17)("no")$'' is a legal expression of type 2929 \lstinline$fTpfU()$ is polymorphic ( in type \lstinline$T$), and returns a pointer to a function that is polymorphic ( in type \lstinline$U$). ``\lstinline$f5(17)("no")$'' is a legal expression of type 3542 2930 \lstinline$char *$. 3543 2931 \begin{lstlisting} … … 3545 2933 forall( type U, type V, type W ) U * g( V *, U, W * const ); 3546 2934 \end{lstlisting} 3547 The functions \lstinline$f()$ and \lstinline$g()$ have compatible types. Let \(f\) and \(g\) be 3548 their types; then \(f_1\) = \lstinline$T$, \(f_2\) = \lstinline$U$, \(f_3\) = \lstinline$V$, \(g_1\) 3549 = \lstinline$V$, \(g_2\) = \lstinline$U$, and \(g_3\) = \lstinline$W$. Replacing every \(f_i\) 3550 by \(g_i\) in \(f\) gives 2935 The functions \lstinline$f()$ and \lstinline$g()$ have compatible types. 2936 Let \(f\) and \(g\) be their types; 2937 then \(f_1\) = \lstinline$T$, \(f_2\) = \lstinline$U$, \(f_3\) = \lstinline$V$, \(g_1\) 2938 = \lstinline$V$, \(g_2\) = \lstinline$U$, and \(g_3\) = \lstinline$W$. 2939 Replacing every \(f_i\) by \(g_i\) in \(f\) gives 3551 2940 \begin{lstlisting} 3552 2941 forall( type V, type U, type W ) U * f( V *, U, W * const ); 3553 \end{lstlisting} 3554 which has a return type and parameter list that is compatible with \(g\). 3555 \begin{rationale} 3556 The word ``\lstinline$type$'' in a forall specifier is redundant at the moment, but I want to leave 3557 room for inferred parameters of ordinary types in case parameterized types get added one day. 2942 \end{lstlisting} which has a return type and parameter list that is compatible with \(g\). 2943 \begin{rationale} 2944 The word ``\lstinline$type$'' in a forall specifier is redundant at the moment, but I want to leave room for inferred parameters of ordinary types in case parameterized types get added one day. 3558 2945 3559 2946 Even without parameterized types, I might try to allow 3560 2947 \begin{lstlisting} 3561 2948 forall( int n ) int sum( int vector[n] ); 3562 \end{lstlisting} 3563 but C currently rewrites array parameters as pointer parameters, so the effects of such a change 3564 require more thought. 3565 \end{rationale} 3566 3567 \begin{rationale} 3568 A polymorphic declaration must do two things: it must introduce type parameters, and it must apply 3569 assertions to those types. Adding this to existing C declaration syntax and semantics was delicate, 3570 and not entirely successful. 3571 3572 C depends on declarationbeforeuse, so a forall specifier must introduce type names before they can 3573 be used in the declaration specifiers. This could be done by making the forall specifier part of 3574 the declaration specifiers, or by making it a new introductory clause of declarations. 3575 3576 Assertions are also part of polymorphic function types, because it must be clear which functions 3577 have access to the assertion parameters declared by the assertions. All attempts to put assertions 3578 inside an introductory clause produced complex semantics and confusing code. Building them into the 3579 declaration specifiers could be done by placing them in the function's parameter list, or in a 3580 forall specifier that is a declaration specifier. Assertions are also used with type parameters of 3581 specifications, and by type declarations. For consistency's sake it seems best to attach assertions 3582 to the type declarations in forall specifiers, which means that forall specifiers must be 3583 declaration specifiers. 2949 \end{lstlisting} but C currently rewrites array parameters as pointer parameters, so the effects of such a change require more thought. 2950 \end{rationale} 2951 2952 \begin{rationale} 2953 A polymorphic declaration must do two things: it must introduce type parameters, and it must apply assertions to those types. 2954 Adding this to existing C declaration syntax and semantics was delicate, and not entirely successful. 2955 2956 C depends on declarationbeforeuse, so a forall specifier must introduce type names before they can be used in the declaration specifiers. 2957 This could be done by making the forall specifier part of the declaration specifiers, or by making it a new introductory clause of declarations. 2958 2959 Assertions are also part of polymorphic function types, because it must be clear which functions have access to the assertion parameters declared by the assertions. 2960 All attempts to put assertions inside an introductory clause produced complex semantics and confusing code. 2961 Building them into the declaration specifiers could be done by placing them in the function's parameter list, or in a forall specifier that is a declaration specifier. 2962 Assertions are also used with type parameters of specifications, and by type declarations. 2963 For consistency's sake it seems best to attach assertions to the type declarations in forall specifiers, which means that forall specifiers must be declaration specifiers. 3584 2964 \end{rationale} 3585 2965 %HERE … … 3595 2975 3596 2976 \constraints 3597 \lstinline$restrict$\index{register@{\lstinline$restrict$}} Types other than type parameters and 3598 pointer types whose referenced type is an object type shall not be restrictqualified. 2977 \lstinline$restrict$\index{register@{\lstinline$restrict$}} Types other than type parameters and pointer types whose referenced type is an object type shall not be restrictqualified. 3599 2978 3600 2979 \semantics 3601 An object's type may be a restrictqualified type parameter. \lstinline$restrict$ does not 3602 establish any special semantics in that case. 3603 3604 \begin{rationale} 3605 \CFA loosens the constraint on the restrict qualifier so that restrictqualified pointers may be 3606 passed to polymorphic functions. 3607 \end{rationale} 3608 3609 \lstinline$lvalue$ may be used to qualify the return type of a function type. Let \lstinline$T$ be 3610 an unqualified version of a type; then the result of calling a function with return type 2980 An object's type may be a restrictqualified type parameter. \lstinline$restrict$ does not establish any special semantics in that case. 2981 2982 \begin{rationale} 2983 \CFA loosens the constraint on the restrict qualifier so that restrictqualified pointers may be passed to polymorphic functions. 2984 \end{rationale} 2985 2986 \lstinline$lvalue$ may be used to qualify the return type of a function type. 2987 Let \lstinline$T$ be an unqualified version of a type; 2988 then the result of calling a function with return type 3611 2989 \lstinline$lvalue T$ is a \Index{modifiable lvalue} of type \lstinline$T$. 3612 \lstinline$const$\use{const} and \lstinline$volatile$\use{volatile} qualifiers may also be added to 3613 indicate that the function result is a constant or volatile lvalue. 3614 \begin{rationale} 3615 The \lstinline$const$ and \lstinline$volatile$ qualifiers can only be sensibly used to qualify the 3616 return type of a function if the \lstinline$lvalue$ qualifier is also used. 3617 \end{rationale} 3618 3619 An {lvalue}qualified type may be used in a \Index{cast expression} if the operand is an lvalue; the 3620 result of the expression is an lvalue. 3621 3622 \begin{rationale} 3623 \lstinline$lvalue$ provides some of the functionality of {\CC}'s ``\lstinline$T&$'' ( reference to 3624 object of type \lstinline$T$) type. Reference types have four uses in {\CC}. 2990 \lstinline$const$\use{const} and \lstinline$volatile$\use{volatile} qualifiers may also be added to indicate that the function result is a constant or volatile lvalue. 2991 \begin{rationale} 2992 The \lstinline$const$ and \lstinline$volatile$ qualifiers can only be sensibly used to qualify the return type of a function if the \lstinline$lvalue$ qualifier is also used. 2993 \end{rationale} 2994 2995 An {lvalue}qualified type may be used in a \Index{cast expression} if the operand is an lvalue; 2996 the result of the expression is an lvalue. 2997 2998 \begin{rationale} 2999 \lstinline$lvalue$ provides some of the functionality of {\CC}'s ``\lstinline$T&$'' ( reference to object of type \lstinline$T$) type. 3000 Reference types have four uses in {\CC}. 3625 3001 \begin{itemize} 3626 3002 \item … … 3629 3005 3630 3006 \item 3631 A reference can be used to define an alias for a complicated lvalue expression, as a way of getting 3632 some of the functionality of the Pascal \lstinline$with$ statement. The following {\CC} code gives 3633 an example. 3007 A reference can be used to define an alias for a complicated lvalue expression, as a way of getting some of the functionality of the Pascal \lstinline$with$ statement. 3008 The following {\CC} code gives an example. 3634 3009 \begin{lstlisting} 3635 3010 { … … 3641 3016 3642 3017 \item 3643 A reference parameter can be used to allow a function to modify an argument without forcing the 3644 caller to pass the address of the argument. This is most useful for userdefined assignment 3645 operators. In {\CC}, plain assignment is done by a function called ``\lstinline$operator=$'', and 3646 the two expressions 3018 A reference parameter can be used to allow a function to modify an argument without forcing the caller to pass the address of the argument. 3019 This is most useful for userdefined assignment operators. 3020 In {\CC}, plain assignment is done by a function called ``\lstinline$operator=$'', and the two expressions 3647 3021 \begin{lstlisting} 3648 3022 a = b; 3649 3023 operator=( a, b ); 3650 \end{lstlisting} 3651 are equivalent. If \lstinline$a$ and \lstinline$b$ are of type \lstinline$T$, then the first 3652 parameter of \lstinline$operator=$ must have type ``\lstinline$T&$''.It cannot have type3024 \end{lstlisting} are equivalent. 3025 If \lstinline$a$ and \lstinline$b$ are of type \lstinline$T$, then the first parameter of \lstinline$operator=$ must have type ``\lstinline$T&$''. 3026 It cannot have type 3653 3027 \lstinline$T$, because then assignment couldn't alter the variable, and it can't have type 3654 3028 ``\lstinline$T *$'', because the assignment would have to be written ``\lstinline$&a = b;$''. 3655 3029 3656 In the case of userdefined operators, this could just as well be handled by using pointer types and 3657 by changing the rewrite rules so that ``\lstinline$a = b;$'' is equivalent to 3658 ``\lstinline$operator=(&( a), b )$''. Reference parameters of ``normal'' functions are Bad Things, 3659 because they remove a useful property of C function calls: an argument can only be modified by a 3660 function if it is preceded by ``\lstinline$&$''. 3030 In the case of userdefined operators, this could just as well be handled by using pointer types and by changing the rewrite rules so that ``\lstinline$a = b;$'' is equivalent to 3031 ``\lstinline$operator=(&( a), b )$''. 3032 Reference parameters of ``normal'' functions are Bad Things, because they remove a useful property of C function calls: an argument can only be modified by a function if it is preceded by ``\lstinline$&$''. 3661 3033 3662 3034 \item … … 3668 3040 void fiddle( const Thing & ); 3669 3041 \end{lstlisting} 3670 If the second form is used, then constructors and destructors are not invoked to create a temporary 3671 variable at the call site ( and it is bad style for the caller to make any assumptions about such 3672 things), and within \lstinline$fiddle$ the parameter is subject to the usual problems caused by 3673 aliases. The reference form might be chosen for efficiency's sake if \lstinline$Thing$s are too 3674 large or their constructors or destructors are too expensive. An implementation may switch between 3675 them without causing trouble for wellbehaved clients. This leaves the implementor to define ``too 3676 large'' and ``too expensive''. 3042 If the second form is used, then constructors and destructors are not invoked to create a temporary variable at the call site ( and it is bad style for the caller to make any assumptions about such things), and within \lstinline$fiddle$ the parameter is subject to the usual problems caused by aliases. 3043 The reference form might be chosen for efficiency's sake if \lstinline$Thing$s are too large or their constructors or destructors are too expensive. 3044 An implementation may switch between them without causing trouble for wellbehaved clients. 3045 This leaves the implementor to define ``too large'' and ``too expensive''. 3677 3046 3678 3047 I propose to push this job onto the compiler by allowing it to implement 3679 3048 \begin{lstlisting} 3680 3049 void fiddle( const volatile Thing ); 3681 \end{lstlisting} 3682 with callbyreference. Since it knows all about the size of \lstinline$Thing$s and the parameter 3683 passing mechanism, it should be able to come up with a better definition of ``too large'', and may 3684 be able to make a good guess at ``too expensive''. 3050 \end{lstlisting} with callbyreference. 3051 Since it knows all about the size of \lstinline$Thing$s and the parameter passing mechanism, it should be able to come up with a better definition of ``too large'', and may be able to make a good guess at ``too expensive''. 3685 3052 \end{itemize} 3686 3053 3687 In summary, since references are only really necessary for returning lvalues, I'll only provide 3688 lvalue functions. 3054 In summary, since references are only really necessary for returning lvalues, I'll only provide lvalue functions. 3689 3055 \end{rationale} 3690 3056 … … 3693 3059 \subsection{Initialization} 3694 3060 3695 An expression that is used as an \nonterm{initializer} is treated as being cast to the type of the 3696 object being initialized. An expression used in an \nonterm{initializerlist} is treated as being 3697 cast to the type of the aggregate member that it initializes. In either case the cast must have a 3698 single unambiguous \Index{interpretation}. 3061 An expression that is used as an \nonterm{initializer} is treated as being cast to the type of the object being initialized. 3062 An expression used in an \nonterm{initializerlist} is treated as being cast to the type of the aggregate member that it initializes. 3063 In either case the cast must have a single unambiguous \Index{interpretation}. 3699 3064 3700 3065 … … 3717 3082 \end{syntax} 3718 3083 \begin{rationale} 3719 The declarations allowed in a specification are much the same as those allowed in a structure, 3720 except that bit fields are not allowed, and \Index{incomplete type}s and function types are allowed. 3084 The declarations allowed in a specification are much the same as those allowed in a structure, except that bit fields are not allowed, and \Index{incomplete type}s and function types are allowed. 3721 3085 \end{rationale} 3722 3086 3723 3087 \semantics 3724 A \define{specification definition} defines a name for a \define{specification}: a parameterized 3725 collection of object and function declarations. 3088 A \define{specification definition} defines a name for a \define{specification}: a parameterized collection of object and function declarations. 3726 3089 3727 3090 The declarations in a specification consist of the declarations in the 3728 3091 \nonterm{specdeclarationlist} and declarations produced by any assertions in the 3729 \nonterm{specparameterlist}. If the collection contains two declarations that declare the same 3730 identifier and have compatible types, they are combined into one declaration with the composite type 3731 constructed from the two types. 3092 \nonterm{specparameterlist}. 3093 If the collection contains two declarations that declare the same identifier and have compatible types, they are combined into one declaration with the composite type constructed from the two types. 3732 3094 3733 3095 … … 3747 3109 3748 3110 \constraints 3749 The \nonterm{identifier} in an assertion that is not a \nonterm{specdeclaration} shall be the name 3750 of a specification. The \nonterm{typenamelist} shall contain one \nonterm{typename} argument for 3751 each \nonterm{typeparameter} in that specification's \nonterm{specparameterlist}. If the 3752 \nonterm{typeparameter} uses typeclass \lstinline$type$\use{type}, the argument shall be the type 3753 name of an \Index{object type}; if it uses \lstinline$dtype$, the argument shall be the type name of 3754 an object type or an \Index{incomplete type}; and if it uses \lstinline$ftype$, the argument shall 3755 be the type name of a \Index{function type}. 3111 The \nonterm{identifier} in an assertion that is not a \nonterm{specdeclaration} shall be the name of a specification. 3112 The \nonterm{typenamelist} shall contain one \nonterm{typename} argument for each \nonterm{typeparameter} in that specification's \nonterm{specparameterlist}. 3113 If the 3114 \nonterm{typeparameter} uses typeclass \lstinline$type$\use{type}, the argument shall be the type name of an \Index{object type}; 3115 if it uses \lstinline$dtype$, the argument shall be the type name of an object type or an \Index{incomplete type}; 3116 and if it uses \lstinline$ftype$, the argument shall be the type name of a \Index{function type}. 3756 3117 3757 3118 \semantics … … 3759 3120 \define{assertion parameters}. 3760 3121 3761 The assertion parameters produced by an assertion that applies the name of a specification to type 3762 arguments are found by taking the declarations specified in the specification and treating each of 3763 the specification's parameters as a synonym for the corresponding \nonterm{typename} argument. 3764 3765 The collection of assertion parameters produced by the \nonterm{assertionlist} are found by 3766 combining the declarations produced by each assertion. If the collection contains two declarations 3767 that declare the same identifier and have compatible types, they are combined into one declaration 3768 with the \Index{composite type} constructed from the two types. 3122 The assertion parameters produced by an assertion that applies the name of a specification to type arguments are found by taking the declarations specified in the specification and treating each of the specification's parameters as a synonym for the corresponding \nonterm{typename} argument. 3123 3124 The collection of assertion parameters produced by the \nonterm{assertionlist} are found by combining the declarations produced by each assertion. 3125 If the collection contains two declarations that declare the same identifier and have compatible types, they are combined into one declaration with the \Index{composite type} constructed from the two types. 3769 3126 3770 3127 \examples … … 3774 3131 return val + val; 3775 3132 } 3776 3777 3133 context summable( type T ) {@\impl{summable}@ 3778 3134 T ?+=?( T *, T );@\use{?+=?}@ … … 3788 3144 context sum_list( type List, type Element  summable( Element )  list_of( List, Element ) ) {}; 3789 3145 \end{lstlisting} 3790 \lstinline$sum_list$ contains seven declarations, which describe a list whose elements can be added 3791 up. The assertion ``\lstinline$sum_list( i_list, int )$''\use{sum_list} produces the assertion 3792 parameters 3146 \lstinline$sum_list$ contains seven declarations, which describe a list whose elements can be added up. 3147 The assertion ``\lstinline$sum_list( i_list, int )$''\use{sum_list} produces the assertion parameters 3793 3148 \begin{lstlisting} 3794 3149 int ?+=?( int *, int ); … … 3825 3180 3826 3181 \constraints 3827 If a type declaration has block scope, and the declared identifier has external or internal linkage, 3828 the declaration shall have no initializer for the identifier. 3182 If a type declaration has block scope, and the declared identifier has external or internal linkage, the declaration shall have no initializer for the identifier. 3829 3183 3830 3184 \semantics 3831 A \nonterm{typeparameter} or a \nonterm{typedeclarator} declares an identifier to be a \Index{type 3832 name} for a type incompatible with all other types. 3833 3834 An identifier declared by a \nonterm{typeparameter} has \Index{no linkage}. Identifiers declared 3835 with typeclass \lstinline$type$\use{type} are \Index{object type}s; those declared with typeclass 3836 \lstinline$dtype$\use{dtype} are \Index{incomplete type}s; and those declared with typeclass 3837 \lstinline$ftype$\use{ftype} are \Index{function type}s. The identifier has \Index{block scope} that 3838 terminates at the end of the \nonterm{specdeclarationlist} or polymorphic function that contains 3839 the \nonterm{typeparameter}. 3840 3841 A \nonterm{typedeclarator} with an \Index{initializer} is a \define{type definition}. The declared 3842 identifier is an \Index{incomplete type} within the initializer, and an \Index{object type} after 3843 the end of the initializer. The type in the initializer is called the \define{implementation 3844 type}. Within the scope of the declaration, \Index{implicit conversion}s can be performed between 3845 the defined type and the implementation type, and between pointers to the defined type and pointers 3846 to the implementation type. 3847 3848 A type declaration without an \Index{initializer} and without a \Index{storageclass specifier} or 3849 with storageclass specifier \lstinline$static$\use{static} defines an \Index{incomplete type}. If a 3850 \Index{translation unit} or \Index{block} contains one or more such declarations for an identifier, 3851 it must contain exactly one definition of the identifier ( but not in an enclosed block, which would 3852 define a new type known only within that block). 3185 A \nonterm{typeparameter} or a \nonterm{typedeclarator} declares an identifier to be a \Index{type name} for a type incompatible with all other types. 3186 3187 An identifier declared by a \nonterm{typeparameter} has \Index{no linkage}. 3188 Identifiers declared with typeclass \lstinline$type$\use{type} are \Index{object type}s; 3189 those declared with typeclass 3190 \lstinline$dtype$\use{dtype} are \Index{incomplete type}s; 3191 and those declared with typeclass 3192 \lstinline$ftype$\use{ftype} are \Index{function type}s. 3193 The identifier has \Index{block scope} that terminates at the end of the \nonterm{specdeclarationlist} or polymorphic function that contains the \nonterm{typeparameter}. 3194 3195 A \nonterm{typedeclarator} with an \Index{initializer} is a \define{type definition}. The declared identifier is an \Index{incomplete type} within the initializer, and an \Index{object type} after the end of the initializer. 3196 The type in the initializer is called the \define{implementation 3197 type}. 3198 Within the scope of the declaration, \Index{implicit conversion}s can be performed between the defined type and the implementation type, and between pointers to the defined type and pointers to the implementation type. 3199 3200 A type declaration without an \Index{initializer} and without a \Index{storageclass specifier} or with storageclass specifier \lstinline$static$\use{static} defines an \Index{incomplete type}. 3201 If a 3202 \Index{translation unit} or \Index{block} contains one or more such declarations for an identifier, it must contain exactly one definition of the identifier ( but not in an enclosed block, which would define a new type known only within that block). 3853 3203 \begin{rationale} 3854 3204 Incomplete type declarations allow compact mutuallyrecursive types. 3855 3205 \begin{lstlisting} 3856 type t1; // Incomplete type declaration.3206 type t1; // incomplete type declaration 3857 3207 type t2 = struct { t1 * p; ... }; 3858 3208 type t1 = struct { t2 * p; ... }; 3859 3209 \end{lstlisting} 3860 Without them, mutual recursion could be handled by declaring mutually recursive structures, then 3861 initializing the types to those structures. 3210 Without them, mutual recursion could be handled by declaring mutually recursive structures, then initializing the types to those structures. 3862 3211 \begin{lstlisting} 3863 3212 struct s1; … … 3865 3214 type t1 = struct s1 { struct s2 * p; ... }; 3866 3215 \end{lstlisting} 3867 This introduces extra names, and may force the programmer to cast between the types and their 3868 implementations. 3216 This introduces extra names, and may force the programmer to cast between the types and their implementations. 3869 3217 \end{rationale} 3870 3218 3871 3219 A type declaration without an initializer and with \Index{storageclass specifier} 3872 \lstinline$extern$\use{extern} is an \define{opaque type declaration}. Opaque types are3873 \Index{object type}s. An opaque type is not a \nonterm{constantexpression}; neither is a structure3874 or union that has a member whose type is not a \nonterm{constantexpression}. Every other 3875 \Index{object type} is a \nonterm{constantexpression}. Objects with static storage duration shall 3876 be declared with a type that is a \nonterm{constantexpression}. 3877 \ begin{rationale}3878 Type declarations can declare identifiers with external linkage, whereas typedef declarations 3879 declare identifiers that only exist within a translation unit. These opaque types can be used in 3880 declarations, but the implementation of the type is not visible.3881 3882 Static objects can not have opaque types because space for them would have to be allocated at 3883 program startup. This is a deficiency\index{deficiencies!static opaque objects}, but I don't want 3884 to deal with ``module initialization'' code just now.3885 \end{rationale} 3886 3887 An \Index{incomplete type} which is not a qualified version\index{qualified type} of a type is a 3888 value of \Index{typeclass} \lstinline$dtype$. An object type\index{object types} which is not a 3889 qualified version of a type is a value of typeclasses \lstinline$type$ and \lstinline$dtype$.A3220 \lstinline$extern$\use{extern} is an \define{opaque type declaration}. 3221 Opaque types are 3222 \Index{object type}s. 3223 An opaque type is not a \nonterm{constantexpression}; 3224 neither is a structure or union that has a member whose type is not a \nonterm{constantexpression}. Every other 3225 \Index{object type} is a \nonterm{constantexpression}. 3226 Objects with static storage duration shall be declared with a type that is a \nonterm{constantexpression}. 3227 \begin{rationale} 3228 Type declarations can declare identifiers with external linkage, whereas typedef declarations declare identifiers that only exist within a translation unit. 3229 These opaque types can be used in declarations, but the implementation of the type is not visible. 3230 3231 Static objects can not have opaque types because space for them would have to be allocated at program startup. 3232 This is a deficiency\index{deficiencies!static opaque objects}, but I don't want to deal with ``module initialization'' code just now. 3233 \end{rationale} 3234 3235 An \Index{incomplete type} which is not a qualified version\index{qualified type} of a type is a value of \Index{typeclass} \lstinline$dtype$. 3236 An object type\index{object types} which is not a qualified version of a type is a value of typeclasses \lstinline$type$ and \lstinline$dtype$. 3237 A 3890 3238 \Index{function type} is a value of typeclass \lstinline$ftype$. 3891 3239 \begin{rationale} 3892 Syntactically, a type value is a \nonterm{typename}, which is a declaration for an object which 3893 omits the identifier being declared. 3894 3895 Object types are precisely the types that can be instantiated. Type qualifiers are not included in 3896 type values because the compiler needs the information they provide at compile time to detect 3897 illegal statements or to produce efficient machine instructions. For instance, the code that a 3898 compiler must generate to manipulate an object that has volatilequalified type may be different 3899 from the code to manipulate an ordinary object. 3900 3901 Type qualifiers are a weak point of C's type system. Consider the standard library function 3902 \lstinline$strchr()$ which, given a string and a character, returns a pointer to the first 3903 occurrence of the character in the string. 3240 Syntactically, a type value is a \nonterm{typename}, which is a declaration for an object which omits the identifier being declared. 3241 3242 Object types are precisely the types that can be instantiated. 3243 Type qualifiers are not included in type values because the compiler needs the information they provide at compile time to detect illegal statements or to produce efficient machine instructions. 3244 For instance, the code that a compiler must generate to manipulate an object that has volatilequalified type may be different from the code to manipulate an ordinary object. 3245 3246 Type qualifiers are a weak point of C's type system. 3247 Consider the standard library function 3248 \lstinline$strchr()$ which, given a string and a character, returns a pointer to the first occurrence of the character in the string. 3904 3249 \begin{lstlisting} 3905 3250 char *strchr( const char *s, int c ) {@\impl{strchr}@ 3906 3251 char real_c = c; // done because c was declared as int. 3907 3252 for ( ; *s != real_c; s++ ) 3908 3253 if ( *s == '\0' ) return NULL; 3909 3254 return ( char * )s; 3910 3255 } 3911 3256 \end{lstlisting} 3912 The parameter \lstinline$s$ must be \lstinline$const char *$, because \lstinline$strchr()$ might be 3913 used to search a constant string, but the return type must be \lstinline$char *$, because the result 3914 might be used to modify a nonconstant string. Hence the body must perform a cast, and ( even worse) 3915 \lstinline$strchr()$ provides a typesafe way to attempt to modify constant strings. What is needed 3916 is some way to say that \lstinline$s$'s type might contain qualifiers, and the result type has 3917 exactly the same qualifiers. Polymorphic functions do not provide a fix for this 3918 deficiency\index{deficiencies!pointers to qualified types}, because type qualifiers are not part of 3919 type values. Instead, overloading can be used to define \lstinline$strchr()$ for each combination 3920 of qualifiers. 3921 \end{rationale} 3922 3923 \begin{rationale} 3924 Since \Index{incomplete type}s are not type values, they can not be used as the initializer in a 3925 type declaration, or as the type of a structure or union member. This prevents the declaration of 3926 types that contain each other. 3257 The parameter \lstinline$s$ must be \lstinline$const char *$, because \lstinline$strchr()$ might be used to search a constant string, but the return type must be \lstinline$char *$, because the result might be used to modify a nonconstant string. 3258 Hence the body must perform a cast, and ( even worse) 3259 \lstinline$strchr()$ provides a typesafe way to attempt to modify constant strings. 3260 What is needed is some way to say that \lstinline$s$'s type might contain qualifiers, and the result type has exactly the same qualifiers. 3261 Polymorphic functions do not provide a fix for this deficiency\index{deficiencies!pointers to qualified types}, because type qualifiers are not part of type values. 3262 Instead, overloading can be used to define \lstinline$strchr()$ for each combination of qualifiers. 3263 \end{rationale} 3264 3265 \begin{rationale} 3266 Since \Index{incomplete type}s are not type values, they can not be used as the initializer in a type declaration, or as the type of a structure or union member. 3267 This prevents the declaration of types that contain each other. 3927 3268 \begin{lstlisting} 3928 3269 type t1; 3929 type t2 = t1; // illegal: incomplete type t1 .3270 type t2 = t1; // illegal: incomplete type t1 3930 3271 type t1 = t2; 3931 3272 \end{lstlisting} 3932 3273 3933 The initializer in a filescope declaration must be a constant expression. This means type3934 declarations can not build on opaque types, which is a deficiency\index{deficiencies!nesting opaque3274 The initializer in a filescope declaration must be a constant expression. 3275 This means type declarations can not build on opaque types, which is a deficiency\index{deficiencies!nesting opaque 3935 3276 types}. 3936 3277 \begin{lstlisting} 3937 extern type Huge; // extendedprecision integer type .3278 extern type Huge; // extendedprecision integer type 3938 3279 type Rational = struct { 3939 3280 Huge numerator, denominator; // illegal … … 3944 3285 \end{lstlisting} 3945 3286 Without this restriction, \CFA might require ``module initialization'' code ( since 3946 \lstinline$Rational$ has external linkage, it must be created before any other translation unit 3947 instantiates it), and would force an ordering on the initialization of the translation unit that 3948 defines \lstinline$Huge$ and the translation that declares \lstinline$Rational$. 3949 3950 A benefit of the restriction is that it prevents the declaration in separate translation units of 3951 types that contain each other, which would be hard to prevent otherwise. 3287 \lstinline$Rational$ has external linkage, it must be created before any other translation unit instantiates it), and would force an ordering on the initialization of the translation unit that defines \lstinline$Huge$ and the translation that declares \lstinline$Rational$. 3288 3289 A benefit of the restriction is that it prevents the declaration in separate translation units of types that contain each other, which would be hard to prevent otherwise. 3952 3290 \begin{lstlisting} 3953 3291 // File a.c: … … 3962 3300 \begin{rationale} 3963 3301 Since a \nonterm{typedeclaration} is a \nonterm{declaration} and not a 3964 \nonterm{structdeclaration}, type declarations can not be structure members. The form of 3302 \nonterm{structdeclaration}, type declarations can not be structure members. 3303 The form of 3965 3304 \nonterm{typedeclaration} forbids arrays of, pointers to, and functions returning \lstinline$type$. 3966 Hence the syntax of \nonterm{typespecifier} does not have to be extended to allow typevalued 3967 expressions. It also sidesteps the problem of typevalued expressions producing different values 3968 in different declarations. 3969 3970 Since a type declaration is not a \nonterm{parameterdeclaration}, functions can not have explicit 3971 type parameters. This may be too restrictive, but it attempts to make compilation simpler. Recall 3972 that when traditional C scanners read in an identifier, they look it up in the symbol table to 3973 determine whether or not it is a typedef name, and return a ``type'' or ``identifier'' token 3974 depending on what they find. A type parameter would add a type name to the current scope. The 3975 scope manipulations involved in parsing the declaration of a function that takes function pointer 3976 parameters and returns a function pointer may just be too complicated. 3977 3978 Explicit type parameters don't seem to be very useful, anyway, because their scope would not include 3979 the return type of the function. Consider the following attempt to define a typesafe memory 3980 allocation function. 3305 Hence the syntax of \nonterm{typespecifier} does not have to be extended to allow typevalued expressions. 3306 It also sidesteps the problem of typevalued expressions producing different values in different declarations. 3307 3308 Since a type declaration is not a \nonterm{parameterdeclaration}, functions can not have explicit type parameters. 3309 This may be too restrictive, but it attempts to make compilation simpler. 3310 Recall that when traditional C scanners read in an identifier, they look it up in the symbol table to determine whether or not it is a typedef name, and return a ``type'' or ``identifier'' token depending on what they find. 3311 A type parameter would add a type name to the current scope. 3312 The scope manipulations involved in parsing the declaration of a function that takes function pointer parameters and returns a function pointer may just be too complicated. 3313 3314 Explicit type parameters don't seem to be very useful, anyway, because their scope would not include the return type of the function. 3315 Consider the following attempt to define a typesafe memory allocation function. 3981 3316 \begin{lstlisting} 3982 3317 #include <stdlib.h> 3983 3318 T * new( type T ) { return ( T * )malloc( sizeof( T) ); }; 3984 @\ldots@ 3985 int * ip = new( int ); 3986 \end{lstlisting} 3987 This looks sensible, but \CFA's declarationbeforeuse rules mean that ``\lstinline$T$'' in the 3988 function body refers to the parameter, but the ``\lstinline$T$'' in the return type refers to the 3989 meaning of \lstinline$T$ in the scope that contains \lstinline$new$; it could be undefined, or a 3990 type name, or a function or variable name. Nothing good can result from such a situation. 3319 @\ldots@ int * ip = new( int ); 3320 \end{lstlisting} 3321 This looks sensible, but \CFA's declarationbeforeuse rules mean that ``\lstinline$T$'' in the function body refers to the parameter, but the ``\lstinline$T$'' in the return type refers to the meaning of \lstinline$T$ in the scope that contains \lstinline$new$; 3322 it could be undefined, or a type name, or a function or variable name. 3323 Nothing good can result from such a situation. 3991 3324 \end{rationale} 3992 3325 … … 4003 3336 f2( v2 ); 4004 3337 \end{lstlisting} 4005 \lstinline$V1$ is passed by value, so \lstinline$f1()$'s assignment to \lstinline$a[0]$ does not 4006 modify v1. \lstinline$V2$ is converted to a pointer, so \lstinline$f2()$ modifies 4007 \lstinline$v2[0]$. 3338 \lstinline$V1$ is passed by value, so \lstinline$f1()$'s assignment to \lstinline$a[0]$ does not modify v1. \lstinline$V2$ is converted to a pointer, so \lstinline$f2()$ modifies \lstinline$v2[0]$. 4008 3339 4009 3340 A translation unit containing the declarations 4010 3341 \begin{lstlisting} 4011 extern type Complex;@\use{Complex}@ // opaque type declaration .3342 extern type Complex;@\use{Complex}@ // opaque type declaration 4012 3343 extern float abs( Complex );@\use{abs}@ 4013 \end{lstlisting} 4014 can contain declarations of complex numbers, which can be passed to \lstinline$abs$. Some other 4015 translation unit must implement \lstinline$Complex$ and \lstinline$abs$. That unit might contain 4016 the declarations 3344 \end{lstlisting} can contain declarations of complex numbers, which can be passed to \lstinline$abs$. 3345 Some other translation unit must implement \lstinline$Complex$ and \lstinline$abs$. 3346 That unit might contain the declarations 4017 3347 \begin{lstlisting} 4018 3348 type Complex = struct { float re, im; };@\impl{Complex}@ … … 4022 3352 } 4023 3353 \end{lstlisting} 4024 Note that \lstinline$c$ is implicitly converted to a \lstinline$struct$ so that its components can 4025 be retrieved. 3354 Note that \lstinline$c$ is implicitly converted to a \lstinline$struct$ so that its components can be retrieved. 4026 3355 4027 3356 \begin{lstlisting} … … 4034 3363 4035 3364 \begin{rationale} 4036 Within the scope of a type definition, an instance of the type can be viewed as having that type or 4037 as having the implementation type. In the \lstinline$Time_of_day$ example, the difference is 4038 important. Different languages have treated the distinction between the abstraction and the 4039 implementation in different ways. 3365 Within the scope of a type definition, an instance of the type can be viewed as having that type or as having the implementation type. 3366 In the \lstinline$Time_of_day$ example, the difference is important. 3367 Different languages have treated the distinction between the abstraction and the implementation in different ways. 4040 3368 \begin{itemize} 4041 3369 \item 4042 Inside a Clu cluster \cite{clu}, the declaration of an instance states which view applies. Two 4043 primitives called \lstinline$up$ and \lstinline$down$ can be used to convert between the views. 4044 \item 4045 The Simula class \cite{Simula87} is essentially a record type. Since the only operations on a 4046 record are member selection and assignment, which can not be overloaded, there is never any 4047 ambiguity as to whether the abstraction or the implementation view is being used. In {\CC} 4048 \cite{c++}, operations on class instances include assignment and ``\lstinline$&$'', which can be 4049 overloaded. A ``scope resolution'' operator can be used inside the class to specify whether the 4050 abstract or implementation version of the operation should be used. 4051 \item 4052 An Ada derived type definition \cite{ada} creates a new type from an old type, and also implicitly 4053 declares derived subprograms that correspond to the existing subprograms that use the old type as a 4054 parameter type or result type. The derived subprograms are clones of the existing subprograms with 4055 the old type replaced by the derived type. Literals and aggregates of the old type are also cloned. 3370 Inside a Clu cluster \cite{clu}, the declaration of an instance states which view applies. 3371 Two primitives called \lstinline$up$ and \lstinline$down$ can be used to convert between the views. 3372 \item 3373 The Simula class \cite{Simula87} is essentially a record type. 3374 Since the only operations on a record are member selection and assignment, which can not be overloaded, there is never any ambiguity as to whether the abstraction or the implementation view is being used. 3375 In {\CC} 3376 \cite{c++}, operations on class instances include assignment and ``\lstinline$&$'', which can be overloaded. 3377 A ``scope resolution'' operator can be used inside the class to specify whether the abstract or implementation version of the operation should be used. 3378 \item 3379 An Ada derived type definition \cite{ada} creates a new type from an old type, and also implicitly declares derived subprograms that correspond to the existing subprograms that use the old type as a parameter type or result type. 3380 The derived subprograms are clones of the existing subprograms with the old type replaced by the derived type. 3381 Literals and aggregates of the old type are also cloned. 4056 3382 In other words, the abstract view provides exactly the same operations as the implementation view. 4057 3383 This allows the abstract view to be used in all cases. 4058 3384 4059 The derived subprograms can be replaced by programmerspecified subprograms. This is an exception4060 to the normal scope rules, which forbid duplicate definitions of a subprogram in a scope. In this 4061 case, explicit conversions between the derived type and the old type can be used.3385 The derived subprograms can be replaced by programmerspecified subprograms. 3386 This is an exception to the normal scope rules, which forbid duplicate definitions of a subprogram in a scope. 3387 In this case, explicit conversions between the derived type and the old type can be used. 4062 3388 \end{itemize} 4063 \CFA's rules are like Clu's, except that implicit conversions and 4064 conversion costs allow it to do away with most uses of \lstinline$up$ and \lstinline$down$. 3389 \CFA's rules are like Clu's, except that implicit conversions and conversion costs allow it to do away with most uses of \lstinline$up$ and \lstinline$down$. 4065 3390 \end{rationale} 4066 3391 … … 4070 3395 A declaration\index{type declaration} of a type identifier \lstinline$T$ with typeclass 4071 3396 \lstinline$type$ implicitly declares a \define{default assignment} function 4072 \lstinline$T ?=?( T *, T )$\use{?=?}, with the same \Index{scope} and \Index{linkage} as the 4073 identifier \lstinline$T$. 4074 \begin{rationale} 4075 Assignment is central to C's imperative programming style, and every existing C object type has 4076 assignment defined for it ( except for array types, which are treated as pointer types for purposes 4077 of assignment). Without this rule, nearly every inferred type parameter would need an accompanying 4078 assignment assertion parameter. If a type parameter should not have an assignment operation, 4079 \lstinline$dtype$ should be used. If a type should not have assignment defined, the user can define 4080 an assignment function that causes a runtime error, or provide an external declaration but no 4081 definition and thus cause a linktime error. 4082 \end{rationale} 4083 4084 A definition\index{type definition} of a type identifier \lstinline$T$ with \Index{implementation 4085 type} \lstinline$I$ and typeclass \lstinline$type$ implicitly defines a default assignment 4086 function. A definition\index{type definition} of a type identifier \lstinline$T$ with implementation 4087 type \lstinline$I$ and an assertion list implicitly defines \define{default function}s and 4088 \define{default object}s as declared by the assertion declarations. The default objects and 4089 functions have the same \Index{scope} and \Index{linkage} as the identifier \lstinline$T$. Their 4090 values are determined as follows: 3397 \lstinline$T ?=?( T *, T )$\use{?=?}, with the same \Index{scope} and \Index{linkage} as the identifier \lstinline$T$. 3398 \begin{rationale} 3399 Assignment is central to C's imperative programming style, and every existing C object type has assignment defined for it ( except for array types, which are treated as pointer types for purposes of assignment). 3400 Without this rule, nearly every inferred type parameter would need an accompanying assignment assertion parameter. 3401 If a type parameter should not have an assignment operation, 3402 \lstinline$dtype$ should be used. 3403 If a type should not have assignment defined, the user can define an assignment function that causes a runtime error, or provide an external declaration but no definition and thus cause a linktime error. 3404 \end{rationale} 3405 3406 A definition\index{type definition} of a type identifier \lstinline$T$ with \Index{implementation type} \lstinline$I$ and typeclass \lstinline$type$ implicitly defines a default assignment function. 3407 A definition\index{type definition} of a type identifier \lstinline$T$ with implementation type \lstinline$I$ and an assertion list implicitly defines \define{default function}s and 3408 \define{default object}s as declared by the assertion declarations. 3409 The default objects and functions have the same \Index{scope} and \Index{linkage} as the identifier \lstinline$T$. 3410 Their values are determined as follows: 4091 3411 \begin{itemize} 4092 3412 \item 4093 If at the definition of \lstinline$T$ there is visible a declaration of an object with the same name 4094 as the default object, and if the type of that object with all occurrence of \lstinline$I$ replaced 4095 by \lstinline$T$ is compatible with the type of the default object, then the default object is 4096 initialized with that object. Otherwise the scope of the declaration of \lstinline$T$ must contain 4097 a definition of the default object. 3413 If at the definition of \lstinline$T$ there is visible a declaration of an object with the same name as the default object, and if the type of that object with all occurrence of \lstinline$I$ replaced by \lstinline$T$ is compatible with the type of the default object, then the default object is initialized with that object. 3414 Otherwise the scope of the declaration of \lstinline$T$ must contain a definition of the default object. 4098 3415 4099 3416 \item 4100 If at the definition of \lstinline$T$ there is visible a declaration of a function with the same 4101 name as the default function, and if the type of that function with all occurrence of \lstinline$I$ 4102 replaced by \lstinline$T$ is compatible with the type of the default function, then the default 4103 function calls that function after converting its arguments and returns the converted result. 4104 4105 Otherwise, if \lstinline$I$ contains exactly one anonymous member\index{anonymous member} such that 4106 at the definition of \lstinline$T$ there is visible a declaration of a function with the same name 4107 as the default function, and the type of that function with all occurrences of the anonymous 4108 member's type in its parameter list replaced by \lstinline$T$ is compatible with the type of the 4109 default function, then the default function calls that function after converting its arguments and 4110 returns the result. 4111 4112 Otherwise the scope of the declaration of \lstinline$T$ must contain a definition of the default 4113 function. 3417 If at the definition of \lstinline$T$ there is visible a declaration of a function with the same name as the default function, and if the type of that function with all occurrence of \lstinline$I$ replaced by \lstinline$T$ is compatible with the type of the default function, then the default function calls that function after converting its arguments and returns the converted result. 3418 3419 Otherwise, if \lstinline$I$ contains exactly one anonymous member\index{anonymous member} such that at the definition of \lstinline$T$ there is visible a declaration of a function with the same name as the default function, and the type of that function with all occurrences of the anonymous member's type in its parameter list replaced by \lstinline$T$ is compatible with the type of the default function, then the default function calls that function after converting its arguments and returns the result. 3420 3421 Otherwise the scope of the declaration of \lstinline$T$ must contain a definition of the default function. 4114 3422 \end{itemize} 4115 3423 \begin{rationale} 4116 Note that a pointer to a default function will not compare as equal to a pointer to the inherited 4117 function. 4118 \end{rationale} 4119 4120 A function or object with the same type and name as a default function or object that is declared 4121 within the scope of the definition of \lstinline$T$ replaces the default function or object. 3424 Note that a pointer to a default function will not compare as equal to a pointer to the inherited function. 3425 \end{rationale} 3426 3427 A function or object with the same type and name as a default function or object that is declared within the scope of the definition of \lstinline$T$ replaces the default function or object. 4122 3428 4123 3429 \examples … … 4125 3431 context s( type T ) { 4126 3432 T a, b; 4127 } 4128 struct impl { int left, right; } a = { 0, 0 }; 3433 } struct impl { int left, right; } a = { 0, 0 }; 4129 3434 type Pair  s( Pair ) = struct impl; 4130 3435 Pair b = { 1, 1 }; 4131 3436 \end{lstlisting} 4132 3437 The definition of \lstinline$Pair$ implicitly defines two objects \lstinline$a$ and \lstinline$b$. 4133 \lstinline$Pair a$ inherits its value from the \lstinline$struct impl a$. The definition of4134 \lstinline$Pair b$ is compulsory because there is no \lstinline$struct impl b$ to construct a value 4135 from.3438 \lstinline$Pair a$ inherits its value from the \lstinline$struct impl a$. 3439 The definition of 3440 \lstinline$Pair b$ is compulsory because there is no \lstinline$struct impl b$ to construct a value from. 4136 3441 \begin{lstlisting} 4137 3442 context ss( type T ) { … … 4152 3457 void munge( Doodad * ); 4153 3458 \end{lstlisting} 4154 The assignment function inherits \lstinline$struct doodad$'s assignment function because the types 4155 match when \lstinline$struct doodad$ is replaced by \lstinline$Doodad$ throughout. 3459 The assignment function inherits \lstinline$struct doodad$'s assignment function because the types match when \lstinline$struct doodad$ is replaced by \lstinline$Doodad$ throughout. 4156 3460 \lstinline$munge()$ inherits \lstinline$Whatsit$'s \lstinline$munge()$ because the types match when 4157 \lstinline$Whatsit$ is replaced by \lstinline$Doodad$ in the parameter list. \lstinline$clone()$ 4158 does \emph{not} inherit \lstinline$Whatsit$'s \lstinline$clone()$: replacement in the parameter 4159 list yields ``\lstinline$Whatsit clone( Doodad )$'', which is not compatible with 4160 \lstinline$Doodad$'s \lstinline$clone()$'s type. Hence the definition of 3461 \lstinline$Whatsit$ is replaced by \lstinline$Doodad$ in the parameter list. \lstinline$clone()$ does \emph{not} inherit \lstinline$Whatsit$'s \lstinline$clone()$: replacement in the parameter list yields ``\lstinline$Whatsit clone( Doodad )$'', which is not compatible with 3462 \lstinline$Doodad$'s \lstinline$clone()$'s type. 3463 Hence the definition of 4161 3464 ``\lstinline$Doodad clone( Doodad )$'' is necessary. 4162 3465 … … 4173 3476 4174 3477 \begin{rationale} 4175 The \emph{class} construct of objectoriented programming languages performs three independent 4176 functions. It \emph{encapsulates} a data structure; it defines a \emph{subtype} relationship, whereby 4177 i nstances of one class may be used in contexts that require instances of another; and it allows one4178 class to \emph{inherit} the implementation of another.4179 4180 In \CFA, encapsulation is provided by opaque types and the scope rules, and subtyping is provided 4181 by specifications and assertions.Inheritance is provided by default functions and objects.3478 The \emph{class} construct of objectoriented programming languages performs three independent functions. 3479 It \emph{encapsulates} a data structure; 3480 it defines a \emph{subtype} relationship, whereby instances of one class may be used in contexts that require instances of another; 3481 and it allows one class to \emph{inherit} the implementation of another. 3482 3483 In \CFA, encapsulation is provided by opaque types and the scope rules, and subtyping is provided by specifications and assertions. 3484 Inheritance is provided by default functions and objects. 4182 3485 \end{rationale} 4183 3486 … … 4190 3493 \end{syntax} 4191 3494 4192 Many statements contain expressions, which may have more than one interpretation. The following4193 sections describe how the \CFA translator selects an interpretation. In all cases the result of the 4194 selection shall be a single unambiguous \Index{interpretation}.3495 Many statements contain expressions, which may have more than one interpretation. 3496 The following sections describe how the \CFA translator selects an interpretation. 3497 In all cases the result of the selection shall be a single unambiguous \Index{interpretation}. 4195 3498 4196 3499 … … 4239 3542 switch ( E ) ... 4240 3543 choose ( E ) ... 4241 \end{lstlisting} 4242 may have more than one interpretation, but it shall have only one interpretation with an integral type. 3544 \end{lstlisting} may have more than one interpretation, but it shall have only one interpretation with an integral type. 4243 3545 An \Index{integer promotion} is performed on the expression if necessary. 4244 3546 The constant expressions in \lstinline$case$ statements with the switch are converted to the promoted type. … … 4284 3586 while ( E ) ... 4285 3587 do ... while ( E ); 4286 \end{lstlisting} 4287 is treated as ``\lstinline$( int )((E)!=0)$''. 3588 \end{lstlisting} is treated as ``\lstinline$( int )((E)!=0)$''. 4288 3589 4289 3590 The statement 4290 3591 \begin{lstlisting} 4291 3592 for ( a; b; c ) @\ldots@ 4292 \end{lstlisting} 4293 is treated as 3593 \end{lstlisting} is treated as 4294 3594 \begin{lstlisting} 4295 3595 for ( ( void )( a ); ( int )(( b )!=0); ( void )( c ) ) ... … … 4413 3713 4414 3714 The implementation shall define the macro names \lstinline$__LINE__$, \lstinline$__FILE__$, 4415 \lstinline$__DATE__$, and \lstinline$__TIME__$, as in the {\c11} standard. It shall not define the 4416 macro name \lstinline$__STDC__$. 4417 4418 In addition, the implementation shall define the macro name \lstinline$__CFORALL__$ to be the 4419 decimal constant 1. 3715 \lstinline$__DATE__$, and \lstinline$__TIME__$, as in the {\c11} standard. 3716 It shall not define the macro name \lstinline$__STDC__$. 3717 3718 In addition, the implementation shall define the macro name \lstinline$__CFORALL__$ to be the decimal constant 1. 4420 3719 4421 3720 … … 4427 3726 4428 3727 \section{C types} 4429 This section gives example specifications for some groups of types that are important in the C 4430 language, in terms of the predefined operations that can be applied to those types. 3728 This section gives example specifications for some groups of types that are important in the C language, in terms of the predefined operations that can be applied to those types. 4431 3729 4432 3730 4433 3731 \subsection{Scalar, arithmetic, and integral types} 4434 3732 4435 The pointer, integral, and floatingpoint types are all \define{scalar types}. All of these types4436 can be logically negated and compared. The assertion ``\lstinline$scalar( Complex )$'' should be read 4437 as ``type \lstinline$Complex$ is scalar''.3733 The pointer, integral, and floatingpoint types are all \define{scalar types}. 3734 All of these types can be logically negated and compared. 3735 The assertion ``\lstinline$scalar( Complex )$'' should be read as ``type \lstinline$Complex$ is scalar''. 4438 3736 \begin{lstlisting} 4439 3737 context scalar( type T ) {@\impl{scalar}@ … … 4443 3741 \end{lstlisting} 4444 3742 4445 The integral and floatingpoint types are \define{arithmetic types}, which support the basic 4446 arithmetic operators. The use of an assertion in the \nonterm{specparameterlist} declares that, 4447 in order to be arithmetic, a type must also be scalar ( and hence that scalar operations are 4448 available ). This is equivalent to inheritance of specifications. 3743 The integral and floatingpoint types are \define{arithmetic types}, which support the basic arithmetic operators. 3744 The use of an assertion in the \nonterm{specparameterlist} declares that, in order to be arithmetic, a type must also be scalar ( and hence that scalar operations are available ). 3745 This is equivalent to inheritance of specifications. 4449 3746 \begin{lstlisting} 4450 3747 context arithmetic( type T  scalar( T ) ) {@\impl{arithmetic}@@\use{scalar}@ … … 4477 3774 4478 3775 Modifiable scalar lvalues are scalars and are modifiable lvalues, and assertions in the 4479 \nonterm{specparameterlist} reflect those relationships. This is equivalent to multiple 4480 inheritance of specifications. Scalars can also be incremented and decremented. 3776 \nonterm{specparameterlist} reflect those relationships. 3777 This is equivalent to multiple inheritance of specifications. 3778 Scalars can also be incremented and decremented. 4481 3779 \begin{lstlisting} 4482 3780 context m_l_scalar( type T  scalar( T )  m_lvalue( T ) ) {@\impl{m_l_scalar}@ … … 4486 3784 \end{lstlisting} 4487 3785 4488 Modifiable arithmetic lvalues are both modifiable scalar lvalues and arithmetic. Note that this4489 results in the ``inheritance'' of \lstinline$scalar$ along both paths.3786 Modifiable arithmetic lvalues are both modifiable scalar lvalues and arithmetic. 3787 Note that this results in the ``inheritance'' of \lstinline$scalar$ along both paths. 4490 3788 \begin{lstlisting} 4491 3789 context m_l_arithmetic( type T  m_l_scalar( T )  arithmetic( T ) ) {@\impl{m_l_arithmetic}@ … … 4493 3791 T ?+=?( T *, T ), ?=?( T *, T ); 4494 3792 }; 4495 4496 3793 context m_l_integral( type T  m_l_arithmetic( T )  integral( T ) ) {@\impl{m_l_integral}@ 4497 3794 T ?&=?( T *, T ), ?=?( T *, T ), ?^=?( T *, T );@\use{m_l_arithmetic}@ … … 4503 3800 \subsection{Pointer and array types} 4504 3801 4505 Array types can barely be said to exist in {\c11}, since in most cases an array name is treated as a 4506 constant pointer to the first element of the array, and the subscript expression 3802 Array types can barely be said to exist in {\c11}, since in most cases an array name is treated as a constant pointer to the first element of the array, and the subscript expression 4507 3803 ``\lstinline$a[i]$'' is equivalent to the dereferencing expression ``\lstinline$(*( a+( i )))$''. 4508 3804 Technically, pointer arithmetic and pointer comparisons other than ``\lstinline$==$'' and 4509 ``\lstinline$!=$'' are only defined for pointers to array elements, but the type system does not 4510 enforce those restrictions. Consequently, there is no need for a separate ``array type'' 4511 specification. 4512 4513 Pointer types are scalar types.Like other scalar types, they have ``\lstinline$+$'' and3805 ``\lstinline$!=$'' are only defined for pointers to array elements, but the type system does not enforce those restrictions. 3806 Consequently, there is no need for a separate ``array type'' specification. 3807 3808 Pointer types are scalar types. 3809 Like other scalar types, they have ``\lstinline$+$'' and 4514 3810 ``\lstinline$$'' operators, but the types do not match the types of the operations in 4515 3811 \lstinline$arithmetic$, so these operators cannot be consolidated in \lstinline$scalar$. … … 4519 3815 ptrdiff_t ??( P, P ); 4520 3816 }; 4521 4522 3817 context m_l_pointer( type P  pointer( P )  m_l_scalar( P ) ) {@\impl{m_l_pointer}@ 4523 3818 P ?+=?( P *, long int ), ?=?( P *, long int ); … … 4527 3822 \end{lstlisting} 4528 3823 4529 Specifications that define the dereference operator ( or subscript operator ) require two 4530 parameters, one for the pointer type and one for the pointedat ( or element ) type. Different 4531 specifications are needed for each set of \Index{type qualifier}s, because qualifiers are not 4532 included in types. The assertion ``\lstinline$ptr_to( Safe_pointer, int )$'' should be read as 3824 Specifications that define the dereference operator ( or subscript operator ) require two parameters, one for the pointer type and one for the pointedat ( or element ) type. 3825 Different specifications are needed for each set of \Index{type qualifier}s, because qualifiers are not included in types. 3826 The assertion ``\lstinline$ptr_to( Safe_pointer, int )$'' should be read as 4533 3827 ``\lstinline$Safe_pointer$ acts like a pointer to \lstinline$int$''. 4534 3828 \begin{lstlisting} 4535 3829 context ptr_to( type P  pointer( P ), type T ) {@\impl{ptr_to}@@\use{pointer}@ 4536 lvalue T *?( P ); lvalue T ?[?]( P, long int ); 3830 lvalue T *?( P ); 3831 lvalue T ?[?]( P, long int ); 4537 3832 }; 4538 4539 3833 context ptr_to_const( type P  pointer( P ), type T ) {@\impl{ptr_to_const}@ 4540 const lvalue T *?( P ); const lvalue T ?[?]( P, long int );@\use{pointer}@ 3834 const lvalue T *?( P ); 3835 const lvalue T ?[?]( P, long int );@\use{pointer}@ 4541 3836 }; 4542 4543 3837 context ptr_to_volatile( type P  pointer( P ), type T ) }@\impl{ptr_to_volatile}@ 4544 volatile lvalue T *?( P ); volatile lvalue T ?[?]( P, long int );@\use{pointer}@ 3838 volatile lvalue T *?( P ); 3839 volatile lvalue T ?[?]( P, long int );@\use{pointer}@ 4545 3840 }; 4546 \end{lstlisting}4547 \begin{lstlisting}4548 3841 context ptr_to_const_volatile( type P  pointer( P ), type T ) }@\impl{ptr_to_const_volatile}@ 4549 3842 const volatile lvalue T *?( P );@\use{pointer}@ … … 4552 3845 \end{lstlisting} 4553 3846 4554 Assignment to pointers is more complicated than is the case with other types, because the target's 4555 type can have extra type qualifiers in the pointedat type: a ``\lstinline$T *$'' can be assigned to 4556 a ``\lstinline$const T *$'', a ``\lstinline$volatile T *$'', and a ``\lstinline$const volatile T *$''. 3847 Assignment to pointers is more complicated than is the case with other types, because the target's type can have extra type qualifiers in the pointedat type: a ``\lstinline$T *$'' can be assigned to a ``\lstinline$const T *$'', a ``\lstinline$volatile T *$'', and a ``\lstinline$const volatile T *$''. 4557 3848 Again, the pointedat type is passed in, so that assertions can connect these specifications to the 4558 3849 ``\lstinline$ptr_to$'' specifications. … … 4562 3853 T * ?=?( T **, P ); 4563 3854 }; 4564 4565 3855 context m_l_ptr_to_const( type P  m_l_pointer( P ),@\use{m_l_pointer}@@\impl{m_l_ptr_to_const}@ type T  ptr_to_const( P, T )@\use{ptr_to_const}@) { 4566 3856 P ?=?( P *, const T * ); 4567 3857 const T * ?=?( const T **, P ); 4568 3858 }; 4569 4570 3859 context m_l_ptr_to_volatile( type P  m_l_pointer( P ),@\use{m_l_pointer}@@\impl{m_l_ptr_to_volatile}@ type T  ptr_to_volatile( P, T )) {@\use{ptr_to_volatile}@ 4571 3860 P ?=?( P *, volatile T * ); 4572 3861 volatile T * ?=?( volatile T **, P ); 4573 3862 }; 4574 4575 3863 context m_l_ptr_to_const_volatile( type P  ptr_to_const_volatile( P ),@\use{ptr_to_const_volatile}@@\impl{m_l_ptr_to_const_volatile}@ 4576 3864 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}@ … … 4580 3868 \end{lstlisting} 4581 3869 4582 Note the regular manner in which type qualifiers appear in those specifications. An alternative 4583 specification can make use of the fact that qualification of the pointedat type is part of a 4584 pointer type to capture that regularity. 3870 Note the regular manner in which type qualifiers appear in those specifications. 3871 An alternative specification can make use of the fact that qualification of the pointedat type is part of a pointer type to capture that regularity. 4585 3872 \begin{lstlisting} 4586 3873 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 ) ) { … … 4590 3877 \end{lstlisting} 4591 3878 The assertion ``\lstinline$ m_l_ptr_like( Safe_ptr, const int * )$'' should be read as 4592 ``\lstinline$Safe_ptr$ is a pointer type like \lstinline$const int *$''. This specification has two4593 defects, compared to the original four: there is no automatic assertion that dereferencing a3879 ``\lstinline$Safe_ptr$ is a pointer type like \lstinline$const int *$''. 3880 This specification has two defects, compared to the original four: there is no automatic assertion that dereferencing a 4594 3881 \lstinline$MyP$ produces an lvalue of the type that \lstinline$CP$ points at, and the 4595 ``\lstinline$m_l_pointer( CP )$'' assertion provides only a weak assurance that the argument passed 4596 to \lstinline$CP$ really is a pointer type. 3882 ``\lstinline$m_l_pointer( CP )$'' assertion provides only a weak assurance that the argument passed to \lstinline$CP$ really is a pointer type. 4597 3883 4598 3884 4599 3885 \section{Relationships between operations} 4600 3886 4601 Different operators often have related meanings; for instance, in C, ``\lstinline$+$'', 3887 Different operators often have related meanings; 3888 for instance, in C, ``\lstinline$+$'', 4602 3889 ``\lstinline$+=$'', and the two versions of ``\lstinline$++$'' perform variations of addition. 4603 Languages like {\CC} and Ada allow programmers to define operators for new types, but do not 4604 require that these relationships be preserved, or even that all of the operators be implemented. 4605 Completeness and consistency is left to the good taste and discretion of the programmer. It is 4606 possible to encourage these attributes by providing generic operator functions, or member functions 4607 of abstract classes, that are defined in terms of other, related operators. 4608 4609 In \CFA, polymorphic functions provide the equivalent of these generic operators, and 4610 specifications explicitly define the minimal implementation that a programmer should provide. This 4611 section shows a few examples. 3890 Languages like {\CC} and Ada allow programmers to define operators for new types, but do not require that these relationships be preserved, or even that all of the operators be implemented. 3891 Completeness and consistency is left to the good taste and discretion of the programmer. 3892 It is possible to encourage these attributes by providing generic operator functions, or member functions of abstract classes, that are defined in terms of other, related operators. 3893 3894 In \CFA, polymorphic functions provide the equivalent of these generic operators, and specifications explicitly define the minimal implementation that a programmer should provide. 3895 This section shows a few examples. 4612 3896 4613 3897 4614 3898 \subsection{Relational and equality operators} 4615 3899 4616 The different comparison operators have obvious relationships, but there is no obvious subset of the 4617 operations to use in the implementation of the others. However, it is usually convenient to 4618 implement a single comparison function that returns a negative integer, 0, or a positive integer if 4619 its first argument is respectively less than, equal to, or greater than its second argument; the 4620 library function \lstinline$strcmp$ is an example. 4621 4622 C and \CFA have an extra, nonobvious comparison operator: ``\lstinline$!$'', logical negation, 4623 returns 1 if its operand compares equal to 0, and 0 otherwise. 3900 The different comparison operators have obvious relationships, but there is no obvious subset of the operations to use in the implementation of the others. 3901 However, it is usually convenient to implement a single comparison function that returns a negative integer, 0, or a positive integer if its first argument is respectively less than, equal to, or greater than its second argument; 3902 the library function \lstinline$strcmp$ is an example. 3903 3904 C and \CFA have an extra, nonobvious comparison operator: ``\lstinline$!$'', logical negation, returns 1 if its operand compares equal to 0, and 0 otherwise. 4624 3905 \begin{lstlisting} 4625 3906 context comparable( type T ) { … … 4627 3908 int compare( T, T ); 4628 3909 } 4629 4630 3910 forall( type T  comparable( T ) ) int ?<?( T l, T r ) { 4631 3911 return compare( l, r ) < 0; 4632 3912 } 4633 3913 // ... similarly for <=, ==, >=, >, and !=. 4634 4635 3914 forall( type T  comparable( T ) ) int !?( T operand ) { 4636 3915 return !compare( operand, 0 ); … … 4641 3920 \subsection{Arithmetic and integer operations} 4642 3921 4643 A complete arithmetic type would provide the arithmetic operators and the corresponding assignment 4644 operators. Of these, the assignment operators are more likely to be implemented directly, because 4645 it is usually more efficient to alter the contents of an existing object than to create and return a 4646 new one. Similarly, a complete integral type would provide integral operations based on integral 4647 assignment operations. 3922 A complete arithmetic type would provide the arithmetic operators and the corresponding assignment operators. 3923 Of these, the assignment operators are more likely to be implemented directly, because it is usually more efficient to alter the contents of an existing object than to create and return a new one. 3924 Similarly, a complete integral type would provide integral operations based on integral assignment operations. 4648 3925 \begin{lstlisting} 4649 3926 context arith_base( type T ) { … … 4651 3928 T ?+=?( T *, T ), ?=?( T *, T ), ?*=?( T *, T ), ?/=?( T *, T ); 4652 3929 } 4653 4654 3930 forall( type T  arith_base( T ) ) T ?+?( T l, T r ) { 4655 3931 return l += r; 4656 3932 } 4657 4658 3933 forall( type T  arith_base( T ) ) T ?++( T * operand ) { 4659 3934 T temporary = *operand; … … 4661 3936 return temporary; 4662 3937 } 4663 4664 3938 forall( type T  arith_base( T ) ) T ++?( T * operand ) { 4665 3939 return *operand += 1; 4666 3940 } 4667 3941 // ... similarly for , , *, and /. 4668 4669 3942 context int_base( type T ) { 4670 3943 T ?&=?( T *, T ), ?=?( T *, T ), ?^=?( T *, T ); 4671 3944 T ?%=?( T *, T ), ?<<=?( T *, T ), ?>>=?( T *, T ); 4672 3945 } 4673 4674 3946 forall( type T  int_base( T ) ) T ?&?( T l, T r ) { 4675 3947 return l &= r; … … 4678 3950 \end{lstlisting} 4679 3951 4680 Note that, although an arithmetic type would certainly provide comparison functions, and an integral 4681 type would provide arithmetic operations, there does not have to be any relationship among 4682 \lstinline$int_base$, \lstinline$arith_base$ and \lstinline$comparable$. Note also that these 4683 declarations provide guidance and assistance, but they do not define an absolutely minimal set of 4684 requirements. A truly minimal implementation of an arithmetic type might only provide 3952 Note that, although an arithmetic type would certainly provide comparison functions, and an integral type would provide arithmetic operations, there does not have to be any relationship among 3953 \lstinline$int_base$, \lstinline$arith_base$ and \lstinline$comparable$. 3954 Note also that these declarations provide guidance and assistance, but they do not define an absolutely minimal set of requirements. 3955 A truly minimal implementation of an arithmetic type might only provide 4685 3956 \lstinline$0$, \lstinline$1$, and \lstinline$?=?$, which would be used by polymorphic 4686 3957 \lstinline$?+=?$, \lstinline$?*=?$, and \lstinline$?/=?$ functions. … … 4692 3963 Review index entries. 4693 3964 4694 Restrict allowed to qualify anything, or type/dtype parameters, but only affects pointers. This gets 4695 into \lstinline$noalias$ territory. Qualifying anything (``\lstinline$short restrict rs$'') means 4696 pointer parameters of \lstinline$?++$, etc, would need restrict qualifiers. 4697 4698 Enumerated types. Constants are not ints. Overloading. Definition should be ``representable as an 4699 integer type'', not ``as an int''. C11 usual conversions freely convert to and from ordinary 4700 integer types via assignment, which works between any integer types. Does enum Color ?*?( enum 3965 Restrict allowed to qualify anything, or type/dtype parameters, but only affects pointers. 3966 This gets into \lstinline$noalias$ territory. 3967 Qualifying anything (``\lstinline$short restrict rs$'') means pointer parameters of \lstinline$?++$, etc, would need restrict qualifiers. 3968 3969 Enumerated types. 3970 Constants are not ints. 3971 Overloading. 3972 Definition should be ``representable as an integer type'', not ``as an int''. 3973 C11 usual conversions freely convert to and from ordinary integer types via assignment, which works between any integer types. 3974 Does enum Color ?*?( enum 4701 3975 Color, enum Color ) really make sense? ?++ does, but it adds (int)1. 4702 3976 4703 Operators on {,signed,unsigned} char and other small types. ?<? harmless; ?*? questionable for 4704 chars. Generic selections make these choices visible. Safe conversion operators? Predefined 3977 Operators on {,signed,unsigned} char and other small types. ?<? harmless; 3978 ?*? questionable for chars. 3979 Generic selections make these choices visible. 3980 Safe conversion operators? Predefined 4705 3981 ``promotion'' function? 4706 3982 4707 \lstinline$register$ assignment might be handled as assignment to a temporary with copying back and 4708 forth, but copying must not be done by assignment. 3983 \lstinline$register$ assignment might be handled as assignment to a temporary with copying back and forth, but copying must not be done by assignment. 4709 3984 4710 3985 Don't use ptrdiff\_t by name in the predefineds. 4711 3986 4712 Polymorphic objects. Polymorphic typedefs and type declarations. 3987 Polymorphic objects. 3988 Polymorphic typedefs and type declarations. 4713 3989 4714 3990 … … 4719 3995 \addcontentsline{toc}{chapter}{\indexname} % add index name to table of contents 4720 3996 \begin{theindex} 4721 Italic page numbers give the location of the main entry for the referenced term. Plain page numbers 4722 denote uses of the indexed term. Entries for grammar nonterminals are italicized. A typewriter 4723 font is used for grammar terminals and program identifiers. 3997 Italic page numbers give the location of the main entry for the referenced term. 3998 Plain page numbers denote uses of the indexed term. 3999 Entries for grammar nonterminals are italicized. 4000 A typewriter font is used for grammar terminals and program identifiers. 4724 4001 \indexspace 4725 4002 \input{refrat.ind}
Note: See TracChangeset
for help on using the changeset viewer.