Xref: utzoo comp.lang.fortran:3825 comp.os.msdos.programmer:1071
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!samsung!munnari.oz.au!uhccux!tholen
From: tholen@uhccux.uhcc.Hawaii.Edu (David Tholen)
Newsgroups: comp.lang.fortran,comp.os.msdos.programmer
Subject: Re: MS Fortran 5.00 FP underflows
Keywords: Microsoft,Fortran
Message-ID: <9504@uhccux.uhcc.Hawaii.Edu>
Date: 22 Sep 90 00:42:40 GMT
References: <1990Sep20.215410.4844@csun.edu> <1990Sep21.082155.1743@usenet.ins.cwru.edu>
Followup-To: comp.lang.fortran
Organization: University of Hawaii
Lines: 21

In article <1990Sep21.082155.1743@usenet.ins.cwru.edu>, jb@falstaff.mae.cwru.edu (Jim Berilla) writes:
 
> 1.  Using integer*1 variables in array subscripts.
>     This test program illustrates the problem:
> 	integer*1 a(4,100)
> 	integer*1 i1,i2
> 	read (*,*) i1,i2
> 	a(i1,i2)=1
> 	end

Hmm.  Interesting.  An INTEGER*1 variable can have only 256 discrete values,
which in this case is certainly adequate for each dimension of the array, but
the array is stored linearly in memory, and in this case requires 400 storage
elements.  Maybe the compiler is trying to store the offset computed from the
two indicies in a single byte as well, and that won't work.  Might I suggest
trying it with the array dimensioned to 4x50?  At least you'll have fewer
than 256 array elements, but then I wonder how it might handle signed versus
unsigned integers?  You might need to have fewer than 128 array elements.  If
it still fails, then I'd say you have good grounds for a complaint.  Otherwise,
using INTEGER*2 (or even the ANSI standard INTEGER) seems like a small price
to pay to get a program working.