`But "glory" doesn't mean "a nice knock-down argument",' Alice objected.
`When *I* use a word,' Humpty Dumpty said, in a rather scornful tone,
`it means just what I choose it to mean -- neither more nor less.'
`The question is,' said Alice, `whether you *can* make words mean so
many different things.'
`The question is,' said Humpty, `which is to be master -- that's all.'
(see <http://www.sabian.org/Alice/lgchap06.htm>).
>Chris Torek wrote:
>>... C remains pass-by-value. The gimmick is that the "value" of
>>an array is a pointer to the array's first element. In:
>>
>> void f(void) {
>> char buf[100];
>> char *p;
>>
>> p = buf;
>>
>> we attempt to copy the "value" of buf -- an array -- to the pointer
>> variable p. The "value" of the array is a pointer to the array's
>> first element, so this sets p to point to &buf[0]. ... [Passing "buf"
to a function g() likewise provides the value &buf[0].]
>> Within g(), as for any simulation of by-reference in C, we have to
>> use the unary "*" operator in order to write to buf[0]:
>>
>> void g(char * ptr) {
>> * ptr = 42;
>> ...
>> }
>>
>> and if we fail to prefix "ptr" with the unary "*" operator when
>> assigning, we will "re-bind" it so that it no longer points to
>> "buf" at all ...
In article <o91wf.6628$M%. net>
Joseph Dionne <> wrote:
>Look who is being humorous. Sir, in you example, "buf" will never
>change is memory value, even *if* you pass it by reference, "& buf".
[I assume "is memory value" is a typo for "its memory value".]
First, I must continue to insist that passing "&buf" does not pass
buf by-reference, as the term "by-reference" is used in compiler
circles. It passes the value &buf by value, which is what one
would expect, since C passes all parameter by value. Note that
the type of &buf differs from the type of "the value of buf" --
&buf has type (char (*)[100]), as one can see from the following:
% cat t.c
void f(void) {
char buf[100];
char *p1;
char (*p2)[50];
char (*p3)[100];
p1 = &buf; /* line 7 - draws a diagnostic */
p2 = &buf; /* line 8 - draws a diagnostic */
p3 = &buf; /* line 9 - no diagnostic */
}
% strictcc -O -c t.c
t.c: In function `f':
t.c:7: error: assignment from incompatible pointer type
t.c:8: error: assignment from incompatible pointer type
%
Second -- but perhaps even more important -- in a very real sense
(but not in the quirky C language, where the "value" of an array
is a pointer to the array's first element), the "memory value" of
buf is a sequence of 100 "char"s. Thus, whether in f() or in g(),
if we change any of the 100 array elements, we have in fact changed
the "memory value" of buf. What you mean to say is that we cannot
change the *address* of buf -- neither "buf as a whole" (i.e., we
cannot move the array from addresses A through A+99 on the x86
stack on an actual implementation, to some new set of addresses B
through B+99), nor any element of it. This is of course true.
However, the address, wherever it may be, is not in fact fixed
forever, but only for the lifetime of the given function activation:
% cat t.c
#include <stdio.h>
void f(int r) {
char buf[100];
printf("&buf[0]: %p\n", (void *)&buf[0]);
if (r > 0)
f(r - 1);
}
void g(void) {
char x[20];
f(0);
}
int main(void) {
f(1);
g();
return 0;
}
% strictcc -o t t.c
% ./t
&buf[0]: 0x8047a58
&buf[0]: 0x80479c8
&buf[0]: 0x8047a18
%
Note that three different numbers appeared. On this particular
(x86) implementation, these are addresses on the system-supplied
stack, printed as if via %#x. The system uses linear, byte-addressed
virtual memory, so these are the actual "hardware addresses"
(virtualized, of course) within the process running the program.
In the second, recursive call to f(), there are of course two
"buf"s outstanding in memory, one for each activation; in the third,
there is only one "buf" but its address is different from either
of the previous two because g()'s activation record is occupying
space above it (the x86 stack having a "natural" downward-growing
direction).
>I think we all can agree the pascal and c++ support pass by
>reference by different syntax. I assert the c uses yet another
>syntax to implement pass by reference, nothing more or less.
Unfortunately for you and/or anyone with whom you are trying to
communicate, your definition of what constitutes "pass by reference"
disagrees with the majority in computing science / informatics.
For the rest of us, if special syntax is required on *every*
(de)reference, what we have is not an actual, language-provided,
by-reference mechanism. It is fine to say that C lets us simulate
by-reference via pointers, and when speaking informally, calling
it "by reference" is not completely out of the question (though I
myself would try to stick to the phrase "passing *a* reference")
-- but one should make it clear, if asked, that this is not what
is, in informatics, called "by-reference".
It is also worth pointing out that the distinction does show
through if the function you call, to which you pass a reference,
happens to implement the call as value-result internally and
uses a global variable and you pass the address of that global.
(See my earlier example, elsewhere in this thread.)
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
email: forget about it
http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.
Similar Threads
