1 | \chapter{Background} |
---|
2 | |
---|
3 | \CFA is a backwards-compatible extension of the C programming language, therefore, it must support C-style enumerations. |
---|
4 | The following covers C enumerations. |
---|
5 | |
---|
6 | As discussed in \VRef{s:Aliasing}, it is common for C programmers to ``believe'' there are three equivalent forms of named constants. |
---|
7 | \begin{clang} |
---|
8 | #define Mon 0 |
---|
9 | static const int Mon = 0; |
---|
10 | enum { Mon }; |
---|
11 | \end{clang} |
---|
12 | \begin{enumerate}[leftmargin=*] |
---|
13 | \item |
---|
14 | For @#define@, the programmer has to explicitly manage the constant name and value. |
---|
15 | Furthermore, these C preprocessor macro names are outside of the C type-system and can incorrectly change random text in a program. |
---|
16 | \item |
---|
17 | The same explicit management is true for the @const@ declaration, and the @const@ variable cannot appear in constant-expression locations, like @case@ labels, array dimensions,\footnote{ |
---|
18 | C allows variable-length array-declarations (VLA), so this case does work, but it fails in \CC, which does not support VLAs, unless it is \lstinline{g++}.} immediate operands of assembler instructions, and occupy storage. |
---|
19 | \begin{clang} |
---|
20 | $\$$ nm test.o |
---|
21 | 0000000000000018 r Mon |
---|
22 | \end{clang} |
---|
23 | \item |
---|
24 | Only the @enum@ form is managed by the compiler, is part of the language type-system, works in all C constant-expression locations, and might not occupy storage.. |
---|
25 | \end{enumerate} |
---|
26 | |
---|
27 | |
---|
28 | \section{C \lstinline{const}} |
---|
29 | \label{s:Cconst} |
---|
30 | |
---|
31 | C can simulate the aliasing @const@ declarations \see{\VRef{s:Aliasing}}, with static and dynamic initialization. |
---|
32 | \begin{clang} |
---|
33 | static const int one = 0 + 1; $\C{// static initialization}$ |
---|
34 | static const void * NIL = NULL; |
---|
35 | static const double PI = 3.14159; |
---|
36 | static const char Plus = '+'; |
---|
37 | static const char * Fred = "Fred"; |
---|
38 | static const int Mon = 0, Tue = Mon + 1, Wed = Tue + 1, Thu = Wed + 1, Fri = Thu + 1, |
---|
39 | Sat = Fri + 1, Sun = Sat + 1; |
---|
40 | void foo() { |
---|
41 | const int r = random() % 100; $\C{// dynamic intialization}$ |
---|
42 | int va[r]; $\C{// VLA, auto scope only}$ |
---|
43 | } |
---|
44 | \end{clang} |
---|
45 | Statically initialized identifiers may appear in any constant-expression context, \eg @case@. |
---|
46 | Dynamically initialized identifiers may appear as array dimensions in @g++@, which allows variable-sized arrays on the stack. |
---|
47 | Again, this form of aliasing is not an enumeration. |
---|
48 | |
---|
49 | |
---|
50 | \section{C Enumeration} |
---|
51 | \label{s:CEnumeration} |
---|
52 | |
---|
53 | The C enumeration has the following syntax~\cite[\S~6.7.2.2]{C11}. |
---|
54 | \begin{clang}[identifierstyle=\linespread{0.9}\it] |
---|
55 | $\it enum$-specifier: |
---|
56 | enum identifier$\(_{opt}\)$ { enumerator-list } |
---|
57 | enum identifier$\(_{opt}\)$ { enumerator-list , } |
---|
58 | enum identifier |
---|
59 | enumerator-list: |
---|
60 | enumerator |
---|
61 | enumerator-list , enumerator |
---|
62 | enumerator: |
---|
63 | enumeration-constant |
---|
64 | enumeration-constant = constant-expression |
---|
65 | \end{clang} |
---|
66 | The terms \emph{enumeration} and \emph{enumerator} used in this work \see{\VRef{s:Terminology}} come from the grammar. |
---|
67 | The C enumeration semantics are discussed using examples. |
---|
68 | |
---|
69 | |
---|
70 | \subsection{Type Name} |
---|
71 | \label{s:TypeName} |
---|
72 | |
---|
73 | An \emph{unnamed} enumeration is used to provide aliasing \see{\VRef{s:Aliasing}} exactly like a @const@ declaration in other languages. |
---|
74 | However, it is restricted to integral values. |
---|
75 | \begin{clang} |
---|
76 | enum { Size = 20, Max = 10, MaxPlus10 = Max + 10, @Max10Plus1@, Fred = -7 }; |
---|
77 | \end{clang} |
---|
78 | Here, the aliased constants are: 20, 10, 20, 21, and -7. |
---|
79 | Direct initialization is by a compile-time expression generating a constant value. |
---|
80 | Indirect initialization (without initialization, @Max10Plus1@) is \newterm{auto-initialized}: from left to right, starting at zero or the next explicitly initialized constant, incrementing by @1@. |
---|
81 | Because multiple independent enumerators can be combined, enumerators with the same values can occur. |
---|
82 | The enumerators are rvalues, so assignment is disallowed. |
---|
83 | Finally, enumerators are \newterm{unscoped}, \ie enumerators declared inside of an @enum@ are visible (projected) into the enclosing scope of the @enum@ type. |
---|
84 | For unnamed enumeration this semantic is required because there is no type name for scoped qualification. |
---|
85 | |
---|
86 | As noted, this kind of aliasing declaration is not an enumeration, even though it is declared using an @enum@ in C. |
---|
87 | While the semantics is misleading, this enumeration form matches with aggregate types: |
---|
88 | \begin{cfa} |
---|
89 | typedef struct /* unnamed */ { ... } S; |
---|
90 | struct /* unnamed */ { ... } x, y, z; $\C{// questionable}$ |
---|
91 | struct S { |
---|
92 | union /* unnamed */ { $\C{// unscoped fields}$ |
---|
93 | int i; double d ; char ch; |
---|
94 | }; |
---|
95 | }; |
---|
96 | \end{cfa} |
---|
97 | Hence, C programmers would expect this enumeration form to exist in harmony with the aggregate form. |
---|
98 | |
---|
99 | A \emph{named} enumeration is an enumeration: |
---|
100 | \begin{clang} |
---|
101 | enum @Week@ { Mon, Tue, Wed, Thu@ = 10@, Fri, Sat, Sun }; |
---|
102 | \end{clang} |
---|
103 | and adopts the same semantics with respect to direct and auto intialization. |
---|
104 | For example, @Mon@ to @Wed@ are implicitly assigned with constants @0@--@2@, @Thu@ is explicitly set to constant @10@, and @Fri@ to @Sun@ are implicitly assigned with constants @11@--@13@. |
---|
105 | As well, initialization may occur in any order. |
---|
106 | \begin{clang} |
---|
107 | enum Week { |
---|
108 | Thu@ = 10@, Fri, Sat, Sun, |
---|
109 | Mon@ = 0@, Tue, Wed@,@ $\C{// terminating comma}$ |
---|
110 | }; |
---|
111 | \end{clang} |
---|
112 | Note, the comma in the enumerator list can be a terminator or a separator, allowing the list to end with a dangling comma.\footnote{ |
---|
113 | A terminating comma appears in other C syntax, \eg the initializer list.} |
---|
114 | This feature allow enumerator lines to be interchanged without moving a comma. |
---|
115 | Named enumerators are also unscoped. |
---|
116 | |
---|
117 | |
---|
118 | \subsection{Implementation} |
---|
119 | |
---|
120 | In theory, a C enumeration \emph{variable} is an implementation-defined integral type large enough to hold all enumerator values. |
---|
121 | In practice, C uses @int@ as the underlying type for enumeration variables, because of the restriction to integral constants, which have type @int@ (unless qualified with a size suffix). |
---|
122 | |
---|
123 | |
---|
124 | \subsection{Usage} |
---|
125 | \label{s:Usage} |
---|
126 | |
---|
127 | C proves an implicit \emph{bidirectional} conversion between an enumeration and its integral type. |
---|
128 | \begin{clang} |
---|
129 | enum Week week = Mon; $\C{// week == 0}$ |
---|
130 | week = Fri; $\C{// week == 11}$ |
---|
131 | int i = Sun; $\C{// implicit conversion to int, i == 13}$ |
---|
132 | @week = 10000;@ $\C{// UNDEFINED! implicit conversion to Week}$ |
---|
133 | \end{clang} |
---|
134 | While converting an enumerator to underlying type is useful, the implicit conversion from the base type to an enumeration type is a common source of error. |
---|
135 | |
---|
136 | Enumerators can appear in @switch@ and looping statements. |
---|
137 | \begin{cfa} |
---|
138 | enum Week { Mon, Tue, Wed, Thu, Fri, Sat, Sun }; |
---|
139 | switch ( week ) { |
---|
140 | case Mon: case Tue: case Wed: case Thu: case Fri: |
---|
141 | printf( "weekday\n" ); |
---|
142 | case Sat: case Sun: |
---|
143 | printf( "weekend\n" ); |
---|
144 | } |
---|
145 | for ( enum Week day = Mon; day <= Sun; day += 1 ) { |
---|
146 | printf( "day %d\n", day ); // 0-6 |
---|
147 | } |
---|
148 | \end{cfa} |
---|
149 | For iterating, the enumerator values \emph{must} have a consecutive ordering with a fixed step between values. |
---|
150 | Note, it is the bidirectional conversion that allows incrementing @day@: @day@ is converted to @int@, integer @1@ is added, and the result is converted back to @Week@ for the assignment to @day@. |
---|
151 | For safety, \CC does not support the bidirectional conversion, and hence, an unsafe cast is necessary to increment @day@: @day = (Week)(day + 1)@. |
---|
152 | |
---|
153 | There is a C idiom to automatically know the number of enumerators in an enumeration. |
---|
154 | \begin{cfa} |
---|
155 | enum E { A, B, C, D, @N@ }; // N == 4 |
---|
156 | for ( enum E e = A; e < @N@; e += 1 ) ... |
---|
157 | \end{cfa} |
---|
158 | Here, the auto-incrementing counts the number of enumerators and puts the total into the last enumerator @N@. |
---|
159 | @N@ is often used as the dimension for an array assocated with the enumeration. |
---|
160 | \begin{cfa} |
---|
161 | E array[@N@]; |
---|
162 | for ( enum E e = A; e < N; e += 1 ) { |
---|
163 | array[e] = e; |
---|
164 | } |
---|
165 | \end{cfa} |
---|
166 | However, for typed enumerations, \see{\VRef{f:EumeratorTyping}}, this idiom fails. |
---|
167 | |
---|
168 | This idiom leads to another C idiom using an enumeration with matching companion information. |
---|
169 | For example, an enumeration is linked with a companion array of printable strings. |
---|
170 | \begin{cfa} |
---|
171 | enum Integral_Type { chr, schar, uschar, sshort, ushort, sint, usint, ..., NO_OF_ITYPES }; |
---|
172 | char * Integral_Name[@NO_OF_ITYPES@] = { |
---|
173 | "char", "signed char", "unsigned char", |
---|
174 | "signed short int", "unsigned short int", |
---|
175 | "signed int", "unsigned int", ... |
---|
176 | }; |
---|
177 | enum Integral_Type integral_type = ... |
---|
178 | printf( "%s\n", Integral_Name[@integral_type@] ); // human readable type name |
---|
179 | \end{cfa} |
---|
180 | However, the companion idiom results in the \emph{harmonizing} problem because an update to the enumeration @Integral_Type@ often requires a corresponding update to the companion array \snake{Integral_Name}. |
---|
181 | The need to harmonize is at best indicated by a comment before the enumeration. |
---|
182 | This issue is exacerbated if enumeration and companion array are in different translation units. |
---|
183 | |
---|
184 | \bigskip |
---|
185 | While C provides a true enumeration, it is restricted, has unsafe semantics, and does provide enumeration features in other programming languages. |
---|