Type punning in C
Richard O'Keefe
ok at cs.mu.oz.au
Fri Oct 13 16:01:22 AEST 1989
In article <4055 at deimos.cis.ksu.edu>, mac at harris.cis.ksu.edu (Myron A. Calhoun) writes:
: In article <1654 at l.cc.purdue.edu> cik at l.cc.purdue.edu (Herman Rubin) writes:
: >This is another example of those "gurus" who can not envision an intelligent
: >user using the machine in an intelligent manner, and prevent that use. I
: >have deliberately used "type punning" on various machines, and I consider it
: >an extremely useful tool.....
: I agree wholeheartedly. FORTRAN doesn't have PL/1's UNSPEC verb, yet
: I have had occasion to want it. And EQUIVALENCE provided it.
: Calling a subroutine with "wrong" type parameters can also work:
: CALL NEWTYP (INTEGER,...)
: :::::
: SUBROUTINE NEWTYP (REAL,...)
I shall try to tell you what the point is in words that have but one
sound in them. Those who write books that say what a tool like C means
want to help you make tools that can be used on more than one box.
I shall say it one more time: "that can be used on more than one box".
A type pun is all but sure to work on at most one box. This means that
those who write books that say what a tool like C means MUST tell you
not to trust type puns. This does not mean that type puns will not
work on your box. It just means that those who write books that say
what a tool like C means had to tell you that it might not work. They
could not rule that the same pun must work on each box, since they do
not tell those who make each box what to do. Nor do they tell YOU
what to do, just what you can TRUST. If a type pun works on your box,
use it, but keep in mind that it may not work on aught else.
[PS: UNSPEC is not a "verb" in PL/I, it is a "pseudo-function", and
it is very far from being portable. It's a _major_ pain when trying
to port PL/I programs.
]
More information about the Comp.lang.c
mailing list