staff@cadlab.sublink.ORG (Alex Martelli) (04/04/90)
> o Fortran compiler is very bomb-proof. I think this is where they must have > spent most of their debugging time to date. It has a few of it's own brain > damages that are inconvienient. For example, there is no ACCESS='APPEND' > on the open statement. You open STATUS='OLD' and it appends automatically > on writing. This is a neusance because the person who wrote this code writes > into a temp file, reads and rewinds it for the next pass. This fortran > allways appends it rather than truncating. Interesting! I spent a few days' work in IBM Italy's porting center, moving most of CAD.LAB's low-level stuff before we finally get a platform of our own, and XL Fortran's *rigidities* (not bugs, except in one case) were what consumed most of my time. The only bug is that an open with STATUS='NEW' on an existing file, instead of failing and jumping to the ERR= label, silently "succeeds" and wipes out the old file's contents; workaround is to protect each such OPEN statement by an INQUIRE statement and conditional jump. The rigidities involve for example code which is compiled with -qnoi4, to get integer*2 by default: builtin functions such as LEN and INDEX *still* return integer*4, and MIN, MAX etc insist on the two paramenters having IDENTICAL types, so you can't code MAX(12,LEN(CHSTR)) since the 12 has become i*2 and the len is i*4... it just won't compile. Workaround is using INT(12), which makes it integer*4 (manual says int() returns INTEGER, and -qnoi4 is supposed to make INTEGER==i*2, BUT int() still returns i*4 - maybe that's a bug and my workaround will break on the next compiler fix???). More rigidity: a line such as "INTEGER*2 FUNCTION IFUN(IARG)" will NOT compile (the manual says that the <type> in "<type> FUNCTION <name> <args>" can be INTEGER, REAL, etc - NO mention of INTEGER*2, etc...) - workaround is to say "FUNCTION IFUN(IARG)" and on next line "INTEGER*2 IFUN". More: CHWHATEVER='' won't compile, you have to say CHWHATEVER=' '. If a formal parameter is declared INTEGER IBUF(1), then references to "IBUF(3)" in the body just won't compile. A "FORMAT(I2,X,I2)" will compile with an E severity and will ignore the X, you HAVE to say "1X" (in the previous patch level it didn't compile and got an S error...). And so on. In general, I think I would like to use this compiler to TEACH Fortran programming (what with the verbose and clear error messages), but to PORT Fortran code which compiles OK on 10 other, quite various compilers, it's a bit of a pain... BTW, this all is based on experience with patch level "9005" something, and the previous level we used I think was "8947" or something like that - if some of these rigidities have been removed from more recent levels I would LOVE to know about it before I go around patching umpteen thousands lines of Fortran code (or cobble together some preprocessor to do it for me). IBM Italy personnel assisting the porting was unable to give us any info about this. BTW squared, we got NO problems with any of our C code (in "good old Unix/K&R semistandard" fashion - we still can't afford any ANSI or POSIX stuff, to keep source portable amongst the umpteen HW/SW platforms our applications support...). Maybe we just didn't push the C compiler far enough, or maybe it happens to be more solid on "oldie but goodie" source than on these newfangled thingies...?-) -- Alex Martelli - Email: staff@cadlab.sublink.org, alex@am.sublink.org Phone: ++39 (51) 371099, ++39 (51) 250434; fax: ++39 (51) 366964