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.9 required=5.0 tests=BAYES_00 autolearn=ham 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/25 Message-ID: <4t7chp$9mk@goanna.cs.rmit.edu.au> X-Deja-AN: 170039055 references: <31EEACDA.64880EEB@sage.inel.gov> <4t1s3n$chv@goanna.cs.rmit.edu.au> <4t4r0s$8te@goanna.cs.rmit.edu.au> organization: Comp Sci, RMIT, Melbourne, Australia nntp-posting-user: ok newsgroups: comp.lang.ada Date: 1996-07-25T00:00:00+00:00 List-Id: bobduff@world.std.com (Robert A Duff) writes: >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. ;-) Because your postings have given me reason to believe you are a very competent programmer (Robert Dewar's postings have given me the same impression of him, even if we don't see eye-to-eye). >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. You are telling this to a programmer who is in the habit of making sure that every integer division involves a divisor declared to be Positive rather than Integer, and thinks that this is one good reason for using Ada instead of C. Floating point divide by zero, that's another matter. >>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. It _isn't_? But I've seen lclint *DO* it! And so does Mercury. It may or may not be feasible for an Ada95 compiler to do a good job; I have never written an Ada95 compiler and can't presume to judge what is or is not feasible for that. What I *can* say is that it isn't just "feasible" in principle, there are systems that DO it. Of course this means having a richer type system, in which it is possible to express "X is a non-null pointer to a record with an initialised Y field, an initialised Z field, and an uninitialised W field". To a first approximation, the Mercury type/mode system does exactly that. It's even possible for such a type system to keep track of whether pointers are unique or not (Clean does this, it's in the Mercury type system, and the lclint checker does a practically useful job of it for C). I wish people wouldn't keep telling me that it isn't feasible to do what several of the tools I use *DO* do. This is not rocket science! >Note that in this case, run-time checks will probably find more bugs >than compile-time checks. I am not arguing *against* run-time checks. I am arguing against run-time checks as a substitute for compile-time checks. I would be delighted to have both. If I have to put up with only one, I will take the compile time checks; I do not want to impose the run-time burdens that Robert Dewar has listed on other programmers. >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. Compile time checking of property Z, in a language that permits it, - forbids some meaningful programs - ensures that a class of errors is not present - has lower run-time penalties, and because the compiler knows more, may permit the generation of better code Run time checking of property Z, in an implementation that permits it, - places fewer restrictions on source programs - ensures that a class of errors will not be *executed* without warning - has higher run-time penalties. You can substitute the property of your choice for Z. When Z = "type correctness", it's widely used as a stick to beat Lisp with. Existing systems show that the analogy holds for Z = initialised/not and Z = null/non-null unique/shared pointer in languages designed with such checks in mind. How much of this could be carried over to a language like Ada that was *not* designed with such checks in mind is a practical issue on which Robert Dewar and others can speak with authority and I cannot. All I can say is that lclint shows that you can do a lot more than you might think. -- 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.