Why multiplication not allowed?

[Vijay Kumar R Zanvar]

Hi,

Why multiplication of pointers is not allowed?
Till now I only know this, but not the reason why!

PS: As a rule, I searched the FAQ, but could not
find an answer.

 

[Ben Pfaff]

Why multiplication of pointers is not allowed?
Till now I only know this, but not the reason why!

What would multiplication of pointers mean?

 

[Vijay Kumar R Zanvar]

What would multiplication of pointers mean?

#include <stdio.h>
#include <stdlib.h>

int
main ( void )
{
int i = 10;
int *k = &i, *j = &i;

k = k * j;
return EXIT_SUCCESS;
}

This gives an error:

ptr_mul.c: In function `main':
ptr_mul.c:10: error: invalid operands to binary *

 

[Ben Pfaff]

#include <stdio.h>
#include <stdlib.h>

int
main ( void )
{
int i = 10;
int *k = &i, *j = &i;

k = k * j;

You mean
*k = *k * *j;
In other words, multiply `int's, not pointers to `int's.

return EXIT_SUCCESS;
}

The difference between pointers and their referents is pretty
fundamental. Have you considered reading a textbook or taking a
class?

 

[Kevin Goodsell]

The question Ben is asking is, what would you propose pointer
multiplication do? How would you define the operation? I can't think of
any way in which multiplying a pointer by any other value would be
useful or even meaningful.

Your question is somewhat like asking "why can't I assign to a
function?" or "why can't I take the square root of a struct?" There's
just no logical reason why you *should* be able to.

-Kevin

 

[Richard Bos]

Why multiplication of pointers is not allowed?

Jack lives at Westmoreland Street 12, London SW6 4E8. Jill lives at
Rossinistraat 27b, 1287 CZ Amsterdam. Please multiply these addresses
and let us know the result.

Richard

 

[Richard Heathfield]

Is the following code wrong? I mean, does it do the same?
int* k =&i
int* j=&i
k* = k* * j*

Yes, it's wrong; no, it doesn't do the same thing; and no, it's not legal
syntax. The last line parses as:

k *= k * *j *

That is, multiply k (a pointer!) by the contents of j, multiply /that/ by
heaven knows what, and then use the result to multiply by k again,
assigning the result to k.

(It seems to me more readable than the above. I come from Pascal
background)

In C, the dereferencing operator comes before the pointer. C programmers are
accustomed to this syntax, and find it perfectly readable.

 

[Julian Maisano]

You mean
*k = *k * *j;
In other words, multiply `int's, not pointers to `int's.

Is the following code wrong? I mean, does it do the same?
int* k =&i
int* j=&i
k* = k* * j*

(It seems to me more readable than the above. I come from Pascal background)

 

[Jeremy Yallop]

Yes, it's wrong; no, it doesn't do the same thing; and no, it's not legal
syntax. The last line parses as:

k *= k * *j *

It doesn't parse that way. The whitespace between '*' and '=' is
significant, so

i* = j;

is also a syntax error.

Jeremy.

 

[Richard Heathfield]

It doesn't parse that way. The whitespace between '*' and '=' is
significant,

Indeed it is. Oops, sorry, darn and heck. (More or less in that order.)

so

i* = j;

is also a syntax error.

Right.

 

[Eric Sosman]

Hi,

Why multiplication of pointers is not allowed?
Till now I only know this, but not the reason why!

PS: As a rule, I searched the FAQ, but could not
find an answer.

The result would be meaningless. An easy (but
informal) way to understand this is to use an analogy:
think of pointer values as street addresses. Then
the following operations make sense:

- Find the house at "123 Main Street."

- To find the neigboring house, compute "123
Main Street plus one." (I'm ignoring such
real-world intrusions as odd-even numbering
schemes, discontinuities between city blocks,
and so on: we're just exploring an imperfect
analogy, after all.)

- To find the distance between two Main Street
addresses, compute "123 Main Street minus 189
Main Street," yielding "minus 66 lots."

However, some other arithmetical operations make
no sense at all:

- Computing "123 Main Street plus 207 Main Street"
produces no useful answer.

- Computing "123 Main Street minus 123 Elm Street"
produces no useful answer.

- Similarly, computing "123 Main Street times
89 El Camino Real" makes no sense. Perhaps the
result might be considered a kind of "area,"
but there seems to be no useful analogous
concept to "area" in the addressing of memory-
resident objects.

- Finally, computing "123 Main Street times three"
might possibly make sense, arriving at "369 Main
Street." But such a definition carries a built-
in assumption that Main Street is zero-based,
and in a linear computer memory no more than one
object can begin at "address zero." If you want
to find the house three times as far from the
start of the street, you really want to compute
"Main Street Origin plus three times (123 Main
Street minus Main Street Origin)."

 

[Sean Kenwrick]

You mean
*k = *k * *j;
In other words, multiply `int's, not pointers to `int's.

Your solution above is correct but can you figure out why the following code
is invalid (which it is):


