Context Navigation

-                      r88e0080
+                      r917ab04
 %% Created On       : Wed Apr  6 14:53:29 2016
 %% Last Modified By : Peter A. Buhr
 %% Last Modified On : Fri May 19 11:54:31 2017
 %% Update Count     : 1735
+%% Last Modified On : Sun May 21 23:16:45 2017
+%% Update Count     : 1817
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 …
 \author{
 \huge \CFA Team \medskip \\
 \Large Richard Bilson, Peter A. Buhr, Thierry Delisle, \smallskip \\
+\Large Andrew Beach, Richard Bilson, Peter A. Buhr, Thierry Delisle, \smallskip \\
 \Large Glen Ditchfield, Rodolfo G. Esteves, Aaron Moss, Rob Schluntz
 }% author
 …
 \end{quote2}
+Unsupported are K\&R C declarations where the base type defaults to ©int©, if no type is specified,\footnote{
+At least one type specifier shall be given in the declaration specifiers in each declaration, and in the specifier-qualifier list in each structure declaration and type name~\cite[\S~6.7.2(2)]{C11}}
+\eg:
+\begin{cfa}
+x;                                                              §\C{// int x}§
+*y;                                                             §\C{// int *y}§
+f( p1, p2 );                                    §\C{// int f( int p1, int p2 );}§
+f( p1, p2 ) {}                                  §\C{// int f( int p1, int p2 ) {}}§
+\end{cfa}
+The new declaration syntax can be used in other contexts where types are required, \eg casts and the pseudo-routine ©sizeof©:
+\begin{quote2}
+\begin{tabular}{@{}l@{\hspace{3em}}l@{}}
+\multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}}        & \multicolumn{1}{c}{\textbf{C}}        \\
+\begin{cfa}
+y = (®* int®)x;
+i = sizeof(®[ 5 ] * int®);
+\end{cfa}
+&
+\begin{cfa}
+y = (®int *®)x;
+i = sizeof(®int *[ 5 ]®);
+\end{cfa}
+\end{tabular}
+\end{quote2}
 Finally, new \CFA declarations may appear together with C declarations in the same program block, but cannot be mixed within a specific declaration.
 …
 > already.
 \end{comment}
-\section{Type Operators}
-The new declaration syntax can be used in other contexts where types are required, \eg casts and the pseudo-routine ©sizeof©:
-\begin{quote2}
-\begin{tabular}{@{}l@{\hspace{3em}}l@{}}
-\multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}}        & \multicolumn{1}{c}{\textbf{C}}        \\
-\begin{cfa}
-y = (®* int®)x;
-i = sizeof(®[ 5 ] * int®);
-\end{cfa}
+&
-\begin{cfa}
-y = (®int *®)x;
-i = sizeof(®int *[ 5 ]®);
-\end{cfa}
-\end{tabular}
-\end{quote2}
 …
