Multiplication or Division of pointer is not supported by C language

[karthikbalaguru]

Hi,

C states that Multiplication or Division of a pointer is not allowed .
If they are able to support addition & subtraction, but why
haven't they supported multiplication or division of a pointer ?
Any difficulty in supporting those functionalities ?
Will it be available in the future releases ?

Thx in advans,
Karthik Balaguru

 

[Richard Tobin]

C states that Multiplication or Division of a pointer is not allowed .
If they are able to support addition & subtraction,

*If* you could add two pointers, it would be hard to see why
multiplication by an integer would not be allowed. But it's not true.
You can't add two pointers. You can add an integer to a pointer, but
then the analogy no longer holds.

There are a few cases where more operations on pointers would be
useful (e.g. it makes perfect sense to take the average of two
pointers when doing a binary search), but they were not considered
worth the mechanism needed to support them. Consider what the type
of the difference of two pointers is, and then consider what the
type of the sum would be.

-- Richard

 

[Antoninus Twink]

First, you have to think of something that the product
of two pointers might mean.

It's surprising that Bjarn Strostroup didn't find some counter-intuitive
and confusing interpretation of an overloaded multiplication operator on
pointers - if he couldn't do it, who else can?...

 

[Bartc]

Hi,

C states that Multiplication or Division of a pointer is not allowed .
If they are able to support addition & subtraction, but why
haven't they supported multiplication or division of a pointer ?
Any difficulty in supporting those functionalities ?
Will it be available in the future releases ?

Multiply and divide are available now for pointers, although you need to
specify a base value:

int *p, *q, *base;
....
q = p * n; /* Now allowed directly */

q = (p - base) *n + base;

As for usefulness: if A is an int array, and base points to A[0] and p to
any element, then this is no different to index arithmetic.

 

[Mark Wooding]

If they are able to support addition & subtraction, but why
haven't they supported multiplication or division of a pointer ?
Any difficulty in supporting those functionalities ?

There's a difficulty of definition. Let's start with the pointer
arithmetic that we /can/ do:

* we can add integers to (and subtract them from) pointers; and
* we can subtract one pointer from another (sometimes).

This addition fails to be associative, however:

p + (q - r)

is well-defined (if p, q, r are pointers, and q and r are within or
one-past-the-end of the same object), but

(p + q) - r

is meaningless. Note also that there is no such thing as an additive
inverse for pointers: although p - p = 0 for all (valid) pointers to
objects, the notation -p is not meaningful.

