Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!ucbvax!decwrl!decvax!ima!haddock!karl
From: karl@haddock.ima.isc.com (Karl Heuer)
Newsgroups: comp.lang.c
Subject: Re: When is a cast not a cast?
Message-ID: <13235@haddock.ima.isc.com>
Date: 20 May 89 23:21:17 GMT
References: <2747@buengc.BU.EDU> <10191@smoke.BRL.MIL> <406@skye.ed.ac.uk> <10276@smoke.BRL.MIL> <2890@buengc.BU.EDU> <546@TSfR.UUCP> <2908@buengc.BU.EDU> <13189@haddock.ima.isc.com> <2922@buengc.BU.EDU>
Reply-To: karl@haddock.ima.isc.com (Karl Heuer)
Organization: Interactive Systems, Boston
Lines: 26

In article <2922@buengc.BU.EDU> bph@buengc.bu.edu (Blair P. Houghton) writes:
>Could it be that adding pointers creates different things, as multiplying
>lengths creates areas?  Maybe.

Aha, maybe now we're getting somewhere.  I was hoping you'd realize that, if
this concept makes any sense at all, it would have to generate a new type, a
ptrsum_t.  Now, if you want to argue that ptrsum_t should exist (its major
property being that you can subtract a pointer from it and get a pointer, and
perhaps also allowing ptrsum_t/2 --> pointer), then I'll be much more
supportive than if you continue the false analogy of ptr+int vs float+int.

Even so, there's a lot of work that would need to be done to make this useful
to portable programs.  It's my opinion that it probably can't be done, and
even if it can, that it's not worth the effort.  If you'd like to prove me
wrong, go ahead.

In another article,
>And you whining toadies who do it so smugly don't give a flying fractal
>whether you cripple the language while you're at it.  Who's righter?

I think that someone who proposes that we
>make it necessary to do pointer+(pointer_type *)int to get the
>current functionality of pointer+int,
should not be one to accuse others of crippling the language.

Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint