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