Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!gistdev!flint From: flint@gistdev.gist.com (Flint Pellett) Newsgroups: comp.lang.fortran Subject: Re: f2c experience Message-ID: <1032@gistdev.gist.com> Date: 10 Dec 90 16:12:36 GMT References: Organization: Global Information Systems Technology Inc., Savoy, IL Lines: 62 bglenden@mandrill.cv.nrao.edu (Brian Glendenning) writes: >I'm the fellow who started the most recent reincarnation of the >Fortran vs C discussion - I'm afraid that discussion digressed more >than I wanted it to and I'm sorry about that. >Anyway, I decided to run our package through f2c. Here's a little note >I wrote up about my experience. I didn't catch the previous discussion, but having used f2c, I have a couple of comments on it. I tried mailing these to the creators but couldn't get the mail thru. While I realize the goal of f2c is merely to output "something that runs", there are some problems in trying to take the output and do debugging in the C code that are possibly easily correctable. (If there is no intention at all to let someone work with the resulting C code at all, you might as well strip the comments out altogether, or provide an option to do that.) 1. f2c munges over static data declarations pretty bad. In particular, it does two things that I dislike: the first is that it moves all the actual data declarations up to the top of the resulting C file, while leaving all the comments that explain what each piece of data is for unmoved. So if you had 50 lines of data intermingled with 50 lines of comments explaining what it was for, you end up with 50 lines of data followed by 50 lines of comments and a hard time figuring out what comment refers to what data. The second objectionable thing: it turns all the data into decimal. If the data was originally written in Hex, it was probably written in hex for a reason, and it ought to be written back out in hex notation. I see no real reason why this type of stuff should be done, since the FORTRAN DATA statements are translatable linearly into C declarations without any need to reorder anything. 2. f2c removes parenthesis and changes where lines break in -if-s. (Again, there does not appear to be any good reason for this.) If the code started out looking like this: if ( (thing1 .eq. thing2) .or. + (thing3 .ne. const) ) It ought to come out as: if ( (thing1 == thing2) || (thing3 != const) ) Instead of what f2c produces now as often as not, which is: if ( thing1 == thing2 || thing3 != const ) 3. One other suggestion: It would be a massive boon to the usability of this software as a translator that intended to be used to produce C that was good enough that the original could be discarded if it allowed you to build a variable name translation table, and then changed variable names for you, based on lines in a file that looked something like this: lcstok long_char_string_token -- Flint Pellett, Global Information Systems Technology, Inc. 1800 Woodfield Drive, Savoy, IL 61874 (217) 352-1165 uunet!gistdev!flint or flint@gistdev.gist.com