Jumped Conclusions

[COTTRELL, JAMES]

/* 
>  >> 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 at 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 at csnet-relay.ARPA

	jim		cottrell at nbs
*/
------