Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!rpi!batcomputer!munnari.oz.au!bruce!goanna!ok
From: ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe)
Newsgroups: comp.lang.fortran
Subject: Re: Cheating on the types
Message-ID: <5020@goanna.cs.rmit.oz.au>
Date: 21 Mar 91 04:27:11 GMT
References: <1991Mar20.195732.15376@appmag.com>
Organization: Comp Sci, RMIT, Melbourne, Australia
Lines: 36

In article <1991Mar20.195732.15376@appmag.com>, pa@appmag.com (Pierre Asselin) writes:
>      program wrong
>        real rin, rout
>        rin = 0.577215665          ! or whatever...
>        call icopy(rin, rout)
>        write(6,*) rout
>      end

>      subroutine icopy(iin, iout)
>        integer iin, iout
>        iout = iin
>        return
>      end
> 
> Seems fairly innocuous, though.  Q:  are there implementations
> where it would fail?

Yes.
1.  I know it's non-Standard, but there are several compilers where
    the default size for integer is INTEGER*2.
2.  On the B6700, integers and floats used the same representation,
    but integer assignments forced the result to integer form, just
    in case.  The code for icopy would be something like
	VALC (3,2)		; fetch value of IIN
	IRND			; round to integer
	NAME (3,3)		; fetch address of IOUT
	STOD			; store
    (I _know_ the details are wrong.  Concentrate on the idea.)
    This would result in the value 1.0 being stored in ROUT.
3.  I don't know whether the Symbolics Fortran compiler did this,
    but it _could_ have:  on a tagged machine where integers and
    floats have different tags, one would expect the compiler to
    plant code to check that IIN has an "integer" tag.

-- 
Seen from an MVS perspective, UNIX and MS-DOS are hard to tell apart.