From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,803df5f3f60558d5 X-Google-Attributes: gid103376,public From: ok@goanna.cs.rmit.edu.au (Richard A. O'Keefe) Subject: Re: Uninitialized "out" parameters Date: 1996/07/24 Message-ID: <4t4r0s$8te@goanna.cs.rmit.edu.au>#1/1 X-Deja-AN: 169860682 references: <31EEACDA.64880EEB@sage.inel.gov> <4stagp$3vg@mulga.cs.mu.OZ.AU> <4t1s3n$chv@goanna.cs.rmit.edu.au> organization: Comp Sci, RMIT, Melbourne, Australia nntp-posting-user: ok newsgroups: comp.lang.ada Date: 1996-07-24T00:00:00+00:00 List-Id: bobduff@world.std.com (Robert A Duff) writes: >In article <4t1s3n$chv@goanna.cs.rmit.edu.au>, >Richard A. O'Keefe wrote: >>In my experience of marking student C programs, trying to use uninitialised >>variables is the commonest non-syntactic error. >This doesn't necessarily indicate a need for compile-time checks. It >indicates a need for something -- possibly compile-time, possibly >run-time, possibly some mixture. And you get the usual trade-offs among >efficiency, early error detection, and flexibility. Bob Duff is the last person I would have expected to argue against static checks. Roughly the third most frightening thing I have seen in a computer manual is the advice "If your program is halting with range-checking errors, and you don't want to address those problems immediately, you can always omit the {$R+} compiler directive [thus suppressing the range checks] for the time being." to be found in the Turbo Pascal 5.0 User Guide on p207. If I can get a compile-time error (when it is provable that an uninitialised variable will be used) or warning (when it is not provable that it won't), why *not*? In computing, ignorance is bliss. Run-time checks only tell you whether the path followed *this time* through the code encountered an uninitialised variable or not. One of the things we are trying hard to teach is "just because your program didn't crash on YOUR test cases doesn't mean it won't crash on OURS", and relying too much on run-time checks would tend to exacerbate the problem. As things stand, I *do* have ready access to tools that do *some* static uninitialised variable checking for C: lint, gcc -O2 -Wall, and lclint. I would of course like to have ready access, at a price suitable for a not-very-rich university whose government is talking about 10% cuts to education funding, to run-time checks for C, and to similar compile time and run time checks for Ada. >>... I have found the program >>'lclint' _extremely_ useful when marking because it does a very good job of >>noticing possible uninitialised variables. >So why don't your students use lclint? To be really honest, because I didn't tell them about it. I *love* lclint, but it is a free system with a one-mand-and-his-dog maintenance team, and it tends to have trouble with system headers (sometimes because they are extremely non-standard C, sometimes because they are standard but c****y C, sometimes because lclint needs improving) and it produces a *LOT* of messages. I have the background and patience to work through long lists of messages and to work around the occasional failure of the tool, the students don't. On the other hand, they *are* told about lint, and they still don't use that. Heck, in the last assignment, a couple of students handed in C++ and I don't mean just C-with-//-comments (nor do I mean that it took *advantage* of C++, just happened to be different enough not to be even close to compiling under C). If it comes to that, they are also told to compile with gcc, and I even gave them a shell script to use that set -O2 -Wall, and they didn't do that either. What this leads up to is that a compiler for *student* use needs to have a high level of static checking switched *by default*. -- Fifty years of programming language research, and we end up with C++ ??? Richard A. O'Keefe; http://www.cs.rmit.edu.au/~ok; RMIT Comp.Sci.