| Rich Townsend 2004-12-15, 3:57 am |
| James Van Buskirk wrote:
> "James Giles" <jamesgiles@worldnet.att.net> wrote in message
> news:RMOvd.126249$7i4.82612@bgtnsc05-news.ops.worldnet.att.net...
>
>
>
>
> Gack! I was afraid of this... shows what I get for not participating
> in the standardization process... What if E is type default INTEGER
> and D is type default REAL so that they have the same storage size
> and the bit pattern of E corresponds to an SNAN? There have been
> popular processors that by default silently convert SNANs to QNANs
> when passing them through their FPUs. This would change one bit
> of E in this case. Also what if D has holes in it, like a user-
> defined type with internal padding for component alignment or
> external padding for aligning arrays of the structure? Or how
> about 80-bit REALs on x86 machines which occupy 128 bits in memory
> leaving 48 bits of 'hole'?
>
Well blow me down -- I was just about to point out that TRANSFER doesn't
work for derived types, but I thought that I ought to check that this is
the case. And lo and behold, it *does* work for derived types. Anyone
care to explain any restrictions or whatnot that I might need to know
about this new-found functionality?
cheers,
Rich
--
Dr Richard H D Townsend
Bartol Research Institute
University of Delaware
[ Delete VOID for valid email address ]
|