When is a cast not a cast?

[Blair P. Houghton]

In article <546 at TSfR.UUCP> orc at TSfR.UUCP (David L. Parsons) writes:
>In article <2890 at buengc.BU.EDU> bph at buengc.bu.edu (Blair P. Houghton) writes:
>[more discussion of the properties of pointer+pointer]
>>
>>>What can one legally do with it?
>>
>>What one can legally do between (consenting) integers?

[...uses the fact that pointer-pointer now returns int to show how
associativity of pointer addition would break if we allowed pointer+pointer...]

So, like, make pointer-pointer return the pointer.

make it necessary to do pointer+(pointer_type *)int to get the
current functionality of pointer+int, but leave it possible to
have an implicit cast (i.e. an automatic promotion) when adding
pointers and integers.  All that stuff about float+int could
apply to pointer+int.

>  What does pointer+pointer give you, aside from clever loop optimizations?

Hey.  It's arcane.  So is calloc().  Then you find somewhere to use it,
and you're hopping with joy.  Jeez.  What does C give you, aside from
not being Pascal?

Allowing pointer addition and treating pointers as types would make
pointer arithmetic a consistent thing.  I spent a long time thinking
it was, and never wrote any code that broke because of it, because
I'd never seen a need to use pointer+pointer, and was satisfied
with what pointer+int_as_offset.  I also didn't use casts at all for
the first few years, not having found a need for them.  I'm only
now getting into doing my own multiple-file programs.  I didn't see
a need for it, though others did.  So, one of these days I'll find
a situation, some few examples of which we've seen already, where I
will really want to do pointer+pointer without having to go through
(unsigned_int) pointer + (unsigned int) pointer.

				--Blair
				  "or is that
				   (signed) --Blair"