+\section{Syntactic Anomalies}
+There are several ambiguous cases with operator identifiers, \eg ©int *?*?()©, where the string ©*?*?© can be lexed as ©*©~\R{/}~©?*?© or ©*?©~\R{/}~©*?©.
+Since it is common practise to put a unary operator juxtaposed to an identifier, \eg ©*i©, users will be annoyed if they cannot do this with respect to operator identifiers.
+Even with this special hack, there are 5 general cases that cannot be handled.
+The first case is for the function-call identifier ©?()©:
+\begin{cfa}
+int *§\textvisiblespace§?()();  // declaration: space required after '*'
+*§\textvisiblespace§?()();              // expression: space required after '*'
+\end{cfa}
+Without the space, the string ©*?()© is ambiguous without N character look ahead;
+it requires scanning ahead to determine if there is a ©'('©, which is the start of an argument/parameter list.
+The 4 remaining cases occur in expressions:
+\begin{cfa}
+i++§\textvisiblespace§?i:0;             // space required before '?'
+i--§\textvisiblespace§?i:0;             // space required before '?'
+i§\textvisiblespace§?++i:0;             // space required after '?'
+i§\textvisiblespace§?--i:0;             // space required after '?'
+\end{cfa}
+In the first two cases, the string ©i++?© is ambiguous, where this string can be lexed as ©i© / ©++?© or ©i++© / ©?©;
+it requires scanning ahead to determine if there is a ©'('©, which is the start of an argument list.
+In the second two cases, the string ©?++x© is ambiguous, where this string can be lexed as ©?++© / ©x© or ©?© / y©++x©;
+it requires scanning ahead to determine if there is a ©'('©, which is the start of an argument list.
+\section{Incompatible}
+The following incompatibles exist between \CFA and C, and are similar to Annex C for \CC~\cite{C++14}.
+\begin{enumerate}
+\item
+\begin{description}
+\item[Change:] add new keywords \\
+New keywords are added to \CFA (see~\VRef{s:NewKeywords}).
+\item[Rationale:] keywords added to implement new semantics of \CFA.
+\item[Effect on original feature:] change to semantics of well-defined feature. \\
+Any ISO C programs using these keywords as identifiers are invalid \CFA programs.
+\item[Difficulty of converting:] keyword clashes are accommodated by syntactic transformations using the \CFA backquote escape-mechanism (see~\VRef{s:BackquoteIdentifiers}):
+\item[How widely used:] clashes among new \CFA keywords and existing identifiers are rare.
+\end{description}
+\item
+\begin{description}
+\item[Change:] type of character literal ©int© to ©char© to allow more intuitive overloading:
+\begin{cfa}
+int rtn( int i );
+int rtn( char c );
+rtn( 'x' );                                             §\C{// programmer expects 2nd rtn to be called}§
+\end{cfa}
+\item[Rationale:] it is more intuitive for the call to ©rtn© to match the second version of definition of ©rtn© rather than the first.
+In particular, output of ©char© variable now print a character rather than the decimal ASCII value of the character.
+\begin{cfa}
+sout | 'x' | " " | (int)'x' | endl;
+x 120
+\end{cfa}
+Having to cast ©'x'© to ©char© is non-intuitive.
+\item[Effect on original feature:] change to semantics of well-defined feature that depend on:
+\begin{cfa}
+sizeof( 'x' ) == sizeof( int )
+\end{cfa}
+no long work the same in \CFA programs.
+\item[Difficulty of converting:] simple
+\item[How widely used:] programs that depend upon ©sizeof( 'x' )© are rare and can be changed to ©sizeof(char)©.
+\end{description}
+\item
+\begin{description}
+\item[Change:] make string literals ©const©:
+\begin{cfa}
+char * p = "abc";                               §\C{// valid in C, deprecated in \CFA}§
+char * q = expr ? "abc" : "de"; §\C{// valid in C, invalid in \CFA}§
+\end{cfa}
+The type of a string literal is changed from ©[] char© to ©const [] char©.
+Similarly, the type of a wide string literal is changed from ©[] wchar_t© to ©const [] wchar_t©.
+\item[Rationale:] This change is a safety issue:
+\begin{cfa}
+char * p = "abc";
+p[0] = 'w';                                             §\C{// segment fault or change constant literal}§
+\end{cfa}
+The same problem occurs when passing a string literal to a routine that changes its argument.
+\item[Effect on original feature:] change to semantics of well-defined feature.
+\item[Difficulty of converting:] simple syntactic transformation, because string literals can be converted to ©char *©.
+\item[How widely used:] programs that have a legitimate reason to treat string literals as pointers to potentially modifiable memory are rare.
+\end{description}
+\item
+\begin{description}
+\item[Change:] remove \newterm{tentative definitions}, which only occurs at file scope:
+\begin{cfa}
+int i;                                                  §\C{// forward definition}§
+int *j = ®&i®;                                  §\C{// forward reference, valid in C, invalid in \CFA}§
+int i = 0;                                              §\C{// definition}§
+\end{cfa}
+is valid in C, and invalid in \CFA because duplicate overloaded object definitions at the same scope level are disallowed.
+This change makes it impossible to define mutually referential file-local static objects, if initializers are restricted to the syntactic forms of C. For example,
+\begin{cfa}
+struct X { int i; struct X *next; };
+static struct X a;                              §\C{// forward definition}§
+static struct X b = { 0, ®&a® };        §\C{// forward reference, valid in C, invalid in \CFA}§
+static struct X a = { 1, &b };  §\C{// definition}§
+\end{cfa}
+\item[Rationale:] avoids having different initialization rules for builtin types and userdefined types.
+\item[Effect on original feature:] change to semantics of well-defined feature.
+\item[Difficulty of converting:] the initializer for one of a set of mutually-referential file-local static objects must invoke a routine call to achieve the initialization.
+\item[How widely used:] seldom
+\end{description}
+\item
+\begin{description}
+\item[Change:] have ©struct© introduce a scope for nested types:
+\begin{cfa}
+enum ®Colour® { R, G, B, Y, C, M };
+struct Person {
+        enum ®Colour® { R, G, B };      §\C{// nested type}§
+        struct Face {                           §\C{// nested type}§
+                ®Colour® Eyes, Hair;    §\C{// type defined outside (1 level)}§
+        };
+        ß.ß®Colour® shirt;                      §\C{// type defined outside (top level)}§
+        ®Colour® pants;                         §\C{// type defined same level}§
+        Face looks[10];                         §\C{// type defined same level}§
+};
+®Colour® c = R;                                 §\C{// type/enum defined same level}§
+Personß.ß®Colour® pc = Personß.ßR;      §\C{// type/enum defined inside}§
+Personß.ßFace pretty;                   §\C{// type defined inside}§
+\end{cfa}
+In C, the name of the nested types belongs to the same scope as the name of the outermost enclosing structure, \ie the nested types are hoisted to the scope of the outer-most type, which is not useful and confusing.
+\CFA is C \emph{incompatible} on this issue, and provides semantics similar to \Index*[C++]{\CC}.
+Nested types are not hoisted and can be referenced using the field selection operator ``©.©'', unlike the \CC scope-resolution operator ``©::©''.
+\item[Rationale:] ©struct© scope is crucial to \CFA as an information structuring and hiding mechanism.
+\item[Effect on original feature:] change to semantics of well-defined feature.
+\item[Difficulty of converting:] Semantic transformation.
+\item[How widely used:] C programs rarely have nest types because they are equivalent to the hoisted version.
+\end{description}
+\item
+\begin{description}
+\item[Change:] In C++, the name of a nested class is local to its enclosing class.
+\item[Rationale:] C++ classes have member functions which require that classes establish scopes.
+\item[Difficulty of converting:] Semantic transformation. To make the struct type name visible in the scope of the enclosing struct, the struct tag could be declared in the scope of the enclosing struct, before the enclosing struct is defined. Example:
+\begin{cfa}
+struct Y;                                               §\C{// struct Y and struct X are at the same scope}§
+struct X {
+struct Y { /* ... */ } y;
+};
+\end{cfa}
+All the definitions of C struct types enclosed in other struct definitions and accessed outside the scope of the enclosing struct could be exported to the scope of the enclosing struct.
+Note: this is a consequence of the difference in scope rules, which is documented in 3.3.
+\item[How widely used:] Seldom.
+\end{description}
+\item
+\begin{description}
+\item[Change:] comma expression is disallowed as subscript
+\item[Rationale:] safety issue to prevent subscripting error for multidimensional arrays: ©x[i,j]© instead of ©x[i][j]©, and this syntactic form then taken by \CFA for new style arrays.
+\item[Effect on original feature:] change to semantics of well-defined feature.
+\item[Difficulty of converting:] semantic transformation of ©x[i,j]© to ©x[(i,j)]©
+\item[How widely used:] seldom.
+\end{description}
+\end{enumerate}
+\section{Syntax Ambiguities}
+C has a number of syntax ambiguities, which are resolved by taking the longest sequence of overlapping characters that constitute a token.
+For example, the program fragment ©x+++++y© is parsed as \lstinline[showspaces=true]@x ++ ++ + y@ because operator tokens ©++© and ©+© overlap.
+Unfortunately, the longest sequence violates a constraint on increment operators, even though the parse \lstinline[showspaces=true]@x ++ + ++ y@ might yield a correct expression.
+Hence, C programmers are aware that spaces have to added to disambiguate certain syntactic cases.
+In \CFA, there are ambiguous cases with dereference and operator identifiers, \eg ©int *?*?()©, where the string ©*?*?© can be interpreted as:
+\begin{cfa}
+*?§\color{red}\textvisiblespace§*?
+*§\color{red}\textvisiblespace§?*?
+\end{cfa}
+By default, the first interpretation is selected, which does not yield a meaningful string in the language.
+Therefore, \CFA does a lexical look-ahead for the second case, and backtracks to return the leading unary operator and reparses the trailing operator identifier.
+Otherwise a space is needed between the unary operator and operator identifier to disambiguate this common case.
+A similar issue occurs with the dereference, ©*?(...)©, and routine-call, ©?()(...)© identifiers.
+The ambiguity occurs when the deference operator has no parameters:
+\begin{cfa}
+*?()§\color{red}\textvisiblespace...§ ;
+*?()§\color{red}\textvisiblespace...§(...) ;
+\end{cfa}
+requiring arbitrary whitespace look-ahead for the routine-call parameter list to disambiguate.
+However, the dereference operator \emph{must} have a parameter/argument to dereference ©*?(...)©.
+Hence, always interpreting the string ©*?()© as \lstinline[showspaces=true]@* ?()@ does not preclude any meaningful program.
+The remaining cases are with the increment/decrement operators and conditional expression, \eg:
+\begin{cfa}
+i++?§\color{red}\textvisiblespace...§(...);
+i?++§\color{red}\textvisiblespace...§(...);
+\end{cfa}
+requiring arbitrary whitespace look-ahead for the routine-call parameter list, even though that interpretation is an incorrect expression (juxtaposed identifiers).
+Therefore, it is necessary to disambiguate these cases with a space:
+\begin{cfa}
+i++§\color{red}\textvisiblespace§? i : 0;
+i?§\color{red}\textvisiblespace§++i : 0;
+\end{cfa}
 …
 \begin{quote2}
 \begin{tabular}{lll}
+\begin{tabular}{llll}
 \begin{tabular}{@{}l@{}}
 ©_AT©                   \\
 …
 ©coroutine©             \\
 ©disable©               \\
-©dtype©                 \\
-©enable©                \\
 \end{tabular}
+&
 \begin{tabular}{@{}l@{}}
+©dtype©                 \\
+©enable©                \\
 ©fallthrough©   \\
 ©fallthru©              \\
 ©finally©               \\
 ©forall©                \\
+\end{tabular}
+&
+\begin{tabular}{@{}l@{}}
 ©ftype©                 \\
 ©lvalue©                \\
 ©monitor©               \\
 ©mutex©                 \\
+©one_t©                 \\
+©otype©                 \\
 \end{tabular}
+&
 \begin{tabular}{@{}l@{}}
-©one_t©                 \\
-©otype©                 \\
 ©throw©                 \\
 ©throwResume©   \\
 …
 \end{tabular}
 \end{quote2}
+\section{Incompatible}
+The following incompatibles exist between \CFA and C, and are similar to Annex C for \CC~\cite{C++14}.
+\begin{enumerate}
+\item
+\begin{description}
+\item[Change:] add new keywords \\
+New keywords are added to \CFA (see~\VRef{s:CFAKeywords}).
+\item[Rationale:] keywords added to implement new semantics of \CFA.
+\item[Effect on original feature:] change to semantics of well-defined feature. \\
+Any ISO C programs using these keywords as identifiers are invalid \CFA programs.
+\item[Difficulty of converting:] keyword clashes are accommodated by syntactic transformations using the \CFA backquote escape-mechanism (see~\VRef{s:BackquoteIdentifiers}).
+\item[How widely used:] clashes among new \CFA keywords and existing identifiers are rare.
+\end{description}
+\item
+\begin{description}
+\item[Change:] drop K\&R C declarations \\
+K\&R declarations allow an implicit base-type of ©int©, if no type is specified, plus an alternate syntax for declaring parameters.
+\eg:
+\begin{cfa}
+x;                                                              §\C{// int x}§
+*y;                                                             §\C{// int *y}§
+f( p1, p2 );                                    §\C{// int f( int p1, int p2 );}§
+g( p1, p2 ) int p1, p2;                 §\C{// int g( int p1, int p2 );}§
+\end{cfa}
+\CFA supports K\&R routine definitions:
+\begin{cfa}
+f( a, b, c )                                    §\C{// default int return}§
+        int a, b; char c                        §\C{// K\&R parameter declarations}§
+{
+        ...
+}
+\end{cfa}
+\item[Rationale:] dropped from C11 standard.\footnote{
+At least one type specifier shall be given in the declaration specifiers in each declaration, and in the specifier-qualifier list in each structure declaration and type name~\cite[\S~6.7.2(2)]{C11}}
+\item[Effect on original feature:] original feature is deprecated. \\
+Any old C programs using these K\&R declarations are invalid \CFA programs.
+\item[Difficulty of converting:] trivial to convert to \CFA.
+\item[How widely used:] existing usages are rare.
+\end{description}
+\item
+\begin{description}
+\item[Change:] type of character literal ©int© to ©char© to allow more intuitive overloading:
+\begin{cfa}
+int rtn( int i );
+int rtn( char c );
+rtn( 'x' );                                             §\C{// programmer expects 2nd rtn to be called}§
+\end{cfa}
+\item[Rationale:] it is more intuitive for the call to ©rtn© to match the second version of definition of ©rtn© rather than the first.
+In particular, output of ©char© variable now print a character rather than the decimal ASCII value of the character.
+\begin{cfa}
+sout | 'x' | " " | (int)'x' | endl;
+x 120
+\end{cfa}
+Having to cast ©'x'© to ©char© is non-intuitive.
+\item[Effect on original feature:] change to semantics of well-defined feature that depend on:
+\begin{cfa}
+sizeof( 'x' ) == sizeof( int )
+\end{cfa}
+no long work the same in \CFA programs.
+\item[Difficulty of converting:] simple
+\item[How widely used:] programs that depend upon ©sizeof( 'x' )© are rare and can be changed to ©sizeof(char)©.
+\end{description}
+\item
+\begin{description}
+\item[Change:] make string literals ©const©:
+\begin{cfa}
+char * p = "abc";                               §\C{// valid in C, deprecated in \CFA}§
+char * q = expr ? "abc" : "de"; §\C{// valid in C, invalid in \CFA}§
+\end{cfa}
+The type of a string literal is changed from ©[] char© to ©const [] char©.
+Similarly, the type of a wide string literal is changed from ©[] wchar_t© to ©const [] wchar_t©.
+\item[Rationale:] This change is a safety issue:
+\begin{cfa}
+char * p = "abc";
+p[0] = 'w';                                             §\C{// segment fault or change constant literal}§
+\end{cfa}
+The same problem occurs when passing a string literal to a routine that changes its argument.
+\item[Effect on original feature:] change to semantics of well-defined feature.
+\item[Difficulty of converting:] simple syntactic transformation, because string literals can be converted to ©char *©.
+\item[How widely used:] programs that have a legitimate reason to treat string literals as pointers to potentially modifiable memory are rare.
+\end{description}
+\item
+\begin{description}
+\item[Change:] remove \newterm{tentative definitions}, which only occurs at file scope:
+\begin{cfa}
+int i;                                                  §\C{// forward definition}§
+int *j = ®&i®;                                  §\C{// forward reference, valid in C, invalid in \CFA}§
+int i = 0;                                              §\C{// definition}§
+\end{cfa}
+is valid in C, and invalid in \CFA because duplicate overloaded object definitions at the same scope level are disallowed.
+This change makes it impossible to define mutually referential file-local static objects, if initializers are restricted to the syntactic forms of C. For example,
+\begin{cfa}
+struct X { int i; struct X *next; };
+static struct X a;                              §\C{// forward definition}§
+static struct X b = { 0, ®&a® };        §\C{// forward reference, valid in C, invalid in \CFA}§
+static struct X a = { 1, &b };  §\C{// definition}§
+\end{cfa}
+\item[Rationale:] avoids having different initialization rules for builtin types and userdefined types.
+\item[Effect on original feature:] change to semantics of well-defined feature.
+\item[Difficulty of converting:] the initializer for one of a set of mutually-referential file-local static objects must invoke a routine call to achieve the initialization.
+\item[How widely used:] seldom
+\end{description}
+\item
+\begin{description}
+\item[Change:] have ©struct© introduce a scope for nested types:
+\begin{cfa}
+enum ®Colour® { R, G, B, Y, C, M };
+struct Person {
+        enum ®Colour® { R, G, B };      §\C{// nested type}§
+        struct Face {                           §\C{// nested type}§
+                ®Colour® Eyes, Hair;    §\C{// type defined outside (1 level)}§
+        };
+        ®.Colour® shirt;                        §\C{// type defined outside (top level)}§
+        ®Colour® pants;                         §\C{// type defined same level}§
+        Face looks[10];                         §\C{// type defined same level}§
+};
+®Colour® c = R;                                 §\C{// type/enum defined same level}§
+Person®.Colour® pc = Person®.®R;        §\C{// type/enum defined inside}§
+Person®.®Face pretty;                   §\C{// type defined inside}§
+\end{cfa}
+In C, the name of the nested types belongs to the same scope as the name of the outermost enclosing structure, \ie the nested types are hoisted to the scope of the outer-most type, which is not useful and confusing.
+\CFA is C \emph{incompatible} on this issue, and provides semantics similar to \Index*[C++]{\CC}.
+Nested types are not hoisted and can be referenced using the field selection operator ``©.©'', unlike the \CC scope-resolution operator ``©::©''.
+\item[Rationale:] ©struct© scope is crucial to \CFA as an information structuring and hiding mechanism.
+\item[Effect on original feature:] change to semantics of well-defined feature.
+\item[Difficulty of converting:] Semantic transformation.
+\item[How widely used:] C programs rarely have nest types because they are equivalent to the hoisted version.
+\end{description}
+\item
+\begin{description}
+\item[Change:] In C++, the name of a nested class is local to its enclosing class.
+\item[Rationale:] C++ classes have member functions which require that classes establish scopes.
+\item[Difficulty of converting:] Semantic transformation. To make the struct type name visible in the scope of the enclosing struct, the struct tag could be declared in the scope of the enclosing struct, before the enclosing struct is defined. Example:
+\begin{cfa}
+struct Y;                                               §\C{// struct Y and struct X are at the same scope}§
+struct X {
+struct Y { /* ... */ } y;
+};
+\end{cfa}
+All the definitions of C struct types enclosed in other struct definitions and accessed outside the scope of the enclosing struct could be exported to the scope of the enclosing struct.
+Note: this is a consequence of the difference in scope rules, which is documented in 3.3.
+\item[How widely used:] Seldom.
+\end{description}
+\item
+\begin{description}
+\item[Change:] comma expression is disallowed as subscript
+\item[Rationale:] safety issue to prevent subscripting error for multidimensional arrays: ©x[i,j]© instead of ©x[i][j]©, and this syntactic form then taken by \CFA for new style arrays.
+\item[Effect on original feature:] change to semantics of well-defined feature.
+\item[Difficulty of converting:] semantic transformation of ©x[i,j]© to ©x[(i,j)]©
+\item[How widely used:] seldom.
+\end{description}
+\end{enumerate}
 …
 \leavevmode
 \begin{cfa}[aboveskip=0pt,belowskip=0pt]
 forall( otype T ) T * malloc( void );§\indexc{malloc}§
 forall( otype T ) T * malloc( char fill );
 forall( otype T ) T * malloc( T * ptr, size_t size );
 forall( otype T ) T * malloc( T * ptr, size_t size, unsigned char fill );
 forall( otype T ) T * calloc( size_t nmemb );§\indexc{calloc}§
 forall( otype T ) T * realloc( T * ptr, size_t size );§\indexc{ato}§
 forall( otype T ) T * realloc( T * ptr, size_t size, unsigned char fill );
 forall( otype T ) T * aligned_alloc( size_t alignment );§\indexc{ato}§
 forall( otype T ) T * memalign( size_t alignment );             // deprecated
 forall( otype T ) int posix_memalign( T ** ptr, size_t alignment );
+forall( dtype T | sized(T) ) T * malloc( void );§\indexc{malloc}§
+forall( dtype T | sized(T) ) T * malloc( char fill );
+forall( dtype T | sized(T) ) T * malloc( T * ptr, size_t size );
+forall( dtype T | sized(T) ) T * malloc( T * ptr, size_t size, unsigned char fill );
+forall( dtype T | sized(T) ) T * calloc( size_t nmemb );§\indexc{calloc}§
+forall( dtype T | sized(T) ) T * realloc( T * ptr, size_t size );§\indexc{ato}§
+forall( dtype T | sized(T) ) T * realloc( T * ptr, size_t size, unsigned char fill );
+forall( dtype T | sized(T) ) T * aligned_alloc( size_t alignment );§\indexc{ato}§
+forall( dtype T | sized(T) ) T * memalign( size_t alignment );          // deprecated
+forall( dtype T | sized(T) ) int posix_memalign( T ** ptr, size_t alignment );
 forall( otype T ) T * memset( T * ptr, unsigned char fill ); // use default value '\0' for fill
 forall( otype T ) T * memset( T * ptr );                                // remove when default value available
+forall( dtype T, ttype Params | sized(T) | { void ?{}(T *, Params); } ) T * new( Params p );
+forall( dtype T | { void ^?{}(T *); } ) void delete( T * ptr );
+forall( dtype T, ttype Params | { void ^?{}(T *); void delete(Params); } ) void delete( T * ptr, Params rest );
 \end{cfa}

Note: See TracChangeset for help on using the changeset viewer.

Context Navigation

Changeset 917ab04 for doc

Legend:

doc/user/user.tex

Download in other formats: