| blob | b84228a15a49a5b76e856f86ffe6404855f41b56 |
2 <!-- This collection of hypertext pages is Copyright 1995, 1996 by Steve Summit. -->
3 <!-- This material may be freely redistributed and used -->
4 <!-- but may not be republished or sold without permission. -->
5 <html>
6 <head>
13 </head>
14 <body>
17 page 95
18 <p>This section discusses a very common use of pointers:
19 setting things up so that a function can modify values in its caller,
20 or return values,
21 via its arguments.
22 Remember that,
23 normally,
24 C passes arguments by value,
25 and that if a function modifies one of its arguments,
26 it modifies only its local copy,
27 not the value in the caller.
28 (Normally,
29 this is a good thing;
30 having a function which inadvertently assigns to its arguments
31 and hence inadvertently modifies a value in its caller
33 can be a source of obscure bugs in languages which don't use call-by-value.)
34 However,
35 what happens if a function wants to modify a value in its caller,
36 and its caller wants to let it?
37 How can a function return two values?
38 (A function's formal return value is always a single value.)
39 </p><p>The answer to both questions
40 is that a function can declare a parameter which is a pointer.
41 The caller then passes a pointer to
42 (that is, the ``address of'')
43 a variable in the caller which is to be modified
44 or which is to receive the second return value.
45 In fact,
46 we've seen examples of this already:
48 as well as the line itself,
49 and
51 in section 4.3
52 returned both a code for an operator
53 and a string representing the full text of the operator.
54 (We needed
55 that string
57 so that the string could return
58 the full numeric input.)
59 Though we didn't say so at the time,
60 we were actually using pointers
61 in these examples.
62 (We'll explore the relationship between arrays and pointers,
63 which made this possible,
64 in section 5.3.)
65 </p><p>With all of this in mind,
66 make sure that you understand why the swap example on page 95
67 would not work,
69 and what the figure on page 96 shows.
71 which modified some variables
73 in its caller.
75 how to return two values from a function
76 by returning one value as the normal function return value
77 and the other one by writing to a pointer.
78 (There
79 is no fundamental difference,
80 though,
81 between
82 ``modifying a variable in the caller''
83 and
84 ``returning a value by writing to a pointer'';
85 these are just two applications of pointer parameters.)
87 is somewhat complicated because it
88 allows free-form input,
89 that is,
90 the values need only be separated by whitespace or punctuation;
91 they are not restricted to being one per line or anything.
92 (C source code is also free-form in this regard;
94 To see more clearly
96 imagine for a moment that
99 In that case,
100 we might use the following simpler
101 (i.e. more primitive)
102 code:
103 <pre> int getint(int *pn)
104 {
105 char line[20];
107 return EOF;
108 *pn = atoi(line);
109 return 1;
110 }
112 documented as returning nonzero for a valid number and 0 for
113 something other than a number.
114 Our stripped-down version does not,
115 and as it happens,
116 the example code at the bottom of page 96 does not make use of
117 the valid/invalid distinction.
118 Can you see a way to rewrite the code at the bottom of page 96
120 </p><p>You might also notice,
121 again from the code at the bottom of page 96,
123 it can take the address of any data object,
124 in this case,
126 Just as for all of C's other operators,
128 although it is restricted to expressions which represent
129 addressable objects.
130 Expressions like
132 are meaningless and illegal.
135 plus an end-of-file indication,
136 in its single return value.
139 </p><p>The examples in this section are again relatively safe.
140 The pointers have all been parameters,
141 and the callers have passed pointers
142 (that is, the ``addresses'' of)
143 their own, properly-allocated variables.
144 That is,
145 code like
148 </pre>and
149 <pre> int a;
150 getint(&a);
151 </pre>is correct and quite safe.
152 </p><p>Something to beware of,
153 though,
154 is the temptation to inadvertently pass an uninitialized pointer variable
155 (rather than the ``address'' of some other
156 variable)
157 to a routine which expects a pointer.
159 as its argument
161 Suppose we took that description literally,
162 and wrote
163 <pre> int *ip; /* a pointer to an int */
164 getint(ip);
166 but the pointer we passed doesn't point anywhere!
169 it will scribble on some random part of memory,
170 and the program may crash.
171 When people get caught in this trap,
175 <pre> getint(*ip); /* WRONG */
176 </pre>but these go from bad to worse.
177 (If you think about them carefully,
182 The correct usage for now,
183 as we showed already,
184 is something like
185 <pre> int a;
186 getint(&a);
187 </pre>In this case,
189 so when we generate a pointer to it
193 </p><hr>
194 <p>
195 Read sequentially:
200 </p>
201 <p>
205 </p>
206 </body>
207 </html>