A doubly linked-list in C

[Keith Thompson]

Phil Carmody said: [...]

Or don't bother. The C standard clearly and consistently describes
the mechanism of passing by address as passing by reference.

The C standard uses the phrase "passing by reference" exactly nowhere.

A pointer type is described as a reference in 6.2.5 Types para 20.
Yes.

Therefore passing a pointer is passing a reference.

Sure, but the phrase was "passing *by* reference", not "passing *a*
reference".

The term "pass by reference" has a particular meaning in computer
science, one that goes beyond the meanings of the individual words.
Some languages other than C directly support the concept of
"pass-by-reference" in a way that C itself does not. (In C++, for
example, passing a pointer to an object and passing an object by
reference are both possible, and are very different things.)

C also defines the word "name", or at least it uses it extensively.
If you use a name as an argument to a function, would you call that
"passing by name"?

6.2.5p20 is using the English word "reference" to define the word
"pointer".

If you need a special term for passing a pointer to an object, why not
call it "passing by pointer"?

 

[Ian Collins]

What bit about "Please attempt to unambiguously describe a mechanism
for passing by reference" makes you think I'm not asking for such
implementation details?

None of it. All that happens is a pointer is passed under the hood and
the compiler takes care of the dereferencing under the hood. Not rocket
science.

 

[BartC]

"Pass by reference"

So, has it been decided yet whether or not C has pass-by-reference? I
haven't been keeping score.

My feeling is that C does pass-by-reference in the same way as assembler.

 

[BartC]

On 2009-04-20, Keith Thompson <[email protected]> wrote:

Note that C++ reference parameters can be used as call by value:

int func(const int &ref);

// ...

func(5);

This is call by value, not call by reference, since the expression 5 does
not
denote an assignable storage location, as required by the concept of call
by
reference.

Why can't it pass a reference to a location containing the value 5?

 

[jameskuyper]

Phil Carmody wrote:
....

Your separation of what can be done at compile time and runtime seems
artificial. Separation between what is done by the caller, and what is
done by the callee does make sense, as that distinguishes pass-by-name
and pass-by-reference. C cannot intrinsically do pass-by-name.

