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: bobduff@world.std.com (Robert A Duff) Subject: Re: Uninitialized "out" parameters Date: 1996/07/24 Message-ID: #1/1 X-Deja-AN: 170213269 references: <31EEACDA.64880EEB@sage.inel.gov> <4t1s3n$chv@goanna.cs.rmit.edu.au> <4t4r0s$8te@goanna.cs.rmit.edu.au> organization: The World Public Access UNIX, Brookline, MA newsgroups: comp.lang.ada Date: 1996-07-24T00:00:00+00:00 List-Id: In article <4t4r0s$8te@goanna.cs.rmit.edu.au>, Richard A. O'Keefe wrote: >Bob Duff is the last person I would have expected to argue against static >checks. I'm not sure why it surprises you -- after all, I had a hand in writing an RM that has more run-time checks than you can shake a stick at. ;-) Anyway, the decision between compile-time and run-time checking is always a trade off between safety and flexibility (among other things). Whenever you check something at compile time, the check is necessarily stricter than it needs to be -- the halting theorem tells us that. Consider the case of divide-by-zero. We could easily catch all divides-by-zero at compile time, if we're willing to be overly conservative. However, this would make the language a lot less useful. >... 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. Wow. That is indeed amazingly bad advice. >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*? ... I certainly agree with the first part (just like I want the compiler to complain if it *knows* I'm going to divide by zero). But the second part is questionable. It means I'm going to get a lot of spurious warnings, since my programs typically contain lots of pointers to heap-allocated records, and it's not feasible for a compiler to do a very good job for that kind of data. So what do I do with all those warnings? Well, I can ignore them, but that's horrible, because every time I recompile something, I will keep getting the same stupid warnings -- the compiler is to stupid to realize that I've already analyzed those particular warnings, and satisfied myself that they're bogus. So if there's ever a *correct* warning, I'll probably miss it. So, instead, what I have to do is add in some junk code that makes the compiler shut up. For example, I'd probably have to default-initialize every record component, whether it needs it or not. Note that in this case, run-time checks will probably find more bugs than compile-time checks. This is because I added in all those bogus initializations to some nonsense value. So if I do have a bug, I'll get that nonsense value, and perhaps get a wrong answer. (At least it will be the *same* wrong answer every time!) Whereas if the checking were done at run time, I would get an exception. (And of course I understand that I might fail to test that execution path, which is the problem with run-time checking.) Of course, with most Ada compilers, I don't get run-time checks, and I may or may not get compile-time warnings in some small subset of the cases. Anyway, I don't believe compile time checking is always better than run time checking. It's a trade-off, and the language designer has to consider the details of each case. The compiler writer, too, for deciding what warnings to produce. >What this leads up to is that a compiler for *student* use needs to have >a high level of static checking switched *by default*. Probably a good idea. - Bob