Newsgroups: comp.lang.fortran
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!m.cs.uiuc.edu!ux1.cso.uiuc.edu!hirchert
From: hirchert@ncsa.uiuc.edu (Kurt Hirchert)
Subject: Re: Cheating on the types
Message-ID: <1991Mar28.222024.2221@ncsa.uiuc.edu>
Originator: hirchert@mars
Sender: usenet@ux1.cso.uiuc.edu (News)
Organization: Nat'l Ctr for Supercomp App (NCSA) @ University of Illinois
References: <1991Mar20.195732.15376@appmag.com>
Date: Thu, 28 Mar 1991 22:20:24 GMT
Lines: 35

In article <1991Mar20.195732.15376@appmag.com> pa@appmag.com (Pierre Asselin) writes:
>This simplified fragment violates the standard by passing reals to a
>routine that expects integers.
>
>      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 ?

One of the early FORTRAN implementations for the IBM 360 line used decimal
arithmetic rather than binary arithmetic for integer variables and
computation.  In that implementation, the above program would have died
with a machine interrupt because the "integer" iout would have contained
bit patterns that were not valid decimal digits.

As a general rule, it is dangerous to use techniques based on the effects
of the implementation of a language's features rather on the features
themselves.  No matter how logical it may seem to implement those features
in that particular way, somewhere out there you will find a machine in
which the implementation does not have the property you exploited.
(an obvious corollary to Murphy's law)
-- 
Kurt W. Hirchert     hirchert@ncsa.uiuc.edu
National Center for Supercomputing Applications