When people disagree about what the correct meaning of a phrase is,
I've found that it's often easier to focus on the question of what the
meaning should be. The definition of a term should be such as to make
it useful to write sentences using that term (and not just for the
purpose of sentences that correct other people for using the term
incorrectly. To put this in a useful context, I'm going to use some C+
+ code, because some of us would use "pass by reference" exclusively
for a feature that is present in C++, and missing in C. Consider the
following C++ code:

void pass_func(int i, const int * pi, int &ri)
{
if (i)
ri = *pi;
else
*pi = ri;
}

int main()
{
int one = 1, two = 2, three = 3;
func(one, &two, three);
}

Using the terms "pass by value" and "pass by reference" in the manner
that you consider correct, could you please describe the passing that
occurs in the above code? It should be clear from the way in which you
describe it, why the second argument requires slightly more
complicated code than the third one.

 

[Mark Wooding]

Not just non-object, but it also explicitly passes arrays (by their
address).

Errr, no. Actually, 6.5.2.2 (Function calls) mentions arrays only (a)
to specify the constraint that `the expression that denotes the function
shall have type pointer to function returning void or returning an
object type other than an array type', and (b) to remind the reader, in
a footnote, about the way that parameters declared as having array type
is `adjusted' to have pointer type. The fact that an argument
expression of array type becomes a pointer follows from 6.3.2.1p3.

This seems remarkably roundabout for an `explicit' mention.

-- [mdw]

 

[CBFalconer]

.... snip ...

"Pass by reference"

So, has it been decided yet whether or not C has pass-by-reference?
I haven't been keeping score.

My feeling is that C does pass-by-reference in the same way as
assembler.

That's pretty accurate. The point, that nobody seems to make, is
that a system (not C) that can pass by reference generally has no
way of accessing that 'pointer' equivalent that was actually
passed.

 

[BartC]

That's pretty accurate. The point, that nobody seems to make, is
that a system (not C) that can pass by reference generally has no
way of accessing that 'pointer' equivalent that was actually
passed.

Don't know about that. I had something similar in a language where if A was
a reference, then

X=A

would do the dereferencing behind the scenes (fetching the value that A
points to). But the pointer value can be obtained using:

X=&A

and the address of A itself by using &&A. It just a question of balancing *
and & ops with the automatic ones added by the reference mechanisms.

In C, nothing happens unless & and * are used explicitly, *except* for
arrays, which confuse things by having implicit & and *, giving the
appearance of pass by reference (or call by reference, whatever the
difference is).

 

[Phil Carmody]

Phil Carmody said: [...]
Or don't bother. The C standard clearly and consistently describes
the mechanism of passing by address as passing by reference.

The C standard uses the phrase "passing by reference" exactly nowhere.

A pointer type is described as a reference in 6.2.5 Types para 20.
Yes.

Therefore passing a pointer is passing a reference.

Sure, but the phrase was "passing *by* reference", not "passing *a*
reference".

What is so special about the word "reference" such that "value"
can be inserted into the blanks in
"passing a _____ is passing by _____"
yet "reference" can't.

Just for reference, passing a name is passing by name too, IMHO.

The term "pass by reference" has a particular meaning in computer
science, one that goes beyond the meanings of the individual words.
Some languages other than C directly support the concept of
"pass-by-reference" in a way that C itself does not. (In C++, for
example, passing a pointer to an object and passing an object by
reference are both possible, and are very different things.)

If you believe that they are very different, then please tell me
which of foo() or bar() the following are:

Snippet A:
"""
..LFB2:
movl 4(%esp), %eax
movl (%eax), %eax
imull %eax, %eax
ret
"""

Snippet B
"""
..LFB2:
movl 4(%esp), %eax
movl (%eax), %eax
imull %eax, %eax
ret
"""

and C++ source:
"""
int foo(unsigned int *i)
{
return *i**i;
}
"""
and:
"""
int bar(unsigned int &i)
{
return i*i;
}
"""

It's worth a guess - you've got evens odds.

C also defines the word "name", or at least it uses it extensively.
If you use a name as an argument to a function, would you call that
"passing by name"?

6.2.5p20 is using the English word "reference" to define the word
"pointer".

If you need a special term for passing a pointer to an object, why not
call it "passing by pointer"?

I don't need a new special term. Following precedent, it's already
been called a reference.

Phil

 

[Phil Carmody]

Phil Carmody said:


Sure - but you were talking about passing /by/ reference, which is a
different matter.

Time to tag your partner and read his branch of the thread.

Phil

 

[Phil Carmody]

Errr, no.
Wrong!

Actually, 6.5.2.2 (Function calls) mentions arrays only (a)
to specify the constraint that `the expression that denotes the function
shall have type pointer to function returning void or returning an
object type other than an array type', and (b) to remind the reader, in
a footnote, about the way that parameters declared as having array type
is `adjusted' to have pointer type. The fact that an argument
expression of array type becomes a pointer follows from 6.3.2.1p3.

This seems remarkably roundabout for an `explicit' mention.

Ah, I see we have a third person who's singularly stuborn.

It's a shame when otherwise intelligent posters think that their
inability to find things in the standard (n1256 at least) implies
that they aren't there. You should now have all the clues to find
enough to correct your point of view regarding what the standard
says.

Phil

 

[Keith Thompson]

Phil Carmody said: [...]
Or don't bother. The C standard clearly and consistently describes
the mechanism of passing by address as passing by reference.

The C standard uses the phrase "passing by reference" exactly nowhere.

C&V please.

A pointer type is described as a reference in 6.2.5 Types para 20.
Yes.

Therefore passing a pointer is passing a reference.

Sure, but the phrase was "passing *by* reference", not "passing *a*
reference".

What is so special about the word "reference" such that "value"
can be inserted into the blanks in
"passing a _____ is passing by _____"
yet "reference" can't.

Just for reference, passing a name is passing by name too, IMHO.

So if an argument happens to be string literal, you'd call that
"passing by string literal"?

But "pass-by-name" (or "call-by-name") has a specific and commonly
understood (or misunderstood) meaning; using an expression that
happens to be a name as an argument has nothing to do with that
meaning.

If you believe that they are very different, then please tell me
which of foo() or bar() the following are:

[C++ source and assembly snippets snipped]

It's worth a guess - you've got evens odds.

Irrelevant. I'll glad concede that they can produce the same machine
code. That's not what I meant by "very different". If you think they
aren't very different, then I suppose you wouldn't think it's
important for a C++ programmer to understand the distinction.

I don't need a new special term. Following precedent, it's already
been called a reference.

And you insist on extrapolating from the use of the word "reference"
(with it's ordinary English meaning) to the phrase "pass by
reference".

I've already explained why I think that's a bad idea.

 

[Keith Thompson]

Time to tag your partner and read his branch of the thread.

Right, if two people both disagree with you they must be partners.

 

[Keith Thompson]

Ah, I see we have a third person who's singularly stuborn.

It's a shame when otherwise intelligent posters think that their
inability to find things in the standard (n1256 at least) implies
that they aren't there. You should now have all the clues to find
enough to correct your point of view regarding what the standard
says.

Since you made your claim just after the rather remarkable claim that
the standard refers to "passing by reference" (a phrase it never
uses), I'm not going to take your word for this.

Mark Wooding is correct. Arrays are not passed as arguments; an array
expression is converted to a pointer, and the resulting pointer can
then be passed as an argument. If there's some other wording in the
standard that refers to passing arrays by their address, please cite
it. (If there is, it's probably just an informal statement, possibly
even an error.)

 

[CBFalconer]

Don't know about that. I had something similar in a language
where if A was a reference, then

X=A

would do the dereferencing behind the scenes (fetching the value
that A points to). But the pointer value can be obtained using:

X=&A

and the address of A itself by using &&A. It just a question of
balancing * and & ops with the automatic ones added by the
reference mechanisms.

In C, nothing happens unless & and * are used explicitly,
*except* for arrays, which confuse things by having implicit &
and *, giving the appearance of pass by reference (or call by
reference, whatever the difference is).

Fair enough. Fix my sloppy use of language by replacing
'accessing' with 'altering'.

 

[Phil Carmody]

Phil Carmody said:


Let's try to pass by reference, and fix up the failures as we go:

1) refer to an object in an argument-expression list:

int foo(int);
int i = 6;
foo(i);

Are we passing i by reference? Clearly not. foo() can't even see i,
only a copy of it. So let's fix foo()'s vision, at least:

2) refer to an object's /address/ in an argument-expression list:

int foo(int *);
int i = 6;
foo(&i);

Are we passing i by reference? Clearly not. We're not even passing i
/at all/.

You are passing something that refers to i.

What about that sentence do you have a problem with?

Instead, we're passing i's address. Still, at least foo()
can now find i. But what is actually being passed is a pointer to
i, not i itself.

An address that refers, by indirection, to exactly the same object
that i refers to by name.

3) use true pass-by-reference:

int foo(int &);
int i = 6;
foo(i);

Are we *now* passing i by reference? Yes. Unfortunately, we had to
switch languages to do it.

<snip>

The difference between 2 and 3 is little more than syntactic
sugar. As evidenced by the identical code generated.

Phil

 

[Phil Carmody]

Right, if two people both disagree with you they must be partners.

No, if one automatically dives into the majority of arguments
in order to support the other, then they're as good as partners.
Quite amusing to see, to be honest. Perhaps you don't notice
you're doing it.

Phil

 

[arnuld]

About as long as it takes to read and understand section 6 of the
comp.lang.c FAQ, <http://www.c-faq.com>.

The relationship between arrays and pointers in C really isn't all
that complicated. Arrays and pointers are two very different things.
The trouble is that certain C constructs almost seem to conspire to
confuse them, making it *seem* like they're the same thing in certain
contexts. You just have to learn to understand a piece of code that
uses arrays and pointers in terms of what's actually going on, rather
than just looking at the syntax.

