Should I convert FORTRAN code to C?

[Jerry Berkman]

This message is a reply to three of the people who commented on my previous
message.

wan at cory.Berkeley.EDU (Hank S. Wan) wants a FORTRAN type checker:

> if FORTRAN is so great as in all the "RE: Should I convert FORTRAN code to C"
> somebody must have a type checker so the following is not merrily accepted
> by unix f77.
> 
> 	PROGRAM bar
> 	    j = sub1( i )
> 	    PRINT *, i, j
> 	END
> 	SUBROUTINE sub1( r )
> 	    r = 1.0
> 	END
> 
> lint would do the job for c code.  (and NO, lint is not a hassle if you're
> smart enough to use it often, and interpret the results right.)
> Checking consistency in type is useful for any large project in any serious
> language.

Here is what IBM's VS FORTRAN, version 2, release 2 says about your sample
program, when the ICA option is specified:

	VS FORTRAN VERSION 2 ENTERED.  13:04:37
	
	**BAR** END OF COMPILATION 1 ******
	
	**SUB1** END OF COMPILATION 2 ******
	
	(W) CONFLICTING NAME USAGE -- THE NAME, SUB1, HAS BEEN REFERENCED AS A
	FUNCTION IN BAR(COMPILATION 1). IT IS DEFINED AS A SUBROUTINE IN
	SUB1(COMPILATION 2).
	
	(W) CONFLICTING TYPE - AT THE MAIN ENTRY TO SUBROUTINE, SUB1(COMPILATION
	2), ARGUMENT NO. 1, "R", IS EXPECTED TO BE REAL*4; HOWEVER,
	BAR(COMPILATION 1), AT ISN 2 PASSES THIS ARGUMENT, "I", AS INTEGER*4.
	
	VS FORTRAN VERSION 2 EXITED.   13:04:40

Sorry, but it's not public domain.  By the way, when you are asking for a
type checker, you are commented on the implementation, not the language.
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?

swarbric at tramp.Colorado.EDU (Frank Swarbrick) comments:

> To Jerry Berkman,
>   Gee, I just tried compiling x = +5; and x = abs(x); both in C and they both
> worked.

I just tried both on monet.berkeley.edu, where the most current distributed
4.3 BSD UNIX lives.  The C compiler, given the program:

	main()
	{
	int i;

	i = +5;

	}

comments:

	"junk.c", line 5: syntax error

It may very well work in other compilers, and will probably be added in
the new standard, but is not there now.

> (Now I don't know why anyone would ever use x = +5, but I guess
> that is not the point.)
It could be output from a program which generates source code, or a
person just likes symmetry.  It does not seem unreasonable to ask a
compiler to correctly compile it.

As for "x = abs(x);", it does compile and load.
However, it's calling a library function.  What's wrong with that?
(1) It's slow.
(2) It returns the absolute value of integers.  You can type it "float abs();"
    and it works on the VAX, but it may not work on all systems.
The FORTRAN generic abs() which works on any numeric data type and
generates in-line code is superior.

grimlok at hubcap.UUCP (Mike Percy) says:
>>> Also, I like the semantics of sqrt() under FORTRAN better:  on all
>> FORTRAN systems I have used, if y = -1., the result is a fatal error.
>> In C, it depends on what the library does.  I have used C libraries
>> which returned sqrt(abs(y)), others which return 0, and 4.3 BSD on a
>> VAX returns the reserved operand.
>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.

	- Jerry Berkman, U.C. Berkeley Computing Services
	  jerry at violet.berkeley.edu