*k = *k/*j;

assuming k and j are pointers to ints that have been correctly
initialized....

Sean

 

[Ben Pfaff]

Your solution above is correct but can you figure out why the following code
is invalid (which it is):


*k = *k/*j;

There's no way to tell whether it's invalid unless we can see
what follows it.

 

[Jarno A Wuolijoki]

Your solution above is correct but can you figure out why the following code
is invalid (which it is):
*k = *k/*j;

*k = k*//*j;

 

[Jarno A Wuolijoki]

*k = k*//*j;

Should have engaged my brain. It starts a new one, duh.

 

[Joona I Palaste]

Your solution above is correct but can you figure out why the following code
is invalid (which it is):

*k = *k/*j;

assuming k and j are pointers to ints that have been correctly
initialized....

Are you testing our knowledge? The C tokeniser thinks of the /* as the
start of a comment, so it ends up being:
*k = *k
which is a syntax error because the lack of a terminating semicolon.
Were you thinking of using it in some way like this?
*k = *k/*j; /* make sure the value of *k stays in bounds */
+0; /* this is just a dummy */

--
/-- Joona Palaste ([email protected]) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"As a boy, I often dreamed of being a baseball, but now we must go forward, not
backward, upward, not forward, and always whirling, whirling towards freedom!"
- Kang

 

[Barry Schwarz]

Hi,

Why multiplication of pointers is not allowed?
Till now I only know this, but not the reason why!

PS: As a rule, I searched the FAQ, but could not
find an answer.

Adding an int to a pointer results in pointing to something a
specified distance further to the "right" in memory.

Subtracting an int from a pointer results in pointing to something a
specified distance further to the "left" in memory.

Subtracting one pointer from another results in how far apart the two
memory locations are.

If your program and data were to be magically relocated as a unit in
memory, each of the above expressions would still produce the same
result.

Until you can define a concept of either adding two pointers or
multiplying two pointers that meets the constraint in the previous
paragraph, the two operations make no sense. (Hint: others have
thought this through and decided such a definition is either not
possible or of no programming value.)


<<Remove the del for email>>

 

[James Dow Allen]

Why multiplication of pointers is not allowed?

While I've never felt an urge to multiply pointers, there
is a situation where adding them is quite legitimate:
char *rcopy, *q, *r;
. . .
strcpy(rcopy, r);
q = index(r, '*');
. . .
/* Now point to the '*' in the copy */
foobar(rcopy + q - r);
(Please don't write in to tell me I forgot to allocate space for rcopy, etc.
This is just a minimal illustration of the point.)

Although the intermediate expression (rcopy + q) has the illegal form
of (ptr + ptr) the net expression is OK.

I was disappointed when gcc rejected my construction like this, depending
on how I parenthesized it. It seems like it shouldn't be hard to support.

Yes, yes; the better parenthesization would also make the program more
readable. Well nevermind ....

James

 

[August Derleth]

The question Ben is asking is, what would you propose pointer
multiplication do? How would you define the operation? I can't think of
any way in which multiplying a pointer by any other value would be
useful or even meaningful.

The way I reason is like this: If I take i and assign an address to it
(that is, I make it a pointer), i is the name of a block of memory that
holds a certain string of bits or trits or decimal digits that compose
that address. At this layer of abstraction, it's no different from an
int or a float. Since I can multiply two ints and stand a good chance at
getting a meaningful result, why not two pointers? Or an int and a pointer?

Your question is somewhat like asking "why can't I assign to a
function?" or "why can't I take the square root of a struct?" There's
just no logical reason why you *should* be able to.

My response to this is that the compiler shouldn't hold my hand that
much. As Kernighan said, "If you want PL/I, you know where to get it."
In Forth, for example, a pointer is simply a bunch of bits on the stack,
and you can do unto a pointer the same as you can do unto an int or
anything else. The only extra feature is that, if you dereference it,
you stand a good chance of getting something meaningful.

I suppose if I want Forth, I know where to find it.

 

[Flash Gordon]

The way I reason is like this: If I take i and assign an address to it
(that is, I make it a pointer), i is the name of a block of memory
that holds a certain string of bits or trits or decimal digits that
compose that address. At this layer of abstraction, it's no different
from an int or a float. Since I can multiply two ints and stand a good
chance at getting a meaningful result, why not two pointers? Or an int
and a pointer?

An pointer may have more bits than the ALU can cope with (it definitely
does on some implementations) so why make a load of work for the
implementation to do something that makes no sense?

My response to this is that the compiler shouldn't hold my hand that
much. As Kernighan said, "If you want PL/I, you know where to get it."

It's not holding your hand, it's just not providing something that makes
no sense. You can always side-step the limitation by casting the
pointers to long long and multiplying them, although there is no
guarantee that they will actually fit in to a long long.

In Forth, for example, a pointer is simply a bunch of bits on the
stack, and you can do unto a pointer the same as you can do unto an
int or anything else. The only extra feature is that, if you
dereference it, you stand a good chance of getting something
meaningful.

I suppose if I want Forth, I know where to find it.

Indeed.