jgd@convex.csd.uwm.edu (John G Dobnick) (05/21/91)
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. In all my years of using FORTRAN compilers, this is the _only_ instance of this behavior I have encountered. (I understand complaints about undefined statement numbers, but this is the opposite case. It's akin to declaring a variable, but never referencing it.) Two things about this behavior annoy me. 1) The warning messages that are generated can (and do) swamp genuine errors in a "sea" of noise messages. 2) These messages cannot be suppressed without also suppressing _real_ warnings. Now, this wouldn't be so bad if all these "Statement number not used" messages were collected in one contiguous block and printed at the end of the other errors/diagnostics, but they are scattered hither and yon _amid_ the more "important" messages. I consider this mis-behavior on the compiler's (and compiler writers') part, and a negative reflection on the "quality of implementation" of the compiler. [Anecdote: I noted this annoying behavior when compiling the "paranoia" program. This program apparently had a long genesis resulting in a veritable multitude of statement numbers, many of which are not referenced in the code. The compiler noted every single bloody one of them! I will note that some of these statement labels are referenced in the commentary text of the code, and in the text messages printed by the program. Thus, the labels are most assuredly _not_ superfluous.] I'm curious about a few things. * Has anyone else encountered FORTRAN compilers with this trait? [Flagging defined but unreferenced statement labels.] * Is this trait good or bad? Desirable or undesirable? * Is the inability to suppress this specific message good or bad? * Is this allowed/forbidden/not-specified by the Standard? (We are speaking X3.9-1978 here. My perusal of the Standard leads me to believe this excessive nattering is not disallowed, but is also not required. However, I'm no standards expert.) * Any general commentary on the above compiler. (Which, other than this peculiarly annoying "habit", is an excellent compiler.) -- John G Dobnick Computing Services Division @ University of Wisconsin - Milwaukee INTERNET: jgd@uwm.edu ATTnet: (414) 229-5727 UUCP: uunet!uwm!jgd "Knowing how things work is the basis for appreciation, and is thus a source of civilized delight." -- William Safire
burley@mole.gnu.ai.mit.edu (Craig Burley) (05/21/91)
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.
In all my years of using FORTRAN compilers, this is the _only_ instance
of this behavior I have encountered.
* Has anyone else encountered FORTRAN compilers with this trait?
[Flagging defined but unreferenced statement labels.]
I haven't.
* Is this trait good or bad? Desirable or undesirable?
It's bad. Undesirable.
* Is the inability to suppress this specific message good or bad?
Very bad. Really incredibly bad.
* Is this allowed/forbidden/not-specified by the Standard? (We are
speaking X3.9-1978 here. My perusal of the Standard leads me to
believe this excessive nattering is not disallowed, but is also
not required. However, I'm no standards expert.)
I agree with your conclusion, but without rereading the standard myself.
As long as the program runs correctly, I think any and all diagnostic
messages it produces in the meantime are irrelevant. Fortran 90 changes
this, but such an obnoxious misfeature suggests the developers are long
gone and not about to do a Fortran 90. We should all be grateful for
this.
* Any general commentary on the above compiler. (Which, other than
this peculiarly annoying "habit", is an excellent compiler.)
I find it hard to believe it is an excellent compiler if it has such a
misfeature. On the other hand, maybe it was a case of some marketing yo-yo
who insisted that a customer who complained about the LACK of such warnings
should be payed attention to.
At my last company, I nearly had to talk until I was blue in the face to
convince the VP of R&D to NOT cause our Fortran compilers to generate
run-time errors/warnings when a computed GOTO statement "fell through" because
the value was out of range. No matter that the standard SAYS thats what is
supposed to happen -- he claimed that "most" computed GOTOs were written to
always transfer control and that if the value was out of range, it more
than likely indicated a bug in the program. Since this run-time detection
system did not permit disabling specific warnings, and since enough occurrences
of some problem could easily "drown out" (by overflowing a buffer) other
(more real) problems like subscript-range errors, I persisted and enlisted the
aid of other members of the compiler development team and other experts to
help me do the convincing.
Finally, the stupid warning code meaning "computed GOTO out of range" was
entirely removed from the debugging compiler and its run-time support code.
Aside from this problem, we offered a generally excellent compiler.
So I suppose it is possible that something like this happened in the R&D
or marketing group at the company that built the compiler, and nobody like
me was around to talk until they were blue in the face to get this stupid
warning removed.
I am perfectly willing to do consulting work as a blue-faced talker, if anyone
wants to hire me. No, I cannot be easily convinced WHAT to argue about! :-)
--
James Craig Burley, Software Craftsperson burley@gnu.ai.mit.eduroth@oasys.dt.navy.mil (Pete Roth) (05/21/91)
If you can get away with it, you might spend a few more moments and pipe the chatty kathy compiler output thru a filter that removes these messages...at least you won't have to look at them anymore...8) regards, pete - - - - - - - - - - - - - - - - - - - - - - - - - - Peter N Roth roth@oasys.dt.navy.mil Objects in this office are closer than they appear.
kornkven@m.cs.uiuc.edu (Ed Kornkven) (05/21/91)
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. > In all my years of using FORTRAN compilers, this is the _only_ instance > of this behavior I have encountered. > * 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, at least in the programs I write. I see nothing at all harmful in pointing out this sort of possible error (like "lint" does). However... > * Is the inability to suppress this specific message good or bad? >Very bad. Really incredibly bad. True. When a suspicious construct is legal, the error message has got to be able to be turned off. Whether the message should be on or off by default is a matter of taste, it seems to me. Ed Kornkven kornkven@cs.uiuc.edu
pa@curly.appmag.com (Pierre Asselin) (05/21/91)
In article <12306@uwm.edu> jgd@uwm.edu 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? Good because, should you want to find unreferenced lines and clean up your code, a compiler can do it much better than you. >* Is the inability to suppress this specific message good or bad? ABOMINABLE. Ruins the whole thing. Better it weren't there at all. As you pointed out, the "spurious" labels could be referenced in explanatory comments. >* Is this allowed/forbidden/not-specified by the Standard? (We are > speaking X3.9-1978 here. My perusal of the Standard leads me to > believe this excessive nattering is not disallowed, but is also > not required. However, I'm no standards expert.) The standard doesn't specify "The mechanism by which programs are transformed for use on a data processing system". (Section 1.3.2, p. 1-1) Seems to me, your compiler could post spurious warnings to comp.misc.bugs and still comply with X3.9-1978... ;-) --Pierre Asselin, R&D, Applied Magnetics. I speak for me.
buckland@ucs.ubc.ca (Tony Buckland) (05/22/91)
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 ... 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.
rdb@ktibv.uucp (Rob den Braasem) (05/22/91)
buckland@ucs.ubc.ca (Tony Buckland) writes: > 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. Just my fl 0.036 worth. Labels that are never referenced are the death of the programmer who has to maintain the bloody code. I know , because I had to maintain code like that. SHOOT the user of computed GOTO. INTENT TO USE ONE DAY ???? Label them on the day you need them, not before. CLASS IN THE PROGRAMMERS HEAD??? Should be clear from the comments. I agree to the fact that you should be able to switch it off. ---------------------- Happy Hacking "PABRAS" ----------------------------------------------------------------------------- | Rob den Braasem | "Before I sink into the big | Voice :-31-79-531825 | | | sleep, I want to hear the | Fax :-31-79-513561 | | | scream of the butterfly." | Mail : | | "PABRAS" | J. Morrison | ....!hp4nl!ktibv!rdb | | KTI bv |-------------------------------| ---------------------| | P.O. Box 86 | " We got to get out of this place, even if it is the | | 2700 AB Zoetermeer | last thing we will ever do. " | | The Netherlands | Animals. | -----------------------------------------------------------------------------
fsset@bach.lerc.nasa.gov (Scott E. Townsend) (05/22/91)
In article <713@curly.appmag.com> pa@appmag.com (Pierre Asselin) writes: >In article <12306@uwm.edu> jgd@uwm.edu 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? > >Good because, should you want to find unreferenced lines and clean up >your code, a compiler can do it much better than you. > >>* Is the inability to suppress this specific message good or bad? > >ABOMINABLE. Ruins the whole thing. Better it weren't there at all. >As you pointed out, the "spurious" labels could be referenced in >explanatory comments. > Just a note for those trying to get rid of messages like these (my pet peeve is lint -- a similar problem) As long as you're on a UNIX-like system, and the errors get routed to stdout try something like this: f77 flags files whatever | \ sed -e "/spurious-message-1-text/d" \ -e "/spurious-message-2-text/d" I'm no FORTRAN guru, but this technique works great for lint & similar programs which don't allow you to turn off 'spurious' messages. (I don't know how many '-e' expressions sed allows, but I've used up to four int the past, and they can be regular expressions!) Of course this does nothing for the compiler's exit status, a bother if you're in a makefile. -- ------------------------------------------------------------------------ Scott Townsend | Mail Stop: 5-11 NASA Lewis Research Center | Email: fsset@bach.lerc.nasa.gov Cleveland, Ohio 44135 |
iris@interet.UUCP (User) (05/22/91)
In article <12306@uwm.edu> jgd@uwm.edu 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. No, you are not being picky; given that the message is not individually suppressable, this _is_ extremely annoying behavior on the part of a com- piler. Unimportant and/or misleading compiler messages are, unfortunately, a fact of life if you support a system on multiple platforms. My suggestions: filter the compiler error output yourself and purchase a FORTRAN source code analyzer. We have Quibus's FORWARN, SAIC's MAT and IPT's Fortran- lint. Fortran-lint has proved to be the most useful for us. It allows the suppression of individual messages and will find bugs that the com- piler misses entirely. ============= Iris Engelson Interet / 111 Dunnell Road / Maplewood, NJ 07040 Tel:(201)763-1200 Fax:(201)763-5120 uunet!interet!iris
hirchert@ncsa.uiuc.edu (Kurt Hirchert) (05/22/91)
In article <12306@uwm.edu> jgd@uwm.edu writes: ... >* Has anyone else encountered FORTRAN compilers with this trait? > [Flagging defined but unreferenced statement labels.] I believe I have, but I can no longer remember which compiler it was that had this check. > >* Is this trait good or bad? Desirable or undesirable? If the message is presented with a severity of warning or less, I would consider it a good feature. In many cases, the presence of an unreferenced label is indicative of an error, but it is legal to have unreferenced (and even unreferencable) statement labels, so the message should not indicate an error, only that something is questionable. > >* Is the inability to suppress this specific message good or bad? At a minimum, there should be a mechanism to suppress all warnings, so you can spot the real error messages. The ability to suppress a specific warning message so you can more readily spot other warnings is highly desirable. > >* Is this allowed/forbidden/not-specified by the Standard? (We are > speaking X3.9-1978 here. My perusal of the Standard leads me to > believe this excessive nattering is not disallowed, but is also > not required. However, I'm no standards expert.) The FORTRAN 77 standard does not address error messages at all, so this practice is not prohibited (and thus allowed). -- Kurt W. Hirchert hirchert@ncsa.uiuc.edu National Center for Supercomputing Applications
nraoaoc@nmt.edu (Daniel Briggs) (05/23/91)
buckland@ucs.ubc.ca (Tony Buckland) writes: > 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. While few people would use Numerical Recepies code as a model of good coding style, there was one paragraph in the introduction of the book that stuck with me ever since I first read it. This argument alone is enough to convince me to never use an unneeded statement label as a shorthand for a precurser comment. This is from page 6: "Second, you {\it avoid}, insofar as possible, control statements whose controlled blocks or objects are difficult to discern at a glance. This means, in practice, that {\it you must try to avoid statement labels and {\tt GOTO}'s}. It is not the {\tt GOTO}'s which are dangerous (although they do interrupt one's reading of the program); the statement labels are the hazard. In fact, whenever you encounter a statement label while reading a program, you will soon be conditioned to get a sinking feeling in the pit of your stomach. Why? Because the following questions will, by habit, immediately spring to mind: Where did control come {\it from} in a branch to this label? It could be anywhere in the routine! What circumstances resulted in a branch to this label? They could be anything! Certainty becomes uncertainty, understanding dissolves into a morass of possibilities. (For the uninitiated, {\it ...} and {\tt ...} are TeXisms for italic and typewriter fonts.) -- This is a shared guest account, please send replies to dbriggs@nrao.edu (Internet) (505) 835-2974 Dan Briggs / NRAO / P.O. Box O / Socorro, NM / 87801 (U.S. Snail)
userAKDU@mts.ucs.UAlberta.CA (Al Dunbar) (05/23/91)
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 ... > > 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. -------------------+------------------------------------------- Al Dunbar | Edmonton, Alberta | Disclaimer: "I disclaim disclaimers" CANADA | -------------------+-------------------------------------------
hirchert@ncsa.uiuc.edu (Kurt Hirchert) (05/23/91)
On the question of unreferenced statement labels in a FORTRAN program, no one has mentioned that in some cases these labels are inserted so they can be referenced by a debugger (e.g., to set a breakpoint). -- Kurt W. Hirchert hirchert@ncsa.uiuc.edu National Center for Supercomputing Applications
burley@albert.gnu.ai.mit.edu (Craig Burley) (05/24/91)
Somehow I missed these intermediate postings, so here goes: In article <RN.1241@mts.ucs.UAlberta.CA> 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
burley@albert.gnu.ai.mit.edu (Craig Burley) (05/24/91)
In article <1991May23.144750.20941@ncsa.uiuc.edu> hirchert@ncsa.uiuc.edu (Kurt Hirchert) writes:
On the question of unreferenced statement labels in a FORTRAN program, no one
has mentioned that in some cases these labels are inserted so they can be
referenced by a debugger (e.g., to set a breakpoint).
Yes, I have done this many times, and typically when compiling for debugging
I WANT messages about uninitialized variables and other "suspicious" but
statically (compile-time) valid things the compiler is able to notice. But
getting a bunch of messages about unreferenced labels at the same time would
make the compiler fairly useless, because I do not want to wade through the
useless messages to find the useful ones, or my time is wasted.
I do remember a PL/I compiler I used did complain about unreferenced labels
I inserted so I could create debugger shell scripts that tested a
multi-process program I built, or some such thing. The messages were very
annoying for the reasons I mention above, and I think the compiler developers
agreed they were silly and removed them. PL/I isn't much different from
Fortran in this respect.
--
James Craig Burley, Software Craftsperson burley@gnu.ai.mit.edumaine@altair.dfrf.nasa.gov (Richard Maine) (05/25/91)
On 24 May 91 14:46:33 GMT, burley@albert.gnu.ai.mit.edu (Craig Burley) said:
Craig> Next, it is not likely that a GOTO to a FORMAT label will be
Craig> accepted by a compiler, Murphy's law notwithstanding.
It may not be likely, but I have used at least one compiler (which shall
remain unnamed) that allowed such GOTOs with nary a complaint. I was
not pleased.
As long as I'm posting to this thread anyway, I'll state that I find
myself in agreement with the position stated by several others that
I like the compiler to warn me about things like unreferenced labels,
but I also like to be able to turn such warnings off. And I agree
with Burley that it is desirable to be able to turn off specific
messages, instead of just the whole class of warnings. As pointed
out by some others, sed can do this, but somehow I never find myself
using it that way.
I have to disagree with Burley about the question of defaults though.
Warning messages that aren't given by default aren't worth much. My
experience is that all too often nobody thinks of turning on the
warning messages until after they have found the bug(s) in question.
I had some arguments with one vendor that would not by default
give warnings for code like
subroutine sub(c)
c = 'This is a string'
end
which I claim is almost certain to be a bug caused by a missing
character declaration. They thought people porting code from
Vaxen would complain if the compiler did not quietly accept
such stuff.
Admitedly, the particular warning that started this thread is not as
big a deal as that, but I hold to my general philosophy in the matter.
--
--
Richard Maine
maine@altair.dfrf.nasa.govjgd@convex.csd.uwm.edu (John G Dobnick) (05/25/91)
I originally said: > 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? Someone answered: >It's bad. Undesirable. Someone else then said: >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 ... > And (Craig Burley) responded: > 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. This is an accurate reading of my original posting. I just wish to point out that the vendor in question _does_ supply a cross-reference facility. Cross-referencing is sufficient to find "unreferenced statement labels", should the programmer desire to find them. I am still annoyed by the (unnecessary) nattering of the compiler on this subject. Since this still seems to be a "live" topic, I'll hold off on summarizing the responses (I've received a number via e-mail) until things "cool off" a little. -- John G Dobnick (JGD2) Computing Services Division @ University of Wisconsin - Milwaukee INTERNET: jgd@uwm.edu ATTnet: (414) 229-5727 UUCP: uunet!uwm!jgd "Knowing how things work is the basis for appreciation, and is thus a source of civilized delight." -- William Safire kkkkkkkk
Zvika Bar-Deroma <AER7101@TECHNION.BITNET> (05/25/91)
In article <12306@uwm.edu>, jgd@convex.csd.uwm.edu (John G Dobnick) says: > > >* Has anyone else encountered FORTRAN compilers with this trait? > [Flagging defined but unreferenced statement labels.] I have. > >* Is this trait good or bad? Desirable or undesirable? Desirable when you need to maintain large codes. > >* Is the inability to suppress this specific message good or bad? Bad - you should at least be able to turn off all warning-type errror messages. >* Is this allowed/forbidden/not-specified by the Standard? (We are I'm almost certain that the standard doesn't specify anything about error messages. >* Any general commentary on the above compiler. (Which, other than > this peculiarly annoying "habit", is an excellent compiler.) I consider as good (as far as messages are concerned) a compiler that gives clear and accurate error message. An important feature is the ability to control those messages (which type you want to see, which you care only about "totals", which don't interest you at all, etc.). Regards, /Zvika Zvika Bar-Deroma Phone: (+972)-4-292706 Faculty of Aerospace Engineering, Fax : (+972)-4-231848 Technion Haifa 32000 Israel BITNET : AER7101@TECHNION Internet : AER7101@TECHNION.TECHNION.AC.IL UUCP : ...!uunet!pucc.princeton.edu!technion!aer7101
userAKDU@mts.ucs.UAlberta.CA (Al Dunbar) (05/26/91)
In article <BURLEY.91May24104633@albert.gnu.ai.mit.edu>, burley@albert.gnu.ai.mit.edu (Craig Burley) writes: >Somehow I missed these intermediate postings, so here goes: > >In article <RN.1241@mts.ucs.UAlberta.CA> 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. > >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%. <<< deletions >>> > > 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. I agree that comments provide no information to the compiler. The idea is that a paragraph of comment about your future intention may be easier to understand later than a five digit number. Using unreferenced labels for future use certainly will help you reserve them, as the compiler will complain of duplication. But will it also be able to tell you that "you cannot GOTO a statement inside a DO loop or if-endif block from outside" if you do not also show it a GOTO. I am not arguing that you should not be allowed to use unreferenced labels the way you obviously are successfully using them. I just know that it would be a mistake for me to do the same. I also have no problem with a compiler that allows you to tailor how it is to respond to certain constructs that it may determine to be questionable. -------------------+------------------------------------------- Al Dunbar | Edmonton, Alberta | Disclaimer: "not much better than CANADA | datclaimer" -------------------+-------------------------------------------
burley@mole.gnu.ai.mit.edu (Craig Burley) (05/31/91)
In article <RN.1248@mts.ucs.UAlberta.CA> userAKDU@mts.ucs.UAlberta.CA (Al Dunbar) writes: In article <BURLEY.91May24104633@albert.gnu.ai.mit.edu>, 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
userAKDU@mts.ucs.UAlberta.CA (Al Dunbar) (05/31/91)
In article <BURLEY.91May30203837@mole.gnu.ai.mit.edu>, burley@mole.gnu.ai.mit.edu (Craig Burley) writes: >In article <RN.1248@mts.ucs.UAlberta.CA> userAKDU@mts.ucs.UAlberta.CA (Al Dunbar) writes: > > In article <BURLEY.91May24104633@albert.gnu.ai.mit.edu>, 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 <<< multiple deletions >>> > >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.) Aha! so you used to work for Data General, then? -------------------+------------------------------------------- Al Dunbar | Edmonton, Alberta | Disclaimer: "not much better than CANADA | datclaimer" -------------------+-------------------------------------------
burley@mole.gnu.ai.mit.edu (Craig Burley) (05/31/91)
In article <RN.1265@mts.ucs.UAlberta.CA> userAKDU@mts.ucs.UAlberta.CA (Al Dunbar) writes: >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.) Aha! so you used to work for Data General, then? Actually, no. You mean there is ANOTHER vendor who did this kind of thing? Sigh. On the other hand, if the Fortran being "sold" isn't an ANSI 77 Fortran, but is a vendor's "own", as in the case of maintaining compatibility with a very old product, then I won't complain if their computed-GOTO happens to require the computed value be in range. It isn't standard Fortran, of course. I don't know about DG, but at my last company, it WAS supposed to be standard Fortran 77 (though lacking some minor things like character data type and all I/O statements -- believe it or not), i.e. based in F77, and in any case there wasn't some "old" Fortran to be compatible with. -- James Craig Burley, Software Craftsperson burley@gnu.ai.mit.edu
leipold@eplrx7.uucp (Walt Leipold) (06/04/91)
In article <RN.1248@mts.ucs.UAlberta.CA> Al Dunbar writes: > 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%. Personally, I still use Ratfor -- it's the only way I've found of writing standard-conforming, portable FORTRAN(*) without gagging. Given the style of FORTRAN that Ratfor preprocessors generate, a compiler that *insisted* on flagging every unreferenced label would be *completely* useless. IMHO, a FORTRAN compiler should never issue a warning about *any* standard- conforming code unless I ask it to... Any other default behavior results in a community of users who think their local FORTRAN *is* the standard. (*) And I don't want to hear any flak about 'standard-conforming' .NE. 'portable'! As far as I'm concerned, if my code conforms to the ANSI standard, the vendor has a problem if he can't compile it correctly. (As it turns out, a lot of vendors have problems.) <smug_mode OFF> -- -------------------------------------------------------------------------- "When dealing with the insane, Walt Leipold it is best to pretend to be sane." (leipolw%esvax@dupont.com) -------------------------------------------------------------------------- -- The UUCP Mailer