Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!hc!lanl!jlg
From: jlg@lanl.gov (Jim Giles)
Newsgroups: comp.lang.fortran
Subject: Re: Fortran vs C for computations
Message-ID: <3341@lanl.gov>
Date: 8 Sep 88 20:27:47 GMT
References: <368@quintus.UUCP>
Organization: Los Alamos National Laboratory
Lines: 90

From article <368@quintus.UUCP>, by ok@quintus.uucp (Richard A. O'Keefe):
> 
> Sorry, this proof won't go through.  It is only the case that Fortran
> and C can use the same library if they use sufficiently compatible
> calling sequences and memory management strategies.  There are quite a
> few other potential problems.  For example, suppose the C library routines
> require that the program execute a C initialisation routine ("crt0.o")
> and Fortran requires a Fortran initialisation which is incompatible with
> the C one?  This is not a theoretical case!  There are far too many UNIX
> systems where mixing Fortran and C code *sometimes* works provided e.g.
> that you don't do any Fortran I/O if the main program is C.

You are mixing the hypothetical with specific cases.  What you're telling
me is that a particular BAD implementation of the Fortran/C libraries proves
that C libraries can always do more and better things than Fortran libraries.
This is not the case.  The _functionality_ of C libraries can _always_ be
duplicated or exceeded by Fortran libraries and vice versa!  That is why
libraries exist!  The library implementors of you hypothetical system
didn't _HAVE_ to write incompatible libraries, the same functionality
could have been provided differently.

Consider system calls, for example.  Neither C nor Fortran has the
ability to make system calls on any machine that I know of (if you
have an example - it's not portable since neither standard speaks of
such things).  Yet the support libraries for both are capable of
doing things like getting the time, reading/writing disk, and allocating
memory.  All these things require system calls!  Usually, at some low
level, some of the library routines are written in assembly.  The point
is that these low-level routines could be shared by both the C and
Fortran libraries.

> As an example of another kind of difficulty, consider the System V
> "ftw" function:
> 	int ftw(char *path,
> 		int (*fn)(char *, struct stat *, int),
> 		int depth)
> Because the function parameter can call ftw() itself, and because it
> can call longjmp(), I believe that it is impossible to write a
> bridging routine to permit Fortran to call this, unless you modify
> the C library.

Why not just write a Fortran callable longjump() routine in assembly?
The rest of the bridge for Fortran is probably in assembly anyway.
On some machines, the _whole_library_ is written in assembly (Crays
for example).  Again, obviously anything the C library can do, so can
the Fortran library - anything that's hard to duplicate in the one 
high-level language can be done in the other or in assembly.  No user
even know what language the library is written in!

>>Because no two machines have the same exception handling capabilities!
>>Fortran doesn't include [them] because there is no portable
>>way to implement them.
> 
> If a machine doesn't provide a way of detecting and reporting floating-
> point exceptions (that is, if it insists on its right to produce
> incorrect answers without notice) why should I *care* about having
> Fortran on it?  Or were the numerical analysts who contributed to the
> development of the IEEE 754 standard wrong in thinking this was important?

Some machines/systems report floating-point (and all other) exceptions
simply by killing the program responsible with a message.  No language
definition or committee can force the designers of such machines/systems
to do otherwise.  Note again, C is _not_ more or less portable than
Fortran in this respect.  Neither language definition says _anything_
about exceptions, interrupts, signals, or any other action the system
may take when an error condition arises.  The C library (not standardized
yet - not until ANSI finishes its work) makes certain assumptions that
are _not_ portable (the C library assumes that all systems behave like
UNIX and that all hardware behaves like VAXen).  The Fortran standard
makes no such assumptions and is therefore more portable than the C
standard will be.  (Note: some of the assumptions made by the C library
are incompatible with other desireable features.  As far as I know,
there is a permanent possibility of deadlock in the Cray C library
because the way signals are processed in UNICOS (Cray UNIX) is incompatible
with multitasking functionality.)

Now, this is not the last word.  I am not in favor of putting exception
handling into the Fortran standard.  I _am_ in favor of having a 
supplimentary standard for exception handling.  This supplimentary 
standard could be proposed as a extra-linguistic standard which could
apply to all ANSI languages (it would have to be a library standard).
Machines/systems which allow user exception handling could provide
a library according to this supplimentary standard which both C and
Fortran could use.  Machines/systems which don't allow user exception
handling would not have such a library, but could still have standard
conforming Fortran and C compilers.  Much useful work can be done
on such machines even if they do always halt the program when an
exception occurs.

J. Giles
Los Alamos