When is a cast not a cast?

[Hamish Reid]

In article <2920 at buengc.BU.EDU> bph at buengc.bu.edu (Blair P. Houghton) writes:
>In article <2052 at unisoft.UUCP> hamish at unisoft.UUCP (Hamish Reid) writes:
>> 
>>Let's try this just one more time (but see also my other posting
>>answering Blair's more general points):
> ^^^^^^^^^
>And chickens have lips like Barbara Hershey...
>
>>Blair	- what is the type of the result of subtracting one pointer
>>	from another?
>
>What color are they?  Is it significant?  Will it overflow?

It's called not answering the questions.... Quick!! Look up there!!

>>	[Hint: As the original poster (Tobin?) pointed out, it's not a
>>	char *, nor is it really well-defined).]
>
>Original poster?  T'was me.  All I did was *(pointer + (sametype *) integer)
>and discovered something I'd never noticed before.

No. The original poster of the example you picked up and ran with was
Richard Tobin, article <406 at skye.ed.ac.uk>; it's a shame you didn't
read the fine print attached to that example (the one involving 't')
before you bought it...

>As I recall, Mr. Tobin described a hypothetical 3-bit machine to argue
>_against_ my position, then you claimed (see your other, more pedantic
>posting) that I was describing hypothetical implementations in order
>to _support_ my position...

No. You got all of this wrong too. Bjorn Engsig, in article
<334.nlhp3 at oracle.nl> described the hypothetical 3-bit machine; I said
that appeals to "loop optimisations" (etc) were irrelevant - in a
direct reference to one of your earlier reasons for allowing pointer
addition. Credit where credit's due... but then we haven't exactly come
to expect accuracy, thought, precision or even a bit of research in
postings from the Blair P. Houghton we've all come to know and
loathe...

And in article <2919 at buengc.BU.EDU>:

>>Blair, a constructive challenge:

>>Post, to this newsgroup, a formal semantics definition of some proposed

>For a semanticist or a professional computer scientist (of which I doubt
>many have the time to be wasting on this sort of thing... :) maybe, neither
>of which I am.  I'm just a C-coding hacknut with a yen to see two pointers
>added together.

Clearly. I wouldn't be too proud of that fact if I were you. And you're
dead right - none of us professional compiler-writers, semanticists,
etc, would waste our time on trying to add pointer addition, in the way
you describe, to C.

>I merely came up with an idea.  It's up to the professionals to come up
>with reasons that it is viable.

And every time one of "the professionals" tells you why it's not a
good idea, you say they have the mind of a four-year-old, they're a
load of casual rom-bats, or they need to consult a second grade
teacher, etc.... Blair, you're not listening...

>Barring that, I'd do with an explanation of the decision to nonimplement
>it from those who made the decision, not a load of folk-etymological
>crapola from a load of casual rom-bats.

If you'd been *listening*, you might have heard the explanations from
exactly those who made the decisions. True, not all of us who have to
implement and define C can take the time to patiently explain, again
and again, why you are barking up the wrong tree. BTW, you display an
extraordinary level of certainty for a self-confessed neophyte - do you
know something about compiler writing, language definition, formal
semantics, etc, that the collected wisdom of the net doesn't? And that
the compiler-writers, professional computer scientists, C semanticists
(etc) that you've been arguing at don't? Not bloody likely....

>They do put 'rationale' in with standards, you know.

And it's clear you've never read them, let alone understood them....

Anyway, as promised earlier, I'm going to be a spoil-sport and bow out
now. Got too much formal C definition and compiler work to do, ya
know... and too little time to talk to brick-wall-like posters. Blair,
are you perhaps some sort of Artificial Stupidity program trying to
test us all?

	Hamish
-----------------------------------------------------------------------------
Hamish Reid             UniSoft Corp, 6121 Hollis St, Emeryville CA 94608 USA
+1-415-420-6400         hamish at unisoft.com,         ...!uunet!unisoft!hamish