no need to precede function and array names with &

[lovecreatesbea...]

K&R 2, sec. 5.11 says that no need to precede function and array names
with address-of operators &, why?

[Chris Dollin]

lovecreatesbea. [e-mail] wrote:

K&R 2, sec. 5.11 says that no need to precede function and array names
with address-of operators &, why?

Presumably because they though it was worth saying, even though it's
not actually true.

--
Chris "2 out of 3 isn't bad" Dollin
The shortcuts are all full of people using them.

[Harald van Dijk]

Chris Dollin wrote:

lovecreatesbea. [e-mail] wrote:

K&R 2, sec. 5.11 says that no need to precede function and array names
with address-of operators &, why?

Presumably because they though it was worth saying, even though it's
not actually true.

When can an alternative which does not involve the & operator not be
found? (It doesn't have to be a better alternative, just an
alternative.)

[Chris Dollin]

Harald van Dijk wrote:

Chris Dollin wrote:

>lovecreatesbea [e-mail] wrote:

K&R 2, sec. 5.11 says that no need to precede function and array names
with address-of operators &, why?

Presumably because they though it was worth saying, even though it's
not actually true.

When can an alternative which does not involve the & operator not be
found? (It doesn't have to be a better alternative, just an
alternative.)

I don't understand the question (too many `not`s, I don't know whether
to cancel or emphasise). So hoping this strikes appropriately:

* you don't need to preceed a function name with an & to get its
address: the name will decay to that address in value context anyway.

* you don't need to preceed an array name with an & to get the address
of its first element: the name will decay to that address in value
context anyway.

* however, if you want the /address of the array/, as opposed to the
address of its first element, you have to use the & operator to
do so. (This is why I said "not actually true" above.)

As to why K&R thought it worth saying, presumably it's both worth
knowing and not obvious.

--
Chris "falling further in" Dollin
"I'm still here and I'm holding the answers" - Karnataka, /Love and Affection/

[Harald van Dijk]

Chris Dollin wrote:

Harald van Dijk wrote:

Chris Dollin wrote:

lovecreatesbea. [e-mail] wrote:

K&R 2, sec. 5.11 says that no need to precede function and array names
with address-of operators &, why?

Presumably because they though it was worth saying, even though it's
not actually true.

When can an alternative which does not involve the & operator not be
found? (It doesn't have to be a better alternative, just an
alternative.)

I don't understand the question (too many `not`s, I don't know whether
to cancel or emphasise). So hoping this strikes appropriately:

Sorry. What I meant is that I believe there is always an alternative
without the & operator, and I asked for a counterexample.

* however, if you want the /address of the array/, as opposed to the
address of its first element, you have to use the & operator to
do so. (This is why I said "not actually true" above.)

You don't. You can use a cast instead.

int main(void) {
int a[2];
int (*pa)[2] = (int (*)[2]) a;
}

And yes, & would be better, that's why I wrote the second sentence in
my previous message.

[Chris Dollin]

Harald van Dijk wrote:

Chris Dollin wrote:

>Harald van Dijk wrote:

Chris Dollin wrote:
lovecreatesbea [e-mail] wrote:

K&R 2, sec. 5.11 says that no need to precede function and array names
with address-of operators &, why?

Presumably because they though it was worth saying, even though it's
not actually true.

When can an alternative which does not involve the & operator not be
found? (It doesn't have to be a better alternative, just an
alternative.)

I don't understand the question (too many `not`s, I don't know whether
to cancel or emphasise). So hoping this strikes appropriately:

Sorry. What I meant is that I believe there is always an alternative
without the & operator, and I asked for a counterexample.

Oh, I see.

>* however, if you want the /address of the array/, as opposed to the
address of its first element, you have to use the & operator to
do so. (This is why I said "not actually true" above.)

You don't. You can use a cast instead.

Oh bother, you're right. But:

You can use a cast to do all sorts of thoroughly unsafe things;
I wouldn't like to use one when it was both completely unnecessary
and dangerous.

int main(void) {
int a[2];
int (*pa)[2] = (int (*)[2]) a;
}

And yes, & would be better, that's why I wrote the second sentence in
my previous message.

Indeed, & would be /lots/ better.

--
Chris "falling further in" Dollin
"Who are you? What do you want?" /Babylon 5/

[Nils O. Selåsdal]

Harald van Dijk wrote:

Chris Dollin wrote:

>Harald van Dijk wrote:

>>Chris Dollin wrote:
lovecreatesb [e-mail] wrote:

K&R 2, sec. 5.11 says that no need to precede function and array names
with address-of operators &, why?
Presumably because they though it was worth saying, even though it's
not actually true.
When can an alternative which does not involve the & operator not be
found? (It doesn't have to be a better alternative, just an
alternative .)

I don't understand the question (too many `not`s, I don't know whether
to cancel or emphasise). So hoping this strikes appropriately:

Sorry. What I meant is that I believe there is always an alternative
without the & operator, and I asked for a counterexample.

>* however, if you want the /address of the array/, as opposed to the
address of its first element, you have to use the & operator to
do so. (This is why I said "not actually true" above.)

You don't. You can use a cast instead.

int main(void) {
int a[2];
int (*pa)[2] = (int (*)[2]) a;
}

And yes, & would be better, that's why I wrote the second sentence in
my previous message.

You could also have done:
FILE *f = (FILE*)a;

That does not mean it is correct, or will "work".
Don't cast, unless you absolutly know why it is ok to do
that cast.

[Harald van Dijk]

Nils O. Selåsdal wrote:

Harald van Dijk wrote:

You don't. You can use a cast instead.

int main(void) {
int a[2];
int (*pa)[2] = (int (*)[2]) a;
}

And yes, & would be better, that's why I wrote the second sentence in
my previous message.

You could also have done:
FILE *f = (FILE*)a;

Yes, casts at times let you get away with broken code. You have not
explained how my code is broken. If my code is not broken, the fact
that it is far more fragile is not really relevant, considering I
already admitted it was bad style.