Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!gem.mps.ohio-state.edu!brutus.cs.uiuc.edu!usc!orion.oac.uci.edu!uci-ics!ucla-cs!math.ucla.edu!sonia!pmontgom
From: pmontgom@sonia.math.ucla.edu (Peter Montgomery)
Newsgroups: comp.lang.fortran
Subject: Re: Type punning in C
Message-ID: <1874@sunset.MATH.UCLA.EDU>
Date: 14 Oct 89 03:25:22 GMT
References: <475@idacrd.UUCP> <1989Oct10.185851.6490@agate.berkeley.edu> <1989Oct11.091619.18336@gdt.bath.ac.uk> <1654@l.cc.purdue.edu> <1989Oct13.090311.9760@gdt.bath.ac.uk>
Sender: news@MATH.UCLA.EDU
Reply-To: pmontgom@math.ucla.edu (Peter Montgomery)
Organization: UCLA Mathematics Department
Lines: 27

In article <1989Oct13.090311.9760@gdt.bath.ac.uk> exspes@gdr.bath.ac.uk 
(P E Smee) writes:
>
>The need for a construct to permit type punning is clear, particularly
>if you're doing 'systemmy' work.  
>
>This provides an explicit instruction to the compiler, and (more
>importantly) a warning to future maintainers of the code, that you are
>about to willfully, knowledgeably, and intentionally, cheat the data
>typing and conversion rules.  Every serious language should have such a
>thing.  (Unfortunately, it seems that most don't, sigh...)
>
	If I read the June, 1989 draft F8X correctly, then the
new TRANSFER intrinsic function (p. 13-51, section 13.13.108)
will do precisely this.  The syntax is

	result = TRANSFER(SOURCE, MOLD, SIZE) .

It "returns a result with a physical representation identical to that
of SOURCE but interpreted with the type and type parameters of MOLD."
The last argument, SIZE, is optional and affects the array shape
of the result when SOURCE and MOLD have different sizes
(e.g., double precision and character).

--------
        Peter Montgomery
        pmontgom@MATH.UCLA.EDU