cottrell@NBS-VMS.ARPA (COTTRELL, JAMES) (03/11/86)
/* > >> I'm curious if any commerically available C compilers implement jumps > >> to arbitrary pointers without recourse to assembly language inserts. > > > >Probably not. I think they all wised up. Why don't you? > > Proof of Point 1. From cottrell@nbs, anyway. [That he wouldn't get much sympathy on that point] > I think the only point you've unequivocally demonstrated is the > one on top of... My head? > Don't excuse my anger; you've shed no light on anything except > your ability to spuriously insult someone. Someone, I might add, > who has demonstrated much more intelligence in considering an > intelligent if unusual question than you have for denouncing his > question as stupid. Okay, so I was feeling ornery that day. Funny, HE didn't seem to be as insulted as you are. > Before you denounce his question as stupid, you should consider > it first. Do there exist situations where this is a reasonable > thing to do? And the answer is yes. I don't think so. If you are asking whether there are `problems' that would benefit from this type of treatment, the answer *may* be yes, most likely in some overconstrained system that you are trying to squeeze the last ounce of performance out of. Of course, you could spend a few bucks and buy a faster machine so you wouldn't have to worry about a few jumps/calls/returns etc. If you are asking whether a general purpose programming language should have these features, whether compilers should be made to support them, and whether programmers should be subjected to this construct once again, the answer is unequivocably `*NO*'. > If you don't have the > knowledge/intelligence to realize this, either keep your mouth shut > or ask questions of others to find out where such situations might > be found. Now who's flaming? Other people *did* ask, notably Doug Gwyn. > Just to broaden your knowledge base, such things are quite often > useful in automatically generated programs (such as those generated > by yacc/lex/bc/...). I don't think yacc/lex/bc ever generated constructs misusing the addresses of labels as pointers-to-functions. Probably an old compiler writer at Bell Labs stored labels in the same symbol table as functions without making any distinction. Someone picked up on the coincidence and a bit of underground folk mythology was born. Besides, most programs generated by yacc & lex are I/O bound anyway, so who cares about extra jumps? And BC is just a toy. > That a statement is easily abused by programmers > may not be sufficient reason to eliminate the statement from the > language. ("There does not exist now, and never will exist, a > language in which it is the least bit difficult to write bad > programs" -- who said it? WHY?). Probably Dijkstra. I agree with the above statements. The key words are `may not'. In this case, it was deemed sufficient. The potential for abuse is far greater than the reward. Remember that UNIX makes it painful (no macros) to code in assembly language for just this reason. Why make a nuisance attractive? Besides, that construct was never a part of C anyway. > If it is Dr. Paul Dietz who > wrote the original article, he has often written programs to generate > other programs, and certainly deserves the serious consideration > of those who bother to read his posting. Okay, fair enuf. It's hard to tell the crazys from the people who just think weird (read innovative) thoughts. He was just the last guy who posted and happened to get flamed at. In a more serious tone I would say something like: `That would not be a good idea. Those constructs were never a part of the language and only appeared as an accident of a particular compiler. Don't count on this feature being there in future releases. You can always run a SED script on the assembly language output.' > Robert Herndon > ...!ihnp4!umn-cs!herndon > herndon.umn-cs@csnet-relay.ARPA jim cottrell@nbs */ ------