Where to find the exact requirement of the operand for C operators?

[Eric Sosman]

Lew Pitcher wrote On 05/07/07 14:35,:

[... concerning arbitrary arithmetic on pointers ...]
Answer these questions, and you'll understand the meaning of the error
message and some of the limits of the operands of the binary
operations.

For even more insight, frame your answers in terms of
a machine whose addresses look like "221B Baker Street,"
"1600 Pennsylvania Avenue," and "79 Wistful Vista."

You misspelled "Wasteful" in the last address...

"Don't open that door!"

http://www.geocities.com/Hollywood/Hills/5284/

 

[Peter Nilsson]

...
By declining to define "unnecessary" operations on
pointers today, C leaves open the possibility of providing
definitions for them tomorrow when more is known about what
might be useful.

"No, they just didn't like it very much."
-- Zaphod Beeblebrox

 

[Richard Tobin]

Of course I'm not seriously suggesting this, but... I don't think
it would be difficult in cases where it makes sense. Sure, adding
two pointers to different objects then dividing by two to get the
average would not work on machines where each object has an
address with a different segment part, but then that operation
doesn't make sense anyway. But doing it with two pointers into
the same array *does* make sense - it's the sort of operation used
in a binary search - and would be no harder to implement than the
things that already have to work, such as array indexing.

And, if you bothered to read the standard, is specifically allowed.[/QUOTE]

What is, adding pointers and then dividing by two?

And again, if you bothered to read the standard, is specifically
disallowed.

I think you have completely misunderstood this conversation.

-- Richard

 

[Thad Smith]

Rudolf said:

No such program has ever run to completion, so the point is moot. But in
any case, the behaviour of such a program would be undefined, whether
or not it terminates.

The previous poster seems to be pulling our leg(s). Using interactive
I/O, one can indeed write a program that has behavior defined by the
standard. The standard says nothing of the timing, of course. A
suitable implementation must be chosen for that aspect.

 

[Kenneth Brody]

Interesting. How was `x' declared? ;-)

That part of the design has not been completed yet. In keeping with
C's inside-out declarations, we might have for example:

char *x/2;

indicating that x/2 is a char *.[/QUOTE]

So, what is the result of:

x = $221B Baker Street$ + $1600 Washington Street$;
printf("half of x is %p\n", x/2);



--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:[email protected]>

 

[Kenneth Brody]

Richard Tobin wrote:
[...]

Of course I'm not seriously suggesting this, but... I don't think it
would be difficult in cases where it makes sense. Sure, adding two
pointers to different objects then dividing by two to get the average
would not work on machines where each object has an address with a
different segment part, but then that operation doesn't make sense
anyway. But doing it with two pointers into the same array *does*
make sense

You can already do this, by adding half the difference, which makes
more sense than adding two addresses. Sure, adding two addresses
and dividing by two to get the "average" address may make sense as
a complete operation, but what is the intermediate result of the
addition of two addresses?

And, while we're at it, what about multiplying or dividing two
pointers? (Why limit it to addition?)

[...]

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:[email protected]>

 

[Dave Vandervies]

So, what is the result of:

x = $221B Baker Street$ + $1600 Washington Street$;
printf("half of x is %p\n", x/2);

--------
half of x is $somewhere in the Atlantic Ocean$
--------
, obviously. What ELSE would you expect it to be?


dave
(maybe lat/long?)

 

[Christopher Benson-Manica]

So, what is the result of:

x = $221B Baker Street$ + $1600 Washington Street$;
printf("half of x is %p\n", x/2);

$Gordon Brown$ ?

 

[Richard Bos]

$Gordon Brown$ ?

I support Gordon Brown for Prime Minister... for the new Free State of
Scotland, which will inevitably be brought up again after the latest
elections.

Richard

 

[Army1987]

Interesting. How was `x' declared? ;-)

That part of the design has not been completed yet. In keeping with
C's inside-out declarations, we might have for example:

char *x/2;

indicating that x/2 is a char *.[/QUOTE]

<visionary>
No. It indicates that (*x)/2 is a char. You meant char *(x/2).
Your declaration indicates that x points to a type able to contain
all even integers from 2*CHAR_MIN to 2*CHAR_MAX.
</visionary>
<uncyclopedia>
Adding two pointers is not legal, but adding a pointer and an
integer is. (The surprising thing is that it's commutative, as
expressions such as 9[array] show.) You can subtract an integer
from a pointer getting a pointer, and can subtract a pointer from
a pointer giving an integer (ptrdiff_t). In fancier language,
pointers form an affine space over integers. Therefore, any affine
combination of pointers (that is, a linear combination of pointers
which coefficients summing to exactly 1) makes sense. What doesn't
make sense is adding a pointer to an integer (rather than
viceversa), but this is allowed in C.
</uncyclopedia>

 

[Army1987]

The argument that (pointer * integer) is invalid because it can't
possibly make any sense is ironclad, because the language *could* have
defined such constructs. [...]

("Is ironclad" corrected to "is not ironclad" elsethread.)

It's not hard to imagine a formal underpinning for pointers
that would allow multiplication by an integer, or even by a
floating-point number. By thinking of a pointer as a vector --
and really now, what could be more natural? -- we can even get
multiplication of two pointer operands in at least two different
ways, corresponding to dot-product and cross-product.

But C's pointers aren't vectors: they are more abstract.

As I pointed out elsethread, they are elements of an affine space
over ptrdiff_t.
http://en.wikipedia.org/wiki/Affine_space
(Actually, only pointers to elements of a same array or to one cell
past the end of an array are required to be in the same affine
space.)
<seriousness level="slightly more">
Suppose I have an array int a[MAX][MAX] and pointers int *p =
&a[0][0], *q = &a[1][0]. p + MAX is required by the standard to be
OK, and it equals q. Now q+1 equals &a[1][1] (or there would be no
way for multidimensional arrays to work).
Now I read in the FAQ 6.19 that p + (MAX + 1) is UB, and yet
I've just shown that (p + MAX) + 1 is OK.
Is there anything I am missing?
</seriousness>

 

[Eric Sosman]

<seriousness level="slightly more">
Suppose I have an array int a[MAX][MAX] and pointers int *p =
&a[0][0], *q = &a[1][0]. p + MAX is required by the standard to be
OK, and it equals q. Now q+1 equals &a[1][1] (or there would be no
way for multidimensional arrays to work).
Now I read in the FAQ 6.19 that p + (MAX + 1) is UB, and yet
I've just shown that (p + MAX) + 1 is OK.
Is there anything I am missing?
</seriousness>

A sense of proportion?