Xref: utzoo comp.lang.fortran:747 comp.lang.c:10691 Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!nrl-cmf!ames!pasteur!agate!violet.berkeley.edu!jerry From: jerry@violet.berkeley.edu ( Jerry Berkman ) Newsgroups: comp.lang.fortran,comp.lang.c Subject: Re: Should I convert FORTRAN code to C? Message-ID: <10681@agate.BERKELEY.EDU> Date: 8 Jun 88 20:42:59 GMT References: <10655@agate.BERKELEY.EDU> <1857@hubcap.UUCP> Sender: usenet@agate.BERKELEY.EDU Organization: University of California, Berkeley Lines: 99 This message is a reply to three of the people who commented on my previous message. wan@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@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@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@violet.berkeley.edu