Path: utzoo!utgpu!watmath!iuvax!ux1.cso.uiuc.edu!ux1.cso.uiuc.edu!uxe.cso.uiuc.edu!hirchert
From: hirchert@uxe.cso.uiuc.edu
Newsgroups: comp.lang.fortran
Subject: Re: Type punning in FORTRAN (was in
Message-ID: <50500157@uxe.cso.uiuc.edu>
Date: 20 Oct 89 16:36:00 GMT
References: <891@acf5.NYU.EDU>
Lines: 41
Nf-ID: #R:acf5.NYU.EDU:891:uxe.cso.uiuc.edu:50500157:000:2615
Nf-From: uxe.cso.uiuc.edu!hirchert    Oct 20 11:36:00 1989


Note that FORTRAN is nominally a (semi-)portable language for computation, not
system programming.  In general, if it is not possible to portably predict
the result of an action (or at least a portable framework for those results),
that action is likely to have been prohibited by the standard.  In the case
of type "punning", the result could either be a merely unpredictable value or
a value that would cause the processor to abort (e.g. an IEEE NaN).  Since
standard FORTRAN has no mechanism for handling exceptions, the standard
disallows the use of storage association to do type "punning".  In practice,
FORTRAN compilers rarely, if ever, directly enforce this prohibition.  However,
some optimizers do not see the use of a variable of one type as being
related to the definition of a storage associated variable if the latter
variable is of an unrelated type.  This can make type "punning" by
EQUIVALENCE unreliable.

In the proposed Fortran 8x draft, an explicit intrinsic TRANSFER has been
provided for type "punning".  This provides an optimizer with the connection
between its input value and the output value.  It also serves to warn future
readers that "dangerous" things are being done.  (EQUIVALENCE can be used in
either "safe" or "dangerous" ways.)

A previous post suggested that "punning" by EQUIVALENCE might be more efficient
than by the TRANSFER intrinsic.  If properly implemented, the reverse should
be true.  To do "punning" by EQUIVALENCE, there must be an EQUIVALENCE between
the object containing the input value and an object of the output type.  If
the input value could come from an arbitrary (or at least widely varied)
source, it may not be possible to have every possible source so EQUIVALENCEd,
and it may be necessary to copy the input from its original source to a
variable that has been appropriately EQUIVALENCEd.  TRANSFER, on the other
hand, if implemented as an in-line function, allows the compiler to look at
the input value in a new, wherever it is, and thus should not require copying
in these cases.  (This is in contrast with TRANSFER-like procedures 
implemented as external procedures.  These nearly always require copying and
thus can be expected to be less than either EQUIVALENCE "punning" or an
intrinsic TRANSFER.)

Another post asked about the relation between TRANSFER and various APL
functionalities.  Fortran 8x has separate facilities for reshaping arrays,
so it is not expected TRANSFER would be used for that purpose.  Fortran 8x
has separate facilities for extracting subarrays of an array.  TRANSFER was
intended only for type "punning" or "casting".