(Aside: is there a name for this kind of algebraic structure? I
wouldn't be at all surprised if it weren't considered interesting enough
to have a name, but it'd be nice to know for sure. ;-) )

So, what kind of multiplication do we want? To be useful, a
multiplication ought to be distributive over addition, and 1 ought to be
a scalar-multiplicative identity, so

2*p = (1 + 1)*p = 1*p + 1*p = p + p

which is still without meaning. So that's out.

What about multiplying two pointers? Umm, well:

(p + 2)*q = p*q + 2*q

but we've already decided that 2*q wasn't meaningful. So that's out.

As for division, let's get multiplication sorted first, shall we?

-- [mdw]

 

[Keith Thompson]

C states that Multiplication or Division of a pointer is not allowed .
If they are able to support addition & subtraction, but why
haven't they supported multiplication or division of a pointer ?
Any difficulty in supporting those functionalities ?
Will it be available in the future releases ?

Only operations that make sense are supported:

Adding an integer and a pointer, or a pointer and an integer,
yields a pointer (the integer specifies the offset from the
original address); this is valid only of the old and new pointer
values point into the same object or just past the end of it.

Subtracting a pointer from a pointer yields an integer; this is
valid only if both pointers point into the same object or just
past the end of it.

Adding two pointers doesn't mean anything. Multiplying or
dividing two pointers doesn't mean anything.

Just because some operations exist for a type, that doesn't mean we
should implement other operations for that type. It probably wouldn't
be difficult to implement pointer multiplication or division in a C
compiler; that's not the issue. The problem is that, if it were
implemented, programmers would be able to use it -- and that would be
A Bad Thing.

 

[Keith Thompson]

Multiply and divide are available now for pointers, although you need to
specify a base value:

int *p, *q, *base;
...
q = p * n; /* Now allowed directly */

I hope you meant "*Not* allowed directly".

q = (p - base) *n + base;

Yeah, but that's not really multiplication of pointers.

As for usefulness: if A is an int array, and base points to A[0] and p
to any element, then this is no different to index arithmetic.

Right.

 

[Bartc]

Multiply and divide are available now for pointers, although you need to
specify a base value:

int *p, *q, *base;
...
q = p * n; /* Now allowed directly */

Or rather, Not allowed.

--

 

[jameskuyper]

Hi,

C states that Multiplication or Division of a pointer is not allowed .
If they are able to support addition & subtraction, but why
haven't they supported multiplication or division of a pointer ?
Any difficulty in supporting those functionalities ?
Will it be available in the future releases ?

On systems where pointers have a simple relationship to addresses in a
linear address space, you can probably get exactly what you're looking
for just by converting the pointers to intptr_t before carrying out
the mathematical operations. It's not portable, but neither is the
concept that you're trying to get implemented.

In the more general case, addition, multiplication, and division of
two pointers is a meaningless concept. Addition or subtraction of an
integer to a pointer already has a well defined meaning; most other
operations between pointers and integers are manifestly meaningless.

However, there's one operation that might usefully supported: pointer
% integer:

char c[2*sizeof(short)];
char *pointer = c+sizeof(short);

ptrdiff_t remainder = pointer % align_of(short);
pointer -= remainder;
short *ps = (short*)pointer;

The result of the % operation would be such that the code given above
would result in ps containing a value that points at a location
correctly aligned to store a 'short'. Such a feature would be pretty
much useless without an align_of() operator also being added to the
language.

 

[Guest]

     First, you have to think of something that the product
of two pointers might mean.  I'll now indulge in analogy ...

     Think of a pointer value as a street address, something
like "124 Elm Street."  Adding six, say, to this address gives
"130 Elm Street," another address that makes sense.  Subtracting
four gives "120 Elm Street," also a sensible outcome.  You can
even subtract two addresses on the same street: "415 Elm Street"
minus "395 Elm Street" gives twenty, which you can interpret as
the "distance" between the addresses.  Observe that subtracting
"318 Elm Street" minus "79 Wistful Vista" is useless: The two
streets have independent numbering systems and the result (whatever
it might look like) wouldn't mean much.  C's pointers are like this,
too: It only makes sense to subtract pointers that are based in the
same object.

     BUT: What would other operations mean?  Adding two pointers
doesn't seem to make sense ("100 Elm Street" plus "120 Elm Street"
might give "220 Elmelm Streetstreet," but I don't think you'd find
it on Google Maps).  Multiplying a pointer by a scalar requires
you to invent a meaning for "20 Main Street" times three, a
meaning more sensible than "60 Mainmainmain Streetstreetstreet".
Multiplying two pointers is even more questionable: The product
of "1600 Pennsylvania Avenue" and "10 Downing Street" is just
meaningless hot air, or so the bloggers say.

     What is "221B Baker Street" divided by "Wisteria Lodge," and
is there a remainder?

     This isn't to say that multiplication and division are
undefinable for all systems of "locators."  Two completely
different kinds of multiplication are commonly used in vector
algebra, and division (in the sense of multiplication by an
inverse) can also be defined.  But C's pointers don't seem to
have an underlying structure that would support such notions
in a useful way ...  If you invent one and it turns out to be
useful, you will probably become famous.

But, but, but.. Richard-I-single-step-all-my-code says that pointers
are addresses are integers and you multiply integers so you *must* be
able to multiply pointers!

This utility function may be handy

/* multiply two addresses together */
void *addresses_product (void *a1, void *a2)
{
/* use long to hold the 32-bit address */
return (void*)((long)a1 * (long)a2);
}

 

[Dik T. Winter]

> There are a few cases where more operations on pointers would be
> useful (e.g. it makes perfect sense to take the average of two
> pointers when doing a binary search)

p1 + (p2 - p1)/2

