Subject: Re: memory allocation in Fortran (was Re: HEASAR

From: cflatter at cv3.CV.NRAO.EDU (Chris Flatters)
Date: Thu, 27 May 93 16:11:22 GMT

In article c100000 at poseidon.ifctr.mi.cnr.it, Lucio Chiappetti <lucio at ifctr.mi.cnr.it> () writes:
>
>On Wed, 26 May 1993, Chris Flatters wrote:
>
>> Remember that many FITS readers are FORTRAN-based for historical
>> reasons and there is no way to dynamically allocate or reallocate an
>> array or character string in FORTRAN 77.
>> 
>
>  Unless you write some Fortran-callable C wrapper around some routine
>  like calloc. I've done this both for VMS and Unix (the two routines are
>  almost identical), and I'm using this routinely now.
>
>  From Fortran you do something like :
>
>  e.g. REAL ARRAY(1)
>  ...
>  CALL Z_ALLOC(10000,4,ARRAY,IADDR,IOFF)
>  
>  and this virtually "extends" ARRAY to 10000 elements. To access the
>  n-th element of the array you do ARRAY(n+IOFF). To pass the array to
>  a subroutine you just CALL SUB(ARRAY(1+IOFF)), and in SUBROUTINE SUB(A)
>  you just declare A(*) and go on as usually.

Any program or subprogram that does this is not a conforming FORTRAN 77
program.  No conforming program may access an element of an array
outside of its declared bounds.  In the above example, the effects
of addressing any element of ARRAY other than ARRAY(1) are
undefined.  Many FORTRAN 77 compilers will pass this as an
extension but even in these cases you are likely to have trouble if
you turn on array bounds checking (a worthwhile feature of many
compilers that can catch a number of common bugs). Indexing an
array outside of its declared bounds may also confuse an optimizer or
cause some array optimizations to be suppressed.[Z_ALLOC
is also not a valid subroutine name in a conforming program, of
course].

On top of this any program that calls C from FORTRAN or vice versa
is going to have portability problems.  There is no standard interface
for C <-> FORTRAN calls.  Some Unix systems convert FORTRAN names to lower
case and append an underscore, some convert FORTRAN names to lower case
and do not append an underscore, still others leave FORTRAN names as upper
case.  In addition to this, some FORTRAN compilers add extra arguments to
hold the dimensions of CHARACTER variables and/or arrays.

Finally, it appears from the call to Z_ALLOC that Z_ALLOC assumes that the address
of a float (IADDR) can be held  in the same storage as a FORTRAN integer.  This is
not necessarily true and Z_ALLOC is unlikely to work on machines with 64-bit
address spaces (eg. Alpha AXP-based workstations).

	Chris Flatters
	cflatter at nrao.edu

---

From: Lucio Chiappetti <lucio at ifctr.mi.cnr.it>
Date: Fri, 28 May 1993 09:23:16 +0200 (MET DST)

> >On Wed, 26 May 1993, Chris Flatters wrote:
  ......

> undefined.  

  Our concern here was mainly with portability than strict conformance
  to the standard (although we have a set of rules of conformance to an
  agreed superset of f77 for main programs and "normal" library routines ..
  the Z_ routines are a handful in the ONLY operating system dependent
  library).
  We use this succesfully on Ultrix, VMS, SunOS and HP-UX. Perhaps it was
  also tried under OSF/1 (not at my site).

> [Z_ALLOC

  I presume you refer to the underscore, or to the name being longer than
  6 characters. In our superset we accept extensions like this, which are
  widespread over all compilers I know (the rule of thumb is "if even IBM
  VS Fortran has it ..."). However we are much more restrictive on other
  extensions.
  It would be interesting to know which of the most common extensions to
  f77 are part of the future f90 standard, but I was unable to find that
  anywhere on the network. That would be a better rule of thumb.
> case and append an underscore, some convert FORTRAN names to lower case

  The underscore is used by Ultrix and SunOS, but not by HP-UX (and I
  presume OSF/1). This can be (is) handled by #define in the C source.
  The VMS version is an altogether different version (although not so
  different). Remember that the idea was that the Z_ library comes in
  a different version for each supported operating system. 

> address spaces (eg. Alpha AXP-based workstations).

  Useful piece of information. Thanks.

-----------------------------------------------------------------------------   
       A member of  G.ASS : Group for Astronomical Software Support             
-----------------------------------------------------------------------------   
Lucio Chiappetti - IFCTR/CNR Milano        |         U N I C U I Q U E          
via Bassini 15 - I-20133 Milano - Italy    |          System  Manager           
Internet: LUCIO at IFCTR.MI.CNR.IT            |           FORTUNAE SUAE            
Decnet:   IFCTR::LUCIO (39610::LUCIO)      |                                    
Bitnet:   <please do not use any more>     |                                    
-----------------------------------------------------------------------------