Should I convert FORTRAN code to C?

[Karl Heuer]

In article <10681 at agate.BERKELEY.EDU> jerry at violet.berkeley.edu (Jerry Berkman) writes:
>By the way, when you are asking for a type checker, you are commented on the
>implementation, not the language.

I'm glad you were the one to bring that up.  Many of the issues you raise are
not intrinsic to the language, either.

>If you want complete checking, try WATFOR77, which check not only for
>argument agreement, but also check subscripts, and for variables used
>before they are defined.  Is there any C equivalent?

Yes, it's my understanding that some implementations of C have this.  I
haven't used them (though I've often threatened to write one).  Certainly the
language doesn't forbid it.

>As for "x = abs(x);", it does compile and load.
>However, it's calling a library function [which is slow].

That's an implementation issue.  The better C compilers generate inline code.

>(2) It returns the absolute value of integers [only].

The floating-point version is named fabs().  If you want to argue whether a
single generic name is better than a family of typed functions, fine; but I
think that the issue you raised (existence) is closed.

>grimlok at hubcap.UUCP (Mike Percy) says [about the semantics of sqrt(-1.0)]
>>Which is why you have the freedom to decide exactly what you want by
>>redefining the function slightly, maybe with a #define.
>
>This makes it an act of faith in reading large programs as to what
>procedure calls do.  I prefer intrinsics for common functions.

Mike Percy has fallen victim to a common misconception.  The user does not
have the guaranteed freedom to redefine standard functions.  (It may happen to
work; this is also true in FORTRAN.)  The standard functions in C are quite
analogous to the intrinsics of FORTRAN.  (Note: "analogous" does not mean
"identical".)

Karl W. Z. Heuer (ima!haddock!karl or karl at haddock.isc.com), The Walking Lint