Arrays are not pointers.
Pointers are not arrays.
Read section 6 of the FAQ.

okay, I got it. Arrays and pointers are different things with two
exceptions:

1) passing an array as an argument to a function. In that case, you never
access the array but the pointer to the first element and then you use
pointer arithmetic to access the array elements.

2) when a pointer is assigned the value of an array (even when we are not
talking about function arguments) then we can access the array using
pointer arithmetic. In fact, C, implicitly converts a into p + i where
p &a[0], C always index into array using pointers.


I got it or still wrong ?

 

[Guest]

rkiesling wrote:

...


I doubt that there are any such readers, but your comment suggests
that you disagree. In what way do you think they are making that
association? Do you have any particular people in mind whose comments
made you believe that they have made such an association? If so, could
you please identify those people, and the comments that they made that
led you to this conclusion?

I'm not being deliberately obtuse. I understand that your comment was
intended to convey criticism of some group of people, and from context
I suspect that this group might include myself. But your comment
failed to achieve it's goal, in that I (at least) don't understand
what criticism it's intended to convey.

I think he's referring to this recent post by Kaz
It's available on google

************************************************************

Simply passing the reference does not say anything about the
contents of the struct or array. C decouples the semantics
of passing on the reference from the actual contents of the
struct or array. And so this is intended.

I missed an announcement here. Is there a competition to post the
dumbest
article that shows a lack of C knowledge, yet manages to use the
words
``decouple'', ``semantics'' and ``portable''?

Aha, trolling.

I'll try to illustrate these cases

I recommend watercolor, or /washable/ crayons.

 

[Phil Carmody]

Since you made your claim just after the rather remarkable claim that
the standard refers to "passing by reference" (a phrase it never
uses), I'm not going to take your word for this.

You can retract that assertion, I never put the phrase in quotes.
I simply said that they mention passing by reference by virtue
of passing parameters by means of what they call references, with
the implication that I consider passing references to be passing
by reference.

Mark Wooding is correct. Arrays are not passed as arguments;

No issue with that clause (I disagree with the first sentence
obviously).

an array
expression is converted to a pointer, and the resulting pointer can
then be passed as an argument.

No issue with that clause either.

I'm curious why you felt the need to parrot such obvious things -
did you think that I was not aware of them, or something?

I'll note here that you explicitly adorned the verb "pass" with
"as arguments" in both cases above, I'll come back to that right
at the end.

If there's some other wording in the
standard that refers to passing arrays by their address, please cite
it. (If there is, it's probably just an informal statement, possibly
even an error.)

Well, not "passing arrays by their address", but certainly "passing
[something]" where you and I know, and anyone conversant with C too,
that the value actaully passed isn't what follows the word "pass",
and which I believe you ought to object to, given your prior stance.

... then passes the array as a single argument ...

... passes the string pointed to ...

I'm guessing you simply searched for 'pass', too, didn't you, and
didn't detect the 'third person' 'singular' clue above? Then again,
if you don't use 'passed' too, you'll miss in the search/sort
functions, where of course objects are passed via their address:

... objects are passed more than once to the comparison function ...

[*] ... objects passed as arguments to that call.

and other "passed"s include:

Strings ... pased as the 2nd argument to setlocale. (twice)

... the list ... is passed to function f4.
[the list being implement as an array of pointers]

And of course there's the function pointer that you've skipped
over too:

To pass one function to another ...


So that's 6 clear unambiguous uses of the the verb 'pass' where
the direct object in the text is different from what is actually
passed.

Incidentally, "actually passed" is a quote from the standard too -
they appreciate that sometimes things *described* as being "passed"
(namely the 6 I refer to above) aren't actually passed.


Note - the [*]-ed clause above I do not believe is well-worded at
all, and would explicitly (and hereby) support your call for that
one to be changed, were you to feel strongly enough about the
wording of the standard to raise it with the standards committee.
"passed as arguments" says too much and the extra implications are
incorrect.

Phil