Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!husc6!bu-cs!buengc!bph
From: bph@buengc.BU.EDU (Blair P. Houghton)
Newsgroups: comp.lang.c
Subject: Re: When is a cast not a cast?
Message-ID: <2906@buengc.BU.EDU>
Date: 18 May 89 19:41:58 GMT
References: <2747@buengc.BU.EDU> <10191@smoke.BRL.MIL> <406@skye.ed.ac.uk> <2890@buengc.BU.EDU> <17569@mimsy.UUCP>
Reply-To: bph@buengc.bu.edu (Blair P. Houghton)
Followup-To: comp.lang.c
Organization: Boston Univ. Col. of Eng.
Lines: 51

In article <17569@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes:
>In article <2890@buengc.BU.EDU> bph@buengc.BU.EDU (Blair P. Houghton) writes:
[argument for allowing pointer addition so we can hand-optimize a loop]
>
>I cannot think of a realistic example of this.

And I don't know why we need arrays at all...or Pascal, for that matter.
:-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-)

>Anyway, consider another argument against pointer+pointer addition:
>
>Suppose we have a segmented architecture, in which each object is
>always placed in its own segment (which is made just big enough to
[...continues to argue that adding pointers may result in segment-end
overrun...]

You're using an architecture to specify C.  Is that not a no-no?

As I think earlier foistings on this thread have illustrated, it
is fallacious to expect that pointers point into an identifiable,
or even coherent, memory space.  If I put together a string, say
"foobazz", and my compiler puts the `foo' on this Encore and stores
the `bazz\0' on a Sun at CMU, but can still find it when it comes
time to dereference 5["foobazz"], then that's legal C.  Awful, slow,
unreliable, and insane, maybe.  Still C.  If it decides to store
it as `f z o z o a b \0', then it's still C, as long as

	char *a="foobazz";
	printf("%s",a);

still emits `foobazz'.

You're using C for assembly-language operations if you worry about
segmentation at all.

Further, the examples you give are not limited to pointer+pointer
arithmetic.  They'd result in over/underflow even if done in
proper pointer+int form.

>is possible---even likely---that integer operations will not produce
>the proper result, so that p+q (and (p+q)-q) cannot be done as an
>unsigned integer add, and might well cost a library call to avoid
>overflow traps, sending your hypothetical speed advantage right down
>the sewer.

The same would be true if we were trying to add unsigned integers
that weren't pointers at all.  Or a couple of really big floats...

				--Blair
				  "Really big.  Bigger than the
				   ones in the Rose Parade..."