Index: doc/user/pointer2.fig =================================================================== --- doc/user/pointer2.fig (revision 4096de0dcc74726f866aecbc8a9e4ef084268699) +++ doc/user/pointer2.fig (revision a17e7b8842a8607a2a53eaf202f9cf7841a5563f) @@ -8,41 +8,41 @@ -2 1200 2 +2 2 0 1 0 7 100 0 -1 0.000 0 0 -1 0 0 5 + 1500 1950 1950 1950 1950 2250 1500 2250 1500 1950 +2 2 0 1 0 7 100 0 -1 0.000 0 0 -1 0 0 5 + 1500 1500 1950 1500 1950 1800 1500 1800 1500 1500 2 1 0 1 4 7 100 -1 -1 0.000 0 0 -1 1 0 2 1 1 1.00 45.00 90.00 - 2550 1800 1800 1950 + 2700 1800 1950 1950 2 1 0 1 4 7 50 -1 -1 0.000 0 0 -1 1 0 2 1 1 1.00 45.00 90.00 - 2550 1950 1800 1800 + 2700 1950 1950 1800 2 2 0 1 0 7 100 0 -1 0.000 0 0 -1 0 0 5 - 1500 1500 1800 1500 1800 1800 1500 1800 1500 1500 + 2700 1950 3150 1950 3150 2250 2700 2250 2700 1950 2 2 0 1 0 7 100 0 -1 0.000 0 0 -1 0 0 5 - 1500 1950 1800 1950 1800 2250 1500 2250 1500 1950 -2 2 0 1 0 7 100 0 -1 0.000 0 0 -1 0 0 5 - 2550 1500 2850 1500 2850 1800 2550 1800 2550 1500 -2 2 0 1 0 7 100 0 -1 0.000 0 0 -1 0 0 5 - 2550 1950 2850 1950 2850 2250 2550 2250 2550 1950 + 2700 1500 3150 1500 3150 1800 2700 1800 2700 1500 2 1 0 1 4 7 100 -1 -1 0.000 0 0 -1 1 0 2 1 1 1.00 45.00 90.00 - 3600 1800 2850 1950 + 3900 1800 3150 1950 2 2 0 1 0 7 100 0 -1 0.000 0 0 -1 0 0 5 - 3600 1500 3900 1500 3900 1800 3600 1800 3600 1500 + 3900 1500 4350 1500 4350 1800 3900 1800 3900 1500 4 2 0 100 0 4 10 0.0000 2 120 270 1425 2250 104\001 4 2 0 100 0 4 10 0.0000 2 120 270 1425 1800 100\001 4 2 0 100 0 4 10 0.0000 2 90 90 1425 1625 x\001 4 2 0 100 0 4 10 0.0000 2 120 90 1425 2075 y\001 -4 1 0 100 0 4 10 0.0000 2 120 90 1650 1700 3\001 -4 1 0 100 0 4 10 0.0000 2 120 90 1650 2150 3\001 -4 0 0 100 0 4 10 0.0000 2 120 165 1875 2150 int\001 -4 0 0 100 0 4 10 0.0000 2 120 165 1875 1700 int\001 -4 2 0 100 0 4 10 0.0000 2 120 270 2475 2250 112\001 -4 2 0 100 0 4 10 0.0000 2 150 180 2475 2075 p2\001 -4 2 0 100 0 4 10 0.0000 2 120 270 2475 1800 108\001 -4 2 0 100 0 4 10 0.0000 2 150 180 2475 1625 p1\001 -4 1 0 100 0 4 10 0.0000 2 120 270 2700 1700 104\001 -4 1 0 100 0 4 10 0.0000 2 120 270 2700 2150 100\001 -4 0 0 100 0 4 10 0.0000 2 120 270 2925 2150 int *\001 -4 0 0 100 0 4 10 0.0000 2 120 270 2925 1700 int *\001 -4 2 0 100 0 4 10 0.0000 2 120 270 3525 1800 116\001 -4 2 0 100 0 4 10 0.0000 2 150 180 3525 1625 p3\001 -4 1 0 100 0 4 10 0.0000 2 120 270 3750 1700 112\001 -4 0 0 100 0 4 10 0.0000 2 120 330 3975 1700 int **\001 +4 0 0 100 0 4 10 0.0000 2 120 165 2025 2150 int\001 +4 0 0 100 0 4 10 0.0000 2 120 165 2025 1700 int\001 +4 2 0 100 0 4 10 0.0000 2 120 270 2625 2250 112\001 +4 2 0 100 0 4 10 0.0000 2 150 180 2625 2075 p2\001 +4 2 0 100 0 4 10 0.0000 2 120 270 2625 1800 108\001 +4 2 0 100 0 4 10 0.0000 2 150 180 2625 1625 p1\001 +4 1 0 100 0 4 10 0.0000 2 120 90 1725 2150 3\001 +4 1 0 100 0 4 10 0.0000 2 120 90 1725 1700 3\001 +4 0 0 100 0 4 10 0.0000 2 120 270 3225 2150 int *\001 +4 0 0 100 0 4 10 0.0000 2 120 270 3225 1700 int *\001 +4 2 0 100 0 4 10 0.0000 2 120 270 3825 1800 116\001 +4 2 0 100 0 4 10 0.0000 2 150 180 3825 1625 p3\001 +4 1 0 100 0 4 10 0.0000 2 120 270 2925 2150 100\001 +4 1 0 100 0 4 10 0.0000 2 120 270 2925 1700 104\001 +4 1 0 100 0 4 10 0.0000 2 120 270 4125 1700 112\001 +4 0 0 100 0 4 10 0.0000 2 120 330 4425 1700 int **\001 Index: doc/user/user.tex =================================================================== --- doc/user/user.tex (revision 4096de0dcc74726f866aecbc8a9e4ef084268699) +++ doc/user/user.tex (revision a17e7b8842a8607a2a53eaf202f9cf7841a5563f) @@ -11,6 +11,6 @@ %% Created On : Wed Apr 6 14:53:29 2016 %% Last Modified By : Peter A. Buhr -%% Last Modified On : Wed Jul 6 21:08:24 2016 -%% Update Count : 1070 +%% Last Modified On : Thu Jul 7 08:25:37 2016 +%% Update Count : 1099 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% @@ -525,5 +525,5 @@ Special addresses are used to denote certain states or access co-processor memory. By convention, no variable is placed at address 0, so addresses like 0, 1, 2, 3 are often used to denote no-value or other special states. -Often dereferencing a special state causes a memory fault, so checking is necessary during execution. +Often dereferencing a special state causes a \Index{memory fault}, so checking is necessary during execution. If the programming language assigns addresses, a program's execution is \Index{sound}, i.e., all addresses are to valid memory locations. C allows programmers to assign addresses, so there is the potential for incorrect addresses, both inside and outside of the computer address-space. @@ -542,13 +542,13 @@ & \begin{lstlisting} -int * const x = (int *)100 +int * ®const® x = (int *)100 *x = 3; // implicit dereference -int * const y = (int *)104; +int * ®const® y = (int *)104; *y = *x; // implicit dereference \end{lstlisting} \end{tabular} \end{quote2} -where the right example is how the compiler logically interpreters variables. -Since a variable name only points to one location during its lifetime, it is a \Index{immutable} pointer; +where the right example is how the compiler logically interpreters the variables in the left example. +Since a variable name only points to one location during its lifetime, it is an \Index{immutable} pointer; hence, variables ©x© and ©y© are constant pointers in the compiler interpretation. In general, variable addresses are stored in instructions instead of loaded independently, so an instruction fetch implicitly loads a variable's address. @@ -594,5 +594,5 @@ In many cases, the compiler can infer the meaning: \begin{lstlisting} -p2 = p1 + x; §\C{// compiler infers *p2 = *p1 + x;}§ +p2 = p1 + x; §\C{// compiler infers *p2 = *p1 + x;}§ \end{lstlisting} because adding the arbitrary integer value in ©x© to the address of ©p1© and storing the resulting address into ©p2© is an unlikely operation. @@ -600,6 +600,6 @@ However, there are ambiguous cases, especially when \Index{pointer arithmetic} is possible, as in C: \begin{lstlisting} -p1 = p2; §\C{// p1 = p2 or *p1 = *p2}§ -p1 = p1 + 1; §\C{// p1 = p1 + 1 or *p1 = *p1 + 1}§ +p1 = p2; §\C{// p1 = p2\ \ or\ \ *p1 = *p2}§ +p1 = p1 + 1; §\C{// p1 = p1 + 1\ \ or\ \ *p1 = *p1 + 1}§ \end{lstlisting} @@ -607,6 +607,6 @@ In C, the default meaning for pointers is to manipulate the pointer's address and the pointed-to value is explicitly accessed by the dereference operator ©*©. \begin{lstlisting} -p1 = p2; §\C{// pointer address assignment}§ -*p1 = *p1 + 1; §\C{// pointed-to value assignment / operation}§ +p1 = p2; §\C{// pointer address assignment}§ +*p1 = *p1 + 1; §\C{// pointed-to value assignment / operation}§ \end{lstlisting} which works well for situations where manipulation of addresses in the primary meaning and data is rarely accessed, such as storage management (©malloc©/©free©). @@ -622,15 +622,15 @@ \end{lstlisting} -To switch the default meaning for an address requires a new kind of pointer, called a \newterm{reference} and denoted by ©&©. +To switch the default meaning for an address requires a new kind of pointer, called a \newterm{reference} denoted by ©&©. \begin{lstlisting} int x, y, ®&® r1, ®&® r2, ®&&® r3; -®&®r1 = &x; §\C{// r1 points to x}§ -®&®r2 = &r1; §\C{// r2 also points to x}§ -®&®r1 = &y; §\C{// r2 also points to x}§ -®&®r1 = &r2 + 1; §\C{// r1 points to y, pointer arithmetic}§ -®&®r3 = ®&®&r2; §\C{// r3 points to r2}§ +®&®r1 = &x; §\C{// r1 points to x}§ +®&®r2 = &r1; §\C{// r2 also points to x}§ +®&®r1 = &y; §\C{// r2 also points to x}§ +®&®r1 = &r2 + 1; §\C{// r1 points to y, pointer arithmetic}§ +®&®r3 = ®&®&r2; §\C{// r3 points to r2}§ r2 = ((r1 + r2) * (r3 - r1)) / (r3 - 15); §\C{// implicit dereferencing}§ \end{lstlisting} -Except for auto-dereferencing by the compiler, this reference example is the same as the pointer example. +Except for auto-dereferencing by the compiler, this reference example is the same as the previous pointer example. Hence, a reference behaves like the variable name for the current variable it is pointing-to. The simplest way to understand a reference is to imagine the compiler inserting a dereference operator before the reference variable for each reference qualifier in a declaration, e.g.: @@ -642,5 +642,5 @@ ®*®r2 = ((®*®r1 + ®*®r2) ®*® (®**®r3 - ®*®r1)) / (®**®r3 - 15); \end{lstlisting} -When a reference appears beside a dereference, e.g., ©&*©, they cancel out.\footnote{ +When a reference operation appears beside a dereference operation, e.g., ©&*©, they cancel out.\footnote{ The unary ©&© operator yields the address of its operand. If the operand has type ``type'', the result has type ``pointer to type''. @@ -648,9 +648,9 @@ Hence, assigning to a reference requires the address of the reference variable (\Index{lvalue}): \begin{lstlisting} -(&®*®)r1 = &x; §\C{// (\&*) cancel out giving variable r1 not the variable pointed-to by r1}§ +(&®*®)r1 = &x; §\C{// (\&*) cancel out giving variable r1 not the variable pointed-to by r1}§ \end{lstlisting} Similarly, the address of a reference can be obtained for assignment or computation (\Index{rvalue}): \begin{lstlisting} -(&®*®)r3 = &(&®*®)r2; §\C{// (\&*) cancel out giving the address of variable r2}§ +(&®*®)r3 = &(&®*®)r2; §\C{// (\&*) cancel out giving the address of variable r2}§ \end{lstlisting} \Index{Cancellation}\index{pointer!cancellation rule} works to arbitrary depth, and pointer and reference values are interchangeable because both contain addresses. @@ -658,11 +658,11 @@ int x, *p1 = &x, **p2 = &p1, ***p3 = &p2, &r1 = &x, &&r2 = &&r1, &&&r3 = &&r2; -***p3 = 3; §\C{// change x}§ -r3 = 3; §\C{// change x, ***r3}§ -**p3 = ...; §\C{// change p1}§ -&r3 = ...; §\C{// change r1, (\&*)**r3, 1 cancellation}§ -*p3 = ...; §\C{// change p2}§ -&&r3 = ...; §\C{// change r2, (\&(\&*)*)*r3, 2 cancellations}§ -&&&r3 = p3; §\C{// change r3 to p3, (\&(\&(\&*)*)*)r3, 3 cancellations}§ +***p3 = 3; §\C{// change x}§ +r3 = 3; §\C{// change x, ***r3}§ +**p3 = ...; §\C{// change p1}§ +&r3 = ...; §\C{// change r1, (\&*)**r3, 1 cancellation}§ +*p3 = ...; §\C{// change p2}§ +&&r3 = ...; §\C{// change r2, (\&(\&*)*)*r3, 2 cancellations}§ +&&&r3 = p3; §\C{// change r3 to p3, (\&(\&(\&*)*)*)r3, 3 cancellations}§ \end{lstlisting} Finally, implicit dereferencing and cancellation are a static (compilation) phenomenon not a dynamic one. @@ -674,45 +674,51 @@ Java deals with the address duality by making address assignment the default and providing a \Index{clone} mechanism to change the pointed-to value. -As for pointers, references may have qualifiers: -\begin{lstlisting} -const int cx = 5; §\C{// cannot change cx;}§ -const int & r3 = &cx; §\C{// cannot change what r3 is pointing to}§ -®&®r3 = &cx; §\C{// can change r3}§ -r3 = 7; §\C{// error, cannot change cx}§ -int & const r4 = &x; §\C{// must be initialized, \CC reference}§ -®&®r4 = &x; §\C{// error, cannot change r4}§ -const int & const r5 = &cx; §\C{// must be initialized, \CC reference}§ -r5 = 7; §\C{// error, cannot change cx}§ -®&®r5 = &cx; §\C{// error, cannot change r5}§ +As for a pointer, a reference may have qualifiers: +\begin{lstlisting} +const int cx = 5; §\C{// cannot change cx;}§ +const int & r3 = &cx; §\C{// cannot change what r3 is pointing to}§ +®&®r3 = &cx; §\C{// can change r3}§ +r3 = 7; §\C{// error, cannot change cx}§ +int & const r4 = &x; §\C{// must be initialized, \CC reference}§ +®&®r4 = &x; §\C{// error, cannot change r4}§ +const int & const r5 = &cx; §\C{// must be initialized, \CC reference}§ +r5 = 7; §\C{// error, cannot change cx}§ +®&®r5 = &cx; §\C{// error, cannot change r5}§ \end{lstlisting} Hence, for type ©& const©, there is no pointer assignment, so ©&r4 = &x© is disallowed, and \emph{the address value cannot be ©0©}. -in effect, the compiler is managing the addresses not the programmer. - -\Index{Initialization} is different than \Index{assignment} because initialization occurs on an empty (uninitialized) storage on an object, while assignment occurs on possible initialized storage for an object. +In effect, the compiler is managing the addresses fpr type ©& const© not the programmer. + +\Index{Initialization} is different than \Index{assignment} because initialization occurs on the empty (uninitialized) storage on an object, while assignment occurs on possibly initialized storage for an object. There are three initialization contexts in \CFA: declaration initialization, argument/parameter binding, return/temporary binding. -For reference (like pointer) initialization, the initializing value must be an address (lvalue) not a value (rvalue). -\begin{lstlisting} -int * p = &x; §\C{// both \&x and x are possible interpretations}§ -int & r = x; §\C{// x unlikely interpretation, because of auto-dereferencing}§ -\end{lstlisting} -Hence, the compiler implicitly inserts a reference, ©&©, before the initialization expression: -Similarly, when a reference is used for a parameter/return type, the call-site argument does not require a reference. -\begin{lstlisting} -int & f( int & ri ); §\C{// reference parameter and return}§ -z = f( x ) + f( y ); §\C{// reference not required}§ +For reference initialization (like pointer), the initializing value must be an address (lvalue) not a value (rvalue). +\begin{lstlisting} +int * p = &x; §\C{// both \&x and x are possible interpretations}§ +int & r = x; §\C{// x unlikely interpretation, because of auto-dereferencing}§ +\end{lstlisting} +Hence, the compiler implicitly inserts a reference operator, ©&©, before the initialization expression: +Similarly, when a reference is used for a parameter/return type, the call-site argument does not require a reference operator. +\begin{lstlisting} +int & f( int & ri ); §\C{// reference parameter and return}§ +z = f( x ) + f( y ); §\C{// reference operator added not required}§ \end{lstlisting} Within routine ©f©, it is possible to change the argument by changing the corresponding parameter, and parameter ©ri© can be locally reassigned within ©f©. -The return reference from ©f© is copied into a compiler generated temporary, which is logically treated as an initialization. +The return reference from ©f© is copied into a compiler generated temporary, which is treated as an initialization. When a pointer/reference parameter has a ©const© value (immutable), it is possible to pass literals and expressions. \begin{lstlisting} -void f( const int & cri ); -void g( const int * cri ); -f( 3 ); g( &3 ); +void f( ®const® int & cri ); +void g( ®const® int * cri ); +f( 3 ); g( &3 ); f( x + y ); g( &(x + y) ); \end{lstlisting} Here, the compiler passes the address to the literal 3 or the temporary for the expression ©x + y©, knowing the argument cannot be changed through the parameter. -(The ©&© is necessary for the pointer parameter to make the types match, and is common for a C programmer.) -\CFA extends this semantics to a mutable pointer/reference parameter, and the compiler implicitly creates the necessary temporary (copying the argument), which is subsequently pointed to by the reference parameter, which can be changed. +(The ©&© is necessary for the pointer parameter to make the types match, and is common requirement for a C programmer.) +\CFA extends this semantics to a mutable pointer/reference parameter, and the compiler implicitly creates the necessary temporary (copying the argument), which is subsequently pointed to by the reference parameter and can be changed. +\begin{lstlisting} +void f( int & cri ); +void g( int * cri ); +f( 3 ); g( &3 ); §\C{// compiler implicit generates temporaries}§ +f( x + y ); g( &(x + y) ); §\C{// compiler implicit generates temporaries}§ +\end{lstlisting} Essentially, there is an implicit rvalue to lvalue conversion in this case.\footnote{ This conversion attempts to address the \newterm{const Hell} problem, when the innocent addition of a ©const© qualifier causes a cascade of type failures, requiring an unknown number of additional ©const© qualifiers, until it is discovered a ©const© qualifier cannot be added and all the ©const© qualifiers must be removed.} @@ -722,8 +728,8 @@ \begin{lstlisting} void f( int p ) {...} -void (*fp)( int ) = &f; §\C{// pointer initialization}§ -void (*fp)( int ) = f; §\C{// reference initialization}§ -(*fp)(3); §\C{// pointer invocation}§ -fp(3); §\C{// reference invocation}§ +void (*fp)( int ) = &f; §\C{// pointer initialization}§ +void (*fp)( int ) = f; §\C{// reference initialization}§ +(*fp)(3); §\C{// pointer invocation}§ +fp(3); §\C{// reference invocation}§ \end{lstlisting} A routine variable is best described by a ©const© reference: @@ -731,6 +737,6 @@ const void (&fp)( int ) = f; fp( 3 ); -fp = ... §\C{// change code not allowed}§ -&fp = ...; §\C{// change routine refernce allowed}§ +fp = ... §\C{// change code not allowed}§ +&fp = ...; §\C{// change routine reference}§ \end{lstlisting} because the value of the routine variable is a routine literal, i.e., the routine code is normally immutable during execution.\footnote{