glenn@qed.physics.su.OZ.AU (Glenn Geers) (12/29/90)
Archive-name: math/ieee-float/387-library/1990-12-27
Archive-directory: suphys.physics.su.oz.au:/libU77/ [129.78.129.1]
Original-posting-by: glenn@qed.physics.su.OZ.AU (Glenn Geers)
Original-subject: libU77 source available for ftp
Reposted-by: emv@ox.com (Edward Vielmetti)
Hi,
my homebrew libU77 is avaialble for ftp in its alpha (version 0.00) state
from suphys.physics.su.oz.au (129.78.129.1) in the root anonymous ftp directory.
Individual files can be obtained from libU77/... . Note that the malloc
interface is not quite correct with f2c. I'm not sure if the bug is in my code
(probably loc_() - loc_.c) or simply due to the fact that f2c passes all scalar
variables by address. However, these routines *work* on my SPARC; and RISC
machines are usually very good at picking up memory faults.
Also my first posting on malloc was badly *wrong*. I'll put it down to too many
Fosters over the festive season :-)
If anyone wants to hack f2c to support a pointer type (just like integer
except that code like:
pointer i
c 100 double precision
i = malloc_(800)
call fred(i, 100)
would get translated to
static integer c__800 = 800;
static integer c__100 = 100;
integer i;
/* 100 double precision */
i = malloc_(&c__800);
fred_(i, &c__100); /* currently fred_(&i, &c__100) */
Using loc() should be able to circumvent this:
in FORTRAN
c assigns address of i to m
m = loc(i)
call fred(m, 100)
but this fails with f2c but works on SUN FORTRAN.
I fear I'm missing something.
Anyway here's loc_.c
int
loc_(arg)
int *arg;
{
return((int)arg);
}
Any help would be most appreciated,
and Happy New Year
Glenn
glenn@qed.physics.su.oz.au
--
Glenn Geers | "So when it's over, we're back to people.
Department of Theoretical Physics | Just to prove that human touch can have
The University of Sydney | no equal."
Sydney NSW 2006 Australia | - Basia Trzetrzelewska, 'Prime Time TV'