Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!unisoft!hamish From: hamish@unisoft.UUCP (Hamish Reid) Newsgroups: comp.lang.c Subject: Re: When is a cast not a cast? Message-ID: <2058@unisoft.UUCP> Date: 21 May 89 03:28:29 GMT References: <2747@buengc.BU.EDU> <10191@smoke.BRL.MIL> <406@skye.ed.ac.uk> <10276@smoke.BRL.MIL> <2890@buengc.BU.EDU> <2052@unisoft.UUCP> <2920@buengc.BU.EDU> Reply-To: hamish@unisoft.UUCP (Hamish Reid) Lines: 93 In article <2920@buengc.BU.EDU> bph@buengc.bu.edu (Blair P. Houghton) writes: >In article <2052@unisoft.UUCP> hamish@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@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@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@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@unisoft.com, ...!uunet!unisoft!hamish