Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!rpi!think.com!mintaka!ai-lab!life!burley From: burley@albert.gnu.ai.mit.edu (Craig Burley) Newsgroups: comp.lang.fortran Subject: Re: A Question of Style Message-ID: Date: 24 May 91 14:46:33 GMT References: <12306@uwm.edu> <1991May21.140440.16964@m.cs.uiuc.edu> <1991May21.180713.1602@unixg.ubc.ca> Sender: news@ai.mit.edu Organization: Free Software Foundation 545 Tech Square Cambridge, MA 02139 Lines: 100 In-reply-to: userAKDU@mts.ucs.UAlberta.CA's message of 23 May 91 03:57:34 GMT Somehow I missed these intermediate postings, so here goes: In article userAKDU@mts.ucs.UAlberta.CA (Al Dunbar) writes: In article <1991May21.180713.1602@unixg.ubc.ca>, buckland@ucs.ubc.ca (Tony Buckland) writes: >In article <1991May21.140440.16964@m.cs.uiuc.edu> kornkven@m.cs.uiuc.edu (Ed Kornkven) writes: >>burley@mole.gnu.ai.mit.edu (Craig Burley) writes: >>>In article <12306@uwm.edu> jgd@convex.csd.uwm.edu (John G Dobnick) writes: >>> I have recently run into a FORTRAN compiler that exhibits, to my >>> mind, an annoying trait. It complains voiciferously about statement >>> numbers that are defined on statements, but are otherwise unreferenced. >>> * Is this trait good or bad? Desirable or undesirable? >>>It's bad. Undesirable. >>I disagree. Any help I get from a compiler to help me catch mistakes >>is appreciated and I would have to say that labels that are never >>referenced are very likely due to an error ... Wrong, unreferenced labels are NOT "very likely due to an error". I'd put the odds at more like 5% than the implied 90%+. Next, the question was whether complaining vociferously about such a perfectly valid and often-used construct (an unreferenced label) was desirable, and I said "NO". I stand by that assessment: if you WANT help from a compiler to catch mistakes, and you think this is a likely mistake, then a compiler that permits you to ENABLE "unlikely but possible errors" but does not make it the default, or at least allows you to disable them but still enable "likely errors" that are still valid Fortran, is desirable. But that was NOT the original question. Given any arbitrary Fortran program, I'd say the odds that any unreferenced labels represent errors are 5% are less, while the odds that any possibly uninitialized variables where the references are reached only via conditionals represent errors are 50% are more. (And the odds that any clearly uninitialized variables are errors are, depending on whether you count on code portability, 90%+ or 100%.) Yet uninitialized-variable messages are, in most implementations, WARNINGS, not ERRORS, because the compiler can still generate code for them according to the standard, and according to the standard, they don't become errors until the uninitialized variable reference is actually executed. (I.e. SUBROUTINE X PRINT *,J END is valid by itself and when "linked" into a program as long as it is never actually called; yet, practically speaking, we almost always want warning messages on this kind of error, compared to wanting messages about something as inncuous as an unreferenced label.) So to have such a vanishingly small chance of actual error (5%-) for such a common occurrence (unreferenced labels) put on equal footing with other offences much more likely to be a problem, with no way to disable the former messages without disabling the latter, is a bug in implementation quality. And probably easy to fix if you have the source code for the compiler. (But it worries me that they'd put a bug like this in it in the first place, unless it was just an oversight.) > There are a few people around (I'm not one of them, but I will > defend, although not entirely to the death, their right to be > themselves) who put labels on statements just as markers, with > no intention of ever referencing them. The technique can serve > as a way of locating all statements belonging to some class > defined in the programmer's head, or as a way of delineating > program segments, or as a labelling of statements you intend > to reference one day, or as a labelling of drop-through > statements for computed GOTOs. Et cetera. Comment statements are a much more flexible (and readable) way to document code than sticking in a specially coded statement label. Anyway, Murphy's law suggests that eventually your code will be mangled to actually GOTO an unintended destination. Yes, but documenting code wasn't all that was listed. What about labeling statements you intend to reference someday, as when developing code? That happens very frequently, and comment statements are a poor substitute, since they aren't checked by the compiler to determine whether you've defined the same label twice as unreferenced label definitions typically are. Next, it is not likely that a GOTO to a FORMAT label will be accepted by a compiler, Murphy's law notwithstanding. Many unreferenced labels are FORMAT statements whose referencing statements are commented out for some reason or other. Remember I am NOT saying that producing warning messages about unreferenced labels is bad. I AM saying that doing so in a way that cannot be disabled separately from things like obvious or suspected references to uninitialized variables IS bad. Very bad. If you are handed a 5,000-line Fortran program to "get running on this new machine", you've never seen it before and don't have much time, you aren't going to be happy using the compiler mentioned if that compiler has tons of unreferenced labels that clearly are NOT errors based on the coding style, especially if turning off the tons of useless warning messages also turns off warnings about uninitialized variables (likely if the program came from an environment that automatically sets otherwise uninitialized variables to 0) and other more important things. -- James Craig Burley, Software Craftsperson burley@gnu.ai.mit.edu