Changeset 13099105


Ignore:
Timestamp:
May 23, 2017, 12:20:38 PM (7 years ago)
Author:
Thierry Delisle <tdelisle@…>
Branches:
ADT, aaron-thesis, arm-eh, ast-experimental, cleanup-dtors, deferred_resn, demangler, enum, forall-pointer-decay, jacob/cs343-translation, jenkins-sandbox, master, new-ast, new-ast-unique-expr, new-env, no_list, persistent-indexer, pthread-emulation, qualifiedEnum, resolv-new, with_gc
Children:
8bcaf21
Parents:
2c9ebab (diff), 935315d (diff)
Note: this is a merge changeset, the changes displayed below correspond to the merge itself.
Use the (diff) links above to see all the changes relative to each parent.
Message:

Merge branch 'master' of plg.uwaterloo.ca:software/cfa/cfa-cc

Files:
1 added
6 edited
6 moved

Legend:

Unmodified
Added
Removed

  • doc/user/user.tex

    r2c9ebab r13099105  
    1111%% Created On       : Wed Apr  6 14:53:29 2016
    1212%% Last Modified By : Peter A. Buhr
    13 %% Last Modified On : Fri May 19 11:54:31 2017
    14 %% Update Count     : 1735
     13%% Last Modified On : Sun May 21 23:36:42 2017
     14%% Update Count     : 1822
    1515%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
    1616
    … …  
    9494\author{
    9595\huge \CFA Team \medskip \\
    96 \Large Richard Bilson, Peter A. Buhr, Thierry Delisle, \smallskip \\
     96\Large Andrew Beach, Richard Bilson, Peter A. Buhr, Thierry Delisle, \smallskip \\
    9797\Large Glen Ditchfield, Rodolfo G. Esteves, Aaron Moss, Rob Schluntz
    9898}% author
    … …  
    644644\end{quote2}
    645645
    646 Unsupported are K\&R C declarations where the base type defaults to ©int©, if no type is specified,\footnote{
    647 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}}
    648 \eg:
    649 \begin{cfa}
    650 x;                                                              §\C{// int x}§
    651 *y;                                                             §\C{// int *y}§
    652 f( p1, p2 );                                    §\C{// int f( int p1, int p2 );}§
    653 f( p1, p2 ) {}                                  §\C{// int f( int p1, int p2 ) {}}§
    654 \end{cfa}
     646The new declaration syntax can be used in other contexts where types are required, \eg casts and the pseudo-routine ©sizeof©:
     647\begin{quote2}
     648\begin{tabular}{@{}l@{\hspace{3em}}l@{}}
     649\multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}}        & \multicolumn{1}{c}{\textbf{C}}        \\
     650\begin{cfa}
     651y = (®* int®)x;
     652i = sizeof(®[ 5 ] * int®);
     653\end{cfa}
     654&
     655\begin{cfa}
     656y = (®int *®)x;
     657i = sizeof(®int *[ 5 ]®);
     658\end{cfa}
     659\end{tabular}
     660\end{quote2}
    655661
    656662Finally, new \CFA declarations may appear together with C declarations in the same program block, but cannot be mixed within a specific declaration.
    … …  
    11051111> already.
    11061112\end{comment}
    1107 
    1108 
    1109 \section{Type Operators}
    1110 
    1111 The new declaration syntax can be used in other contexts where types are required, \eg casts and the pseudo-routine ©sizeof©:
    1112 \begin{quote2}
    1113 \begin{tabular}{@{}l@{\hspace{3em}}l@{}}
    1114 \multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}}        & \multicolumn{1}{c}{\textbf{C}}        \\
    1115 \begin{cfa}
    1116 y = (®* int®)x;
    1117 i = sizeof(®[ 5 ] * int®);
    1118 \end{cfa}
    1119 &
    1120 \begin{cfa}
    1121 y = (®int *®)x;
    1122 i = sizeof(®int *[ 5 ]®);
    1123 \end{cfa}
    1124 \end{tabular}
    1125 \end{quote2}
    11261113
    11271114
    … …  
    48424829
    48434830
    4844 \section{Syntactic Anomalies}
    4845 
    4846 There are several ambiguous cases with operator identifiers, \eg ©int *?*?()©, where the string ©*?*?© can be lexed as ©*©~\R{/}~©?*?© or ©*?©~\R{/}~©*?©.
    4847 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.
    4848 Even with this special hack, there are 5 general cases that cannot be handled.
    4849 The first case is for the function-call identifier ©?()©:
    4850 \begin{cfa}
    4851 int *§\textvisiblespace§?()();  // declaration: space required after '*'
    4852 *§\textvisiblespace§?()();              // expression: space required after '*'
    4853 \end{cfa}
    4854 Without the space, the string ©*?()© is ambiguous without N character look ahead;
    4855 it requires scanning ahead to determine if there is a ©'('©, which is the start of an argument/parameter list.
    4856 
    4857 The 4 remaining cases occur in expressions:
    4858 \begin{cfa}
    4859 i++§\textvisiblespace§?i:0;             // space required before '?'
    4860 i--§\textvisiblespace§?i:0;             // space required before '?'
    4861 i§\textvisiblespace§?++i:0;             // space required after '?'
    4862 i§\textvisiblespace§?--i:0;             // space required after '?'
    4863 \end{cfa}
    4864 In the first two cases, the string ©i++?© is ambiguous, where this string can be lexed as ©i© / ©++?© or ©i++© / ©?©;
    4865 it requires scanning ahead to determine if there is a ©'('©, which is the start of an argument list.
    4866 In the second two cases, the string ©?++x© is ambiguous, where this string can be lexed as ©?++© / ©x© or ©?© / y©++x©;
    4867 it requires scanning ahead to determine if there is a ©'('©, which is the start of an argument list.
    4868 
    4869 
    4870 \section{Incompatible}
    4871 
    4872 The following incompatibles exist between \CFA and C, and are similar to Annex C for \CC~\cite{C++14}.
    4873 
    4874 \begin{enumerate}
    4875 \item
    4876 \begin{description}
    4877 \item[Change:] add new keywords \\
    4878 New keywords are added to \CFA (see~\VRef{s:NewKeywords}).
    4879 \item[Rationale:] keywords added to implement new semantics of \CFA.
    4880 \item[Effect on original feature:] change to semantics of well-defined feature. \\
    4881 Any ISO C programs using these keywords as identifiers are invalid \CFA programs.
    4882 \item[Difficulty of converting:] keyword clashes are accommodated by syntactic transformations using the \CFA backquote escape-mechanism (see~\VRef{s:BackquoteIdentifiers}):
    4883 \item[How widely used:] clashes among new \CFA keywords and existing identifiers are rare.
    4884 \end{description}
    4885 
    4886 \item
    4887 \begin{description}
    4888 \item[Change:] type of character literal ©int© to ©char© to allow more intuitive overloading:
    4889 \begin{cfa}
    4890 int rtn( int i );
    4891 int rtn( char c );
    4892 rtn( 'x' );                                             §\C{// programmer expects 2nd rtn to be called}§
    4893 \end{cfa}
    4894 \item[Rationale:] it is more intuitive for the call to ©rtn© to match the second version of definition of ©rtn© rather than the first.
    4895 In particular, output of ©char© variable now print a character rather than the decimal ASCII value of the character.
    4896 \begin{cfa}
    4897 sout | 'x' | " " | (int)'x' | endl;
    4898 x 120
    4899 \end{cfa}
    4900 Having to cast ©'x'© to ©char© is non-intuitive.
    4901 \item[Effect on original feature:] change to semantics of well-defined feature that depend on:
    4902 \begin{cfa}
    4903 sizeof( 'x' ) == sizeof( int )
    4904 \end{cfa}
    4905 no long work the same in \CFA programs.
    4906 \item[Difficulty of converting:] simple
    4907 \item[How widely used:] programs that depend upon ©sizeof( 'x' )© are rare and can be changed to ©sizeof(char)©.
    4908 \end{description}
    4909 
    4910 \item
    4911 \begin{description}
    4912 \item[Change:] make string literals ©const©:
    4913 \begin{cfa}
    4914 char * p = "abc";                               §\C{// valid in C, deprecated in \CFA}§
    4915 char * q = expr ? "abc" : "de"; §\C{// valid in C, invalid in \CFA}§
    4916 \end{cfa}
    4917 The type of a string literal is changed from ©[] char© to ©const [] char©.
    4918 Similarly, the type of a wide string literal is changed from ©[] wchar_t© to ©const [] wchar_t©.
    4919 \item[Rationale:] This change is a safety issue:
    4920 \begin{cfa}
    4921 char * p = "abc";
    4922 p[0] = 'w';                                             §\C{// segment fault or change constant literal}§
    4923 \end{cfa}
    4924 The same problem occurs when passing a string literal to a routine that changes its argument.
    4925 \item[Effect on original feature:] change to semantics of well-defined feature.
    4926 \item[Difficulty of converting:] simple syntactic transformation, because string literals can be converted to ©char *©.
    4927 \item[How widely used:] programs that have a legitimate reason to treat string literals as pointers to potentially modifiable memory are rare.
    4928 \end{description}
    4929 
    4930 \item
    4931 \begin{description}
    4932 \item[Change:] remove \newterm{tentative definitions}, which only occurs at file scope:
    4933 \begin{cfa}
    4934 int i;                                                  §\C{// forward definition}§
    4935 int *j = ®&i®;                                  §\C{// forward reference, valid in C, invalid in \CFA}§
    4936 int i = 0;                                              §\C{// definition}§
    4937 \end{cfa}
    4938 is valid in C, and invalid in \CFA because duplicate overloaded object definitions at the same scope level are disallowed.
    4939 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,
    4940 \begin{cfa}
    4941 struct X { int i; struct X *next; };
    4942 static struct X a;                              §\C{// forward definition}§
    4943 static struct X b = { 0, ®&a® };        §\C{// forward reference, valid in C, invalid in \CFA}§
    4944 static struct X a = { 1, &b };  §\C{// definition}§
    4945 \end{cfa}
    4946 \item[Rationale:] avoids having different initialization rules for builtin types and userdefined types.
    4947 \item[Effect on original feature:] change to semantics of well-defined feature.
    4948 \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.
    4949 \item[How widely used:] seldom
    4950 \end{description}
    4951 
    4952 \item
    4953 \begin{description}
    4954 \item[Change:] have ©struct© introduce a scope for nested types:
    4955 \begin{cfa}
    4956 enum ®Colour® { R, G, B, Y, C, M };
    4957 struct Person {
    4958         enum ®Colour® { R, G, B };      §\C{// nested type}§
    4959         struct Face {                           §\C{// nested type}§
    4960                 ®Colour® Eyes, Hair;    §\C{// type defined outside (1 level)}§
    4961         };
    4962         ß.ß®Colour® shirt;                      §\C{// type defined outside (top level)}§
    4963         ®Colour® pants;                         §\C{// type defined same level}§
    4964         Face looks[10];                         §\C{// type defined same level}§
    4965 };
    4966 ®Colour® c = R;                                 §\C{// type/enum defined same level}§
    4967 Personß.ß®Colour® pc = Personß.ßR;      §\C{// type/enum defined inside}§
    4968 Personß.ßFace pretty;                   §\C{// type defined inside}§
    4969 \end{cfa}
    4970 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.
    4971 \CFA is C \emph{incompatible} on this issue, and provides semantics similar to \Index*[C++]{\CC}.
    4972 Nested types are not hoisted and can be referenced using the field selection operator ``©.©'', unlike the \CC scope-resolution operator ``©::©''.
    4973 \item[Rationale:] ©struct© scope is crucial to \CFA as an information structuring and hiding mechanism.
    4974 \item[Effect on original feature:] change to semantics of well-defined feature.
    4975 \item[Difficulty of converting:] Semantic transformation.
    4976 \item[How widely used:] C programs rarely have nest types because they are equivalent to the hoisted version.
    4977 \end{description}
    4978 
    4979 \item
    4980 \begin{description}
    4981 \item[Change:] In C++, the name of a nested class is local to its enclosing class.
    4982 \item[Rationale:] C++ classes have member functions which require that classes establish scopes.
    4983 \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:
    4984 \begin{cfa}
    4985 struct Y;                                               §\C{// struct Y and struct X are at the same scope}§
    4986 struct X {
    4987 struct Y { /* ... */ } y;
    4988 };
    4989 \end{cfa}
    4990 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.
    4991 Note: this is a consequence of the difference in scope rules, which is documented in 3.3.
    4992 \item[How widely used:] Seldom.
    4993 \end{description}
    4994 
    4995 \item
    4996 \begin{description}
    4997 \item[Change:] comma expression is disallowed as subscript
    4998 \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.
    4999 \item[Effect on original feature:] change to semantics of well-defined feature.
    5000 \item[Difficulty of converting:] semantic transformation of ©x[i,j]© to ©x[(i,j)]©
    5001 \item[How widely used:] seldom.
    5002 \end{description}
    5003 \end{enumerate}
     4831\section{Syntax Ambiguities}
     4832
     4833C has a number of syntax ambiguities, which are resolved by taking the longest sequence of overlapping characters that constitute a token.
     4834For example, the program fragment ©x+++++y© is parsed as \lstinline[showspaces=true]@x ++ ++ + y@ because operator tokens ©++© and ©+© overlap.
     4835Unfortunately, the longest sequence violates a constraint on increment operators, even though the parse \lstinline[showspaces=true]@x ++ + ++ y@ might yield a correct expression.
     4836Hence, C programmers are aware that spaces have to added to disambiguate certain syntactic cases.
     4837
     4838In \CFA, there are ambiguous cases with dereference and operator identifiers, \eg ©int *?*?()©, where the string ©*?*?© can be interpreted as:
     4839\begin{cfa}
     4840*?§\color{red}\textvisiblespace§*?              §\C{// dereference operator, dereference operator}§
     4841*§\color{red}\textvisiblespace§?*?              §\C{// dereference, multiplication operator}§
     4842\end{cfa}
     4843By default, the first interpretation is selected, which does not yield a meaningful parse.
     4844Therefore, \CFA does a lexical look-ahead for the second case, and backtracks to return the leading unary operator and reparses the trailing operator identifier.
     4845Otherwise a space is needed between the unary operator and operator identifier to disambiguate this common case.
     4846
     4847A similar issue occurs with the dereference, ©*?(...)©, and routine-call, ©?()(...)© identifiers.
     4848The ambiguity occurs when the deference operator has no parameters:
     4849\begin{cfa}
     4850*?()§\color{red}\textvisiblespace...§ ;
     4851*?()§\color{red}\textvisiblespace...§(...) ;
     4852\end{cfa}
     4853requiring arbitrary whitespace look-ahead for the routine-call parameter-list to disambiguate.
     4854However, the dereference operator \emph{must} have a parameter/argument to dereference ©*?(...)©.
     4855Hence, always interpreting the string ©*?()© as \lstinline[showspaces=true]@* ?()@ does not preclude any meaningful program.
     4856
     4857The remaining cases are with the increment/decrement operators and conditional expression, \eg:
     4858\begin{cfa}
     4859i++?§\color{red}\textvisiblespace...§(...);
     4860i?++§\color{red}\textvisiblespace...§(...);
     4861\end{cfa}
     4862requiring arbitrary whitespace look-ahead for the operator parameter-list, even though that interpretation is an incorrect expression (juxtaposed identifiers).
     4863Therefore, it is necessary to disambiguate these cases with a space:
     4864\begin{cfa}
     4865i++§\color{red}\textvisiblespace§? i : 0;
     4866i?§\color{red}\textvisiblespace§++i : 0;
     4867\end{cfa}
    50044868
    50054869
    … …  
    50084872
    50094873\begin{quote2}
    5010 \begin{tabular}{lll}
     4874\begin{tabular}{llll}
    50114875\begin{tabular}{@{}l@{}}
    50124876©_AT©                   \\
    … …  
    50164880©coroutine©             \\
    50174881©disable©               \\
    5018 ©dtype©                 \\
    5019 ©enable©                \\
    50204882\end{tabular}
    50214883&
    50224884\begin{tabular}{@{}l@{}}
     4885©dtype©                 \\
     4886©enable©                \\
    50234887©fallthrough©   \\
    50244888©fallthru©              \\
    50254889©finally©               \\
    50264890©forall©                \\
     4891\end{tabular}
     4892&
     4893\begin{tabular}{@{}l@{}}
    50274894©ftype©                 \\
    50284895©lvalue©                \\
    50294896©monitor©               \\
    50304897©mutex©                 \\
     4898©one_t©                 \\
     4899©otype©                 \\
    50314900\end{tabular}
    50324901&
    50334902\begin{tabular}{@{}l@{}}
    5034 ©one_t©                 \\
    5035 ©otype©                 \\
    50364903©throw©                 \\
    50374904©throwResume©   \\
    … …  
    50434910\end{tabular}
    50444911\end{quote2}
     4912
     4913
     4914\section{Incompatible}
     4915
     4916The following incompatibles exist between \CFA and C, and are similar to Annex C for \CC~\cite{C++14}.
     4917
     4918
     4919\begin{enumerate}
     4920\item
     4921\begin{description}
     4922\item[Change:] add new keywords \\
     4923New keywords are added to \CFA (see~\VRef{s:CFAKeywords}).
     4924\item[Rationale:] keywords added to implement new semantics of \CFA.
     4925\item[Effect on original feature:] change to semantics of well-defined feature. \\
     4926Any ISO C programs using these keywords as identifiers are invalid \CFA programs.
     4927\item[Difficulty of converting:] keyword clashes are accommodated by syntactic transformations using the \CFA backquote escape-mechanism (see~\VRef{s:BackquoteIdentifiers}).
     4928\item[How widely used:] clashes among new \CFA keywords and existing identifiers are rare.
     4929\end{description}
     4930
     4931\item
     4932\begin{description}
     4933\item[Change:] drop K\&R C declarations \\
     4934K\&R declarations allow an implicit base-type of ©int©, if no type is specified, plus an alternate syntax for declaring parameters.
     4935\eg:
     4936\begin{cfa}
     4937x;                                                              §\C{// int x}§
     4938*y;                                                             §\C{// int *y}§
     4939f( p1, p2 );                                    §\C{// int f( int p1, int p2 );}§
     4940g( p1, p2 ) int p1, p2;                 §\C{// int g( int p1, int p2 );}§
     4941\end{cfa}
     4942\CFA supports K\&R routine definitions:
     4943\begin{cfa}
     4944f( a, b, c )                                    §\C{// default int return}§
     4945        int a, b; char c                        §\C{// K\&R parameter declarations}§
     4946{
     4947        ...
     4948}
     4949\end{cfa}
     4950\item[Rationale:] dropped from C11 standard.\footnote{
     4951At 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}}
     4952\item[Effect on original feature:] original feature is deprecated. \\
     4953Any old C programs using these K\&R declarations are invalid \CFA programs.
     4954\item[Difficulty of converting:] trivial to convert to \CFA.
     4955\item[How widely used:] existing usages are rare.
     4956\end{description}
     4957
     4958\item
     4959\begin{description}
     4960\item[Change:] type of character literal ©int© to ©char© to allow more intuitive overloading:
     4961\begin{cfa}
     4962int rtn( int i );
     4963int rtn( char c );
     4964rtn( 'x' );                                             §\C{// programmer expects 2nd rtn to be called}§
     4965\end{cfa}
     4966\item[Rationale:] it is more intuitive for the call to ©rtn© to match the second version of definition of ©rtn© rather than the first.
     4967In particular, output of ©char© variable now print a character rather than the decimal ASCII value of the character.
     4968\begin{cfa}
     4969sout | 'x' | " " | (int)'x' | endl;
     4970x 120
     4971\end{cfa}
     4972Having to cast ©'x'© to ©char© is non-intuitive.
     4973\item[Effect on original feature:] change to semantics of well-defined feature that depend on:
     4974\begin{cfa}
     4975sizeof( 'x' ) == sizeof( int )
     4976\end{cfa}
     4977no long work the same in \CFA programs.
     4978\item[Difficulty of converting:] simple
     4979\item[How widely used:] programs that depend upon ©sizeof( 'x' )© are rare and can be changed to ©sizeof(char)©.
     4980\end{description}
     4981
     4982\item
     4983\begin{description}
     4984\item[Change:] make string literals ©const©:
     4985\begin{cfa}
     4986char * p = "abc";                               §\C{// valid in C, deprecated in \CFA}§
     4987char * q = expr ? "abc" : "de"; §\C{// valid in C, invalid in \CFA}§
     4988\end{cfa}
     4989The type of a string literal is changed from ©[] char© to ©const [] char©.
     4990Similarly, the type of a wide string literal is changed from ©[] wchar_t© to ©const [] wchar_t©.
     4991\item[Rationale:] This change is a safety issue:
     4992\begin{cfa}
     4993char * p = "abc";
     4994p[0] = 'w';                                             §\C{// segment fault or change constant literal}§
     4995\end{cfa}
     4996The same problem occurs when passing a string literal to a routine that changes its argument.
     4997\item[Effect on original feature:] change to semantics of well-defined feature.
     4998\item[Difficulty of converting:] simple syntactic transformation, because string literals can be converted to ©char *©.
     4999\item[How widely used:] programs that have a legitimate reason to treat string literals as pointers to potentially modifiable memory are rare.
     5000\end{description}
     5001
     5002\item
     5003\begin{description}
     5004\item[Change:] remove \newterm{tentative definitions}, which only occurs at file scope:
     5005\begin{cfa}
     5006int i;                                                  §\C{// forward definition}§
     5007int *j = ®&i®;                                  §\C{// forward reference, valid in C, invalid in \CFA}§
     5008int i = 0;                                              §\C{// definition}§
     5009\end{cfa}
     5010is valid in C, and invalid in \CFA because duplicate overloaded object definitions at the same scope level are disallowed.
     5011This change makes it impossible to define mutually referential file-local static objects, if initializers are restricted to the syntactic forms of C. For example,
     5012\begin{cfa}
     5013struct X { int i; struct X *next; };
     5014static struct X a;                              §\C{// forward definition}§
     5015static struct X b = { 0, ®&a® };        §\C{// forward reference, valid in C, invalid in \CFA}§
     5016static struct X a = { 1, &b };  §\C{// definition}§
     5017\end{cfa}
     5018\item[Rationale:] avoids having different initialization rules for builtin types and userdefined types.
     5019\item[Effect on original feature:] change to semantics of well-defined feature.
     5020\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.
     5021\item[How widely used:] seldom
     5022\end{description}
     5023
     5024\item
     5025\begin{description}
     5026\item[Change:] have ©struct© introduce a scope for nested types:
     5027\begin{cfa}
     5028enum ®Colour® { R, G, B, Y, C, M };
     5029struct Person {
     5030        enum ®Colour® { R, G, B };      §\C{// nested type}§
     5031        struct Face {                           §\C{// nested type}§
     5032                ®Colour® Eyes, Hair;    §\C{// type defined outside (1 level)}§
     5033        };
     5034        ®.Colour® shirt;                        §\C{// type defined outside (top level)}§
     5035        ®Colour® pants;                         §\C{// type defined same level}§
     5036        Face looks[10];                         §\C{// type defined same level}§
     5037};
     5038®Colour® c = R;                                 §\C{// type/enum defined same level}§
     5039Person®.Colour® pc = Person®.®R;        §\C{// type/enum defined inside}§
     5040Person®.®Face pretty;                   §\C{// type defined inside}§
     5041\end{cfa}
     5042In 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.
     5043\CFA is C \emph{incompatible} on this issue, and provides semantics similar to \Index*[C++]{\CC}.
     5044Nested types are not hoisted and can be referenced using the field selection operator ``©.©'', unlike the \CC scope-resolution operator ``©::©''.
     5045\item[Rationale:] ©struct© scope is crucial to \CFA as an information structuring and hiding mechanism.
     5046\item[Effect on original feature:] change to semantics of well-defined feature.
     5047\item[Difficulty of converting:] Semantic transformation.
     5048\item[How widely used:] C programs rarely have nest types because they are equivalent to the hoisted version.
     5049\end{description}
     5050
     5051\item
     5052\begin{description}
     5053\item[Change:] In C++, the name of a nested class is local to its enclosing class.
     5054\item[Rationale:] C++ classes have member functions which require that classes establish scopes.
     5055\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:
     5056\begin{cfa}
     5057struct Y;                                               §\C{// struct Y and struct X are at the same scope}§
     5058struct X {
     5059struct Y { /* ... */ } y;
     5060};
     5061\end{cfa}
     5062All 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.
     5063Note: this is a consequence of the difference in scope rules, which is documented in 3.3.
     5064\item[How widely used:] Seldom.
     5065\end{description}
     5066
     5067\item
     5068\begin{description}
     5069\item[Change:] comma expression is disallowed as subscript
     5070\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.
     5071\item[Effect on original feature:] change to semantics of well-defined feature.
     5072\item[Difficulty of converting:] semantic transformation of ©x[i,j]© to ©x[(i,j)]©
     5073\item[How widely used:] seldom.
     5074\end{description}
     5075\end{enumerate}
    50455076
    50465077
    … …  
    50805111\leavevmode
    50815112\begin{cfa}[aboveskip=0pt,belowskip=0pt]
    5082 forall( otype T ) T * malloc( void );§\indexc{malloc}§
    5083 forall( otype T ) T * malloc( char fill );
    5084 forall( otype T ) T * malloc( T * ptr, size_t size );
    5085 forall( otype T ) T * malloc( T * ptr, size_t size, unsigned char fill );
    5086 forall( otype T ) T * calloc( size_t nmemb );§\indexc{calloc}§
    5087 forall( otype T ) T * realloc( T * ptr, size_t size );§\indexc{ato}§
    5088 forall( otype T ) T * realloc( T * ptr, size_t size, unsigned char fill );
    5089 
    5090 forall( otype T ) T * aligned_alloc( size_t alignment );§\indexc{ato}§
    5091 forall( otype T ) T * memalign( size_t alignment );             // deprecated
    5092 forall( otype T ) int posix_memalign( T ** ptr, size_t alignment );
     5113forall( dtype T | sized(T) ) T * malloc( void );§\indexc{malloc}§
     5114forall( dtype T | sized(T) ) T * malloc( char fill );
     5115forall( dtype T | sized(T) ) T * malloc( T * ptr, size_t size );
     5116forall( dtype T | sized(T) ) T * malloc( T * ptr, size_t size, unsigned char fill );
     5117forall( dtype T | sized(T) ) T * calloc( size_t nmemb );§\indexc{calloc}§
     5118forall( dtype T | sized(T) ) T * realloc( T * ptr, size_t size );§\indexc{ato}§
     5119forall( dtype T | sized(T) ) T * realloc( T * ptr, size_t size, unsigned char fill );
     5120
     5121forall( dtype T | sized(T) ) T * aligned_alloc( size_t alignment );§\indexc{ato}§
     5122forall( dtype T | sized(T) ) T * memalign( size_t alignment );          // deprecated
     5123forall( dtype T | sized(T) ) int posix_memalign( T ** ptr, size_t alignment );
    50935124
    50945125forall( otype T ) T * memset( T * ptr, unsigned char fill ); // use default value '\0' for fill
    50955126forall( otype T ) T * memset( T * ptr );                                // remove when default value available
     5127
     5128forall( dtype T, ttype Params | sized(T) | { void ?{}(T *, Params); } ) T * new( Params p );
     5129forall( dtype T | { void ^?{}(T *); } ) void delete( T * ptr );
     5130forall( dtype T, ttype Params | { void ^?{}(T *); void delete(Params); } ) void delete( T * ptr, Params rest );
    50965131\end{cfa}
    50975132

  • doc/working/exception/impl/main.c

    r2c9ebab r13099105  
    2626extern int this_exception;
    2727_Unwind_Reason_Code foo_try_match() {
    28         return this_exception == 2 ? _URC_HANDLER_FOUND : _URC_CONTINUE_UNWIND;
     28        return this_exception == 3 ? _URC_HANDLER_FOUND : _URC_CONTINUE_UNWIND;
    2929}
    3030

  • src/InitTweak/FixInit.cc

    r2c9ebab r13099105  
    896896                        Parent::visit( compoundStmt );
    897897
    898                         // add destructors for the current scope that we're exiting
     898                        // add destructors for the current scope that we're exiting, unless the last statement is a return, which
     899                        // causes unreachable code warnings
    899900                        std::list< Statement * > & statements = compoundStmt->get_kids();
    900                         insertDtors( reverseDeclOrder.front().begin(), reverseDeclOrder.front().end(), back_inserter( statements ) );
     901                        if ( ! statements.empty() && ! dynamic_cast< ReturnStmt * >( statements.back() ) ) {
     902                                insertDtors( reverseDeclOrder.front().begin(), reverseDeclOrder.front().end(), back_inserter( statements ) );
     903                        }
    901904                        reverseDeclOrder.pop_front();
    902905                }

  • src/SymTab/Validate.cc

    r2c9ebab r13099105  
    208208        };
    209209
     210        /// ensure that generic types have the correct number of type arguments
     211        class ValidateGenericParameters : public Visitor {
     212        public:
     213                typedef Visitor Parent;
     214                virtual void visit( StructInstType * inst ) final override;
     215                virtual void visit( UnionInstType * inst ) final override;
     216        };
     217
    210218        class ArrayLength : public Visitor {
    211219        public:
    … …  
    235243                Pass3 pass3( 0 );
    236244                CompoundLiteral compoundliteral;
    237 
    238                 HoistStruct::hoistStruct( translationUnit );
     245                ValidateGenericParameters genericParams;
     246
    239247                EliminateTypedef::eliminateTypedef( translationUnit );
     248                HoistStruct::hoistStruct( translationUnit ); // must happen after EliminateTypedef, so that aggregate typedefs occur in the correct order
    240249                ReturnTypeFixer::fix( translationUnit ); // must happen before autogen
    241250                acceptAll( translationUnit, lrt ); // must happen before autogen, because sized flag needs to propagate to generated functions
     251                acceptAll( translationUnit, genericParams );  // check as early as possible - can't happen before LinkReferenceToTypes
    242252                acceptAll( translationUnit, epc ); // must happen before VerifyCtorDtorAssign, because void return objects should not exist
    243253                VerifyCtorDtorAssign::verify( translationUnit );  // must happen before autogen, because autogen examines existing ctor/dtors
    … …  
    829839        }
    830840
     841        template< typename Aggr >
     842        void validateGeneric( Aggr * inst ) {
     843                std::list< TypeDecl * > * params = inst->get_baseParameters();
     844                if ( params != NULL ) {
     845                        std::list< Expression * > & args = inst->get_parameters();
     846                        if ( args.size() < params->size() ) throw SemanticError( "Too few type arguments in generic type ", inst );
     847                        if ( args.size() > params->size() ) throw SemanticError( "Too many type arguments in generic type ", inst );
     848                }
     849        }
     850
     851        void ValidateGenericParameters::visit( StructInstType * inst ) {
     852                validateGeneric( inst );
     853                Parent::visit( inst );
     854        }
     855
     856        void ValidateGenericParameters::visit( UnionInstType * inst ) {
     857                validateGeneric( inst );
     858                Parent::visit( inst );
     859        }
     860
    831861        DeclarationWithType * CompoundLiteral::mutate( ObjectDecl *objectDecl ) {
    832862                storageClasses = objectDecl->get_storageClasses();

  • src/libcfa/gmp

    r2c9ebab r13099105  
    1010// Created On       : Tue Apr 19 08:43:43 2016
    1111// Last Modified By : Peter A. Buhr
    12 // Last Modified On : Sun May 14 23:47:36 2017
    13 // Update Count     : 9
     12// Last Modified On : Mon May 22 08:32:39 2017
     13// Update Count     : 13
    1414//
    1515
    … …  
    3535Int ?=?( Int * lhs, long int rhs ) { mpz_set_si( lhs->mpz, rhs ); return *lhs; }
    3636Int ?=?( Int * lhs, unsigned long int rhs ) { mpz_set_ui( lhs->mpz, rhs ); return *lhs; }
    37 //Int ?=?( Int * lhs, const char * rhs ) { if ( mpq_set_str( lhs->mpz, rhs, 0 ) ) abort(); return *lhs; }
     37Int ?=?( Int * lhs, const char * rhs ) { if ( mpz_set_str( lhs->mpz, rhs, 0 ) ) { printf( "invalid string conversion\n" ); abort(); } return *lhs; }
    3838
    3939char ?=?( char * lhs, Int rhs ) { char val = mpz_get_si( rhs.mpz ); *lhs = val; return val; }

  • src/tests/.expect/64/gmp.txt

    r2c9ebab r13099105  
    44conversions
    55y:97
     6y:12345678901234567890123456789
    67y:3
    78y:-3
    … …  
    2425z:150000000000000000000
    2526z:16666666666666666666
     2716666666666666666666, 2 16666666666666666666, 2
    2628x:16666666666666666666 y:2
    2729

  • src/tests/gmp.c

    r2c9ebab r13099105  
    1010// Created On       : Tue Apr 19 08:55:51 2016
    1111// Last Modified By : Peter A. Buhr
    12 // Last Modified On : Sun May 14 14:46:50 2017
    13 // Update Count     : 530
     12// Last Modified On : Mon May 22 09:05:09 2017
     13// Update Count     : 538
    1414//
    1515
    1616#include <gmp>
    1717
    18 int main() {
     18int main( void ) {
    1919        sout | "constructors" | endl;
    2020        short int si = 3;
    … …  
    2525        sout | "conversions" | endl;
    2626        y = 'a';
     27        sout | "y:" | y | endl;
     28        y = "12345678901234567890123456789";
    2729        sout | "y:" | y | endl;
    2830        y = si;
    … …  
    6264        z = x / 3;
    6365        sout | "z:" | z | endl;
     66        sout | div( x, 3 ) | x / 3 | "," | x % 3 | endl;
    6467        [ x, y ] = div( x, 3 );
    6568        sout | "x:" | x | "y:" | y | endl;
    66 //      sout | div( x, 3 ) | x / 3 | "," | x % 3 | endl;
    6769
    6870        sout | endl;
    … …  
    7274        fn = (Int){0}; fn1 = fn;                                                        // 1st case
    7375        sout | (int)0 | fn | endl;
    74         fn = (Int){1}; fn2 = fn1; fn1 = fn;                                     // 2nd case
     76        fn = 1; fn2 = fn1; fn1 = fn;                                            // 2nd case
    7577        sout | 1 | fn | endl;
    76         for ( int i = 2; i <= 200; i += 1 ) {
     78        for ( unsigned int i = 2; i <= 200; i += 1 ) {
    7779                fn = fn1 + fn2; fn2 = fn1; fn1 = fn;                    // general case
    7880                sout | i | fn | endl;
    … …  
    8385        sout | "Factorial Numbers" | endl;
    8486        Int fact;
    85         fact = (Int){1};                                                                        // 1st case
     87        fact = 1;                                                                                       // 1st case
    8688        sout | (int)0 | fact | endl;
    87         for ( int i = 1; i <= 40; i += 1 ) {
     89        for ( unsigned int i = 1; i <= 40; i += 1 ) {
    8890                fact = fact * i;                                                                // general case
    8991                sout | i | fact | endl;
Note: See TracChangeset for help on using the changeset viewer.