On the other hand, naive adding two pointers and dividing by 2 would not
result in a valid pointer on some machines.

 

[Dik T. Winter]

> This addition fails to be associative, however:
> p + (q - r)
> is well-defined (if p, q, r are pointers, and q and r are within or
> one-past-the-end of the same object), but
> (p + q) - r
> is meaningless. Note also that there is no such thing as an additive
> inverse for pointers: although p - p = 0 for all (valid) pointers to
> objects, the notation -p is not meaningful.
>
> (Aside: is there a name for this kind of algebraic structure? I
> wouldn't be at all surprised if it weren't considered interesting enough
> to have a name, but it'd be nice to know for sure. ;-) )

No, at least associativity is required to make it a monoid.

 

[Richard]

But, but, but.. Richard-I-single-step-all-my-code says that pointers
are addresses are integers and you multiply integers so you *must* be
able to multiply pointers!

Would you like to quote that with context please.

Or are you being typically ignorant and small minded?

 

[Ben Bacarisse]

No, at least associativity is required to make it a monoid.

and a monoid is closed under its (single) operation. Here we have two
sets and two related operations (-: P -> P -> Z and a commutative +: P
-> Z -> P). I bet it has a name in category theory -- everything else
seems to have a name in category theory.

 

[Kojak]

Le Wed, 04 Mar 2009 12:42:30 +0000,
Ben Bacarisse a écrit :

and a monoid is closed under its (single) operation. Here we have two
sets and two related operations (-: P -> P -> Z and a commutative +: P
-> Z -> P). I bet it has a name in category theory -- everything else
seems to have a name in category theory.

Say, a "pointoid".

Sorry, :-D

 

[Richard Tobin]

p1 + (p2 - p1)/2

Of course I know you can do it like that, which is why I said that
those operations were not considered worth the mechanism needed to
support them. I was just pointing out that the operations are
not meaningless or even useless.

On the other hand, naive adding two pointers and dividing by 2 would not
result in a valid pointer on some machines.

It would require some shifting or masking, just as the subtraction in
your expression above can't be done naively.

-- Richard

 

[Dik T. Winter]

>
> It would require some shifting or masking, just as the subtraction in
> your expression above can't be done naively.

Suppose a system with the data address space starting at 0x80000000.
Assume p1 and p2 to be char pointers. In that case the first can be
implemented naively while the second can not.

 

[Richard Tobin]

Suppose a system with the data address space starting at 0x80000000.
Assume p1 and p2 to be char pointers. In that case the first can be
implemented naively while the second can not.

True, I hadn't considered overflow.

-- Richard

 

[Nate Eldredge]

There's a difficulty of definition. Let's start with the pointer
arithmetic that we /can/ do:

* we can add integers to (and subtract them from) pointers; and
* we can subtract one pointer from another (sometimes).

This addition fails to be associative, however:

p + (q - r)

is well-defined (if p, q, r are pointers, and q and r are within or
one-past-the-end of the same object), but

(p + q) - r

is meaningless. Note also that there is no such thing as an additive
inverse for pointers: although p - p = 0 for all (valid) pointers to
objects, the notation -p is not meaningful.

(Aside: is there a name for this kind of algebraic structure? I
wouldn't be at all surprised if it weren't considered interesting enough
to have a name, but it'd be nice to know for sure. ;-) )

An affine space is pretty close.

http://en.wikipedia.org/wiki/Affine_space

In our case, I guess we should replace the vector space V in the
definition by a ring (the integers, or the integers mod (size_t)-1 or
something).

A simple example of an affine space in geometry is a plane in R^3 not
passing through the origin.

 

[Mark Wooding]

So, p+i is shorthand for p_base + (p_offset + i). Pointer
differences are only defined if they share the same base. So p-q
is shorthand for common_base + (p_offset - q_offset).

Quibble: p - q is short for (p_offset - q_offset) if they have a common
base. The result is an integer, not another pointer. (Probably a
braino, but worth pointing out.)

Of course we don't have to go through any such mental gyrations
when writing code, but it is a way of explaining what is going on
with pointer arithmetic.

Indeed. Your explanation was much clearer than mine: thanks.

-- [mdw]