Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!zaphod.mps.ohio-state.edu!think.com!mintaka!ai-lab!life!burley From: burley@mole.gnu.ai.mit.edu (Craig Burley) Newsgroups: comp.lang.fortran Subject: Re: A Question of Style Message-ID: Date: 31 May 91 00:38:37 GMT References: <12306@uwm.edu> Sender: news@ai.mit.edu Organization: Free Software Foundation 545 Tech Square Cambridge, MA 02139 Lines: 179 In-reply-to: userAKDU@mts.ucs.UAlberta.CA's message of 25 May 91 17:21:48 GMT In article userAKDU@mts.ucs.UAlberta.CA (Al Dunbar) writes: In article , burley@albert.gnu.ai.mit.edu (Craig Burley) writes: >Wrong, unreferenced labels are NOT "very likely due to an error". I'd put >the odds at more like 5% than the implied 90%+. A nice statistic, but based on what? It is likely true of your code, because you use unreferenced labels. Since I choose not to do this, the odds that the presence of an unreferenced label in my code represents an error is exactly 100%. No, I'm a neatnick, in my code it, too, would be 100%, unless I were doing automated debugging/testing with a fixture that required/allowed breakpoints at labels, and then I'd either leave the unreferenced labels in or remove them depending on how likely I thought it would be to continue doing it. My guess is based on the fact that there are millions and millions of lines of running Fortran code out there (perhaps billions); only Cobol beats out Fortran in lines of production code (last I heard), and Fortran leads any other language by quite a margin. And on the fact that almost every time I look at "dusty deck" code, there tend to be several unreferenced labels, but no apparent errors. For example, the NBS test suite, and other test suites and subroutine libraries I worked with in my last job. I've proposed a "bet" with Kurt Hirchert, who feels the figure should be more like 60% (of unreferenced labels being indiciative of actual errors) that we find some patsy^H^H^H^H^Hbright young comp.sci. major to do a study by trying to obtain a representative sample of production Fortran code, run it through my GNU Fortran Front End (which doesn't work as a compiler yet but seems to do ok as a stand-alone front end) modified so it complains about unreferenced labels, and determine how many of those unreferenced labels actually involve errors (I mean production errors, not "gee I think dead code is an error, don't you?"). Then if the figure turns out to be 40% or higher, Kurt wins; I've put my guess at a "maximum error" at 20%, so below 40%, I win. The amount of the bet won't be publicized, but can be easily guessed at by any Eddie Murphy fan (the guy who'll play the bright young comp.sci. major in the movie about the bet :-). Anyway, I'm not sure I agree with another poster that all possible warning messages should be ON by default. As with gcc, the user should be able to enable them using "-Wall", but for defaults, warnings that are not likely to indicate coding errors in most programs should not, in my opinion, be enabled by default. Of course, that is my opinion -- and my original opinion, that a compiler that doesn't permit me to exercise my particular opinion regarding its opinion regarding unreferenced labels is a bad compiler in my book, I feel much more strongly about than my opinion about others' opinions regarding compiler's opinions about every little warning being important. Now let's play "invent the [useless but claimably useful] warning": - "two definitions of variable not separated by reference of variable", as in I=5 J=K I=3 since (assuming I, J, and K are mutually disassociated) "I=5" is pointless, it might well indicate an error (just like unreferenced labels) - "unwise use of DO loop", as in DO 10 I=1,100000 !Wait a while on a PC 10 J=K*L since the body of the loop always does the same thing, it might well indicate omitted code or a programmer who doesn't really want the machine to take longer then necessary to do something - "FORMAT statement referenced only in dead code" after all, assuming the compiler already warns about (and removes) dead code (unless perhaps debugging is turned on), it should also warn about any subsequently dead FORMAT statements -- or variables, etc -- because that too might conceivably indicate a programming error We can make up more. I can put them into GNU Fortran, even. What I WON'T do is EVER inflict on GNU Fortran users the requirement that ALL these warning messages be turned on (along with "uninitialized variable", "invalid run-time FORMAT constant", etc) or they ALL be turned off. Because THAT is what I object to. Even my tongue-in-cheek warnings in the above list can be shown to have their uses on occasion. Despite all the statistics and claims, I have yet to see anyone say in any persuasive way that "unreferenced label" is ANYWHERE NEAR as likely as "uninitialized variable" in indicating a possible programming error for Fortran programs in general (specific "I write my code this way" doesn't count, unless you also write your own compiler I guess). Lumping these things together doesn't make sense; even allowing individual suppression of messages is useless when a typical programmer has to "suppress" every single generally useless warning message (like unreferenced label and the ones I list above) just to get a huge amount of existing code to compile cleanly so the REAL problems can be found. In case it isn't clear, I'm not talking about seat-of-the-pants measurement: one rule I'd use in choosing warnings vs. informational (or "by-the-ways" if you want to call them that) is to determine whether execution of the "offending" code is likely to result in violation of a standard or expected behavior of the program. One cannot "execute" an unreferenced label in a way that is erroneous. One can do indirect things regarding unreferenced labels that are erroneous, but that is true of everything, I believe. And to take the example I know well, one cannot claim that falling through a computed GOTO because the computed value is out of range is a run-time "error" because that is what the standard says is SUPPOSED to happen. (The company I used to work for used to lump this "error" in with things like "array reference out of bounds" and "reference to uninitialized variable", until I convinced the VP of R&D to change his thinking, with help from other real Fortran experts in the firm.) On the other hand, "uninitialized variable" does NOT indicate an error. The error happens only when the code actually makes the reference to the uninitialized variable, and unless its near the top of a PROGRAM, the compiler probably doesn't know for sure whether that'll ever happen. (I.e. the code path, subroutine, whatever, might never get called, so it isn't an "error" like "DIMNESION A(100)" is an error.) So it IS, in my book, a valid "warning" message -- "Hey you, this looks blatantly wrong, even though I am doing what it says, so check it out", is what warnings should mean in my book. They should mean "Gee, I don't know anything about how you like to write your programs or where you got your code from, but I think unreferenced labels are accidents waiting to happen". "Run-time FORMAT constant invalid", as in "WRITE(6,'[bad format]')...", is another example of a good warning: it isn't an error until and unless that line of code is executed, but it might not be. Yet it is fairly certain that the programmer wants to know about it, because either the line might get executed and cause a hard-to-debug crash, or it might never get executed until somebody types in the right sequence of options, there's an I/O error, or some such thing, also resulting in a hard-to-debug crash. Again, with my own code, like the GNU Fortran Front End, I think cleanliness is next to godliness, and I compile my FFE stand-alone with "-Wall" using gcc, and visually ignore the warnings I've decided I want to "keep" (for speed or compatibility reasons), so this isn't a personal vendetta against useless warnings. But I would be the first to hack gcc if its default was "-Wall" and there wasn't a way of saying "turn off generally useless warnings" and it complained about some of the things "-Wall" does. As far as # lines of Fortran code I've written or maintained, I suspect it creeps into the low 1-million range. The big projects I can name are the PRIMOS operating system (revs 15, 16, which were all Fortran and assembler,through rev 19, but as of rev 18.3 or so, no new Fortran code was being written); Prime's FUTIL utility (all Fortran); Prime's RUNOFF text processor (mostly Fortran); Prime's SPOOL subsystem (mostly Fortran); Prime's CX subsystem (mostly Fortran); Prime's BATCH subsystem (circa revs 17-19, all Fortran until rev 19 I think, I should remember because I wrote it); lots of numerical code (vs. the systems code I've been listing so far) that I probably shouldn't name at my last job working in the Fortran compiler department (and prior to that the documentation group) for a VLIW machine manufacturer; and probably a bunch of other things. Out of all that, I know there were LOTS of unreferenced labels, though of course some chunks had none; and I know they rarely had anything to do with errors, so messages about them being unreferenced would have been nothing but white noise disguising any worthwhile warnings the compilers might have issued. So, after all this, does anyone STILL FEEL that it is not a Bad Thing for a compiler to force a user to always see messages like "unreferenced label" grouped with ones like "uninitialized variable" or to never see them? And that it is still a Fairly Bad Thing if a compiler requires a user to individually disable a bunch of "unreferenced label"-like warning messages rather than as a group? If so, I hope you're not developing a compiler.... :-) (And you'll all get to beat up on me when GNU Fortran is released for testing, because I haven't been paying a great deal of attention to classifying error messages, providing some of these admittedly useful messages (in some cases not the job of my front end anyway, the back end should handle them), or breaking down "general" messages into more specific and useful ones. But at least it'll have gcc's method of distinguishing useful warnings from "advisories" like unreferenced-label, by defaulting to warnings without advisories and permitted -Wall or -Wnone or a bunch of individual combinations as desired.) -- James Craig Burley, Software Craftsperson burley@gnu.ai.mit.edu