Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!snorkelwacker.mit.edu!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: 21 May 91 07:07:55 GMT References: <12306@uwm.edu> Sender: news@ai.mit.edu Organization: Free Software Foundation 545 Tech Square Cambridge, MA 02139 Lines: 70 In-reply-to: jgd@convex.csd.uwm.edu's message of 21 May 91 02:09:23 GMT 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.edu