Path: utzoo!attcan!uunet!know!zaphod.mps.ohio-state.edu!usc!elroy.jpl.nasa.gov!decwrl!sgi!bron@bronze.wpd.sgi.com
From: bron@bronze.wpd.sgi.com (Bron Campbell Nelson)
Newsgroups: comp.sys.sgi
Subject: Re: Cross-Language Communication problem between FORTRAN & C.
Summary: Try this
Message-ID: <74791@sgi.sgi.com>
Date: 12 Nov 90 18:32:20 GMT
References: <1990Nov9.212649.27564@athena.mit.edu>
Sender: guest@sgi.sgi.com
Organization: Silicon Graphics, Inc., Mountain View, CA
Lines: 45

In article <1990Nov9.212649.27564@athena.mit.edu>, mlzerkle@athena.mit.edu (Michael L Zerkle) writes:
> I am trying to develop C functions to allocate and deallocate arrays
> for use in a FORTRAN progam that would run on a number of different
> UNIX boxes (DEC VS3100, Apollo, SGI 4D/210, etc.).  The C functions
> I have written appear to allocate the double array correctly, but
> either it does not pass it back the the FORTRAN program correctly, or
> the FORTRAN program is not accepting the pointer/array it is returning.
> 
> Does anyone out there have any experience with problems of this sort,
> or know what I am doing wrong?  Any suggestions?
> 

I'll skip over the error in the code and instead mention one way that
you can do this using SGI Fortran.  It relys on a couple of things:
  (1) Fortran array parameters are passed simply by passing the address
	(no funny array descriptors or dope vectors)
  (2) The VAX Fortran "%val" extension.
These two assumptions are true with SGI Fortran, and are probably true on
a number of other platforms.  For instance, the following program will
behave like one would hope:

	integer foo
	foo = malloc(1000*1000*4)
	call fill(%VAL(foo), 1000,1000)
	end

	subroutine fill(a,i,j)
	real a(i,j)
	do n1 = 1, 1000
		do n2 = 1, 1000
			a(n2,n1) = 0.0
		enddo
	enddo
	return
	end

Some versions of the SGI software do not define a Fortran interface to
malloc.  In such a case you'll also have to write the 1 line C routine

	int malloc_(size) int *size; { return (int) malloc(*size); }

--
Bron Campbell Nelson
bron@sgi.com  or possibly  ..!ames!sgi!bron
These statements are my own, not those of Silicon Graphics.