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: dewar@cs.nyu.edu (Robert Dewar) Subject: Re: Uninitialized "out" parameters Date: 1996/07/23 Message-ID: #1/1 X-Deja-AN: 170394369 references: <31EEACDA.64880EEB@sage.inel.gov> <4t3f1u$t0u@newsbf02.news.aol.com> organization: Courant Institute of Mathematical Sciences newsgroups: comp.lang.ada Date: 1996-07-23T00:00:00+00:00 List-Id: John Herro said " If "Ada, oh why?" does the same thing by default, it would use extra memory and CPU time, but improve reliability and increase the chances of detecting errors. This is certainly in keeping with the Ada philosophy. It's analogous to Ada doing bounds checking at run time, which can be turned off with a pragma." It is quite unlikely that the parameters that went into the original Ada 83 decision will have changed, they certainly had not changed for Ada 95, and I don't see any likelihood that architectures will develop in a direction that makes this feasible. It is not at all analogous to bounds checking. The point with bounds checking is that the cost of this checking, with good compiler optimization, is quite reasonable (in the 10-20% range at most, for typical programs). The cost of runtime checking of uninitialized variables is MUCH higher. If you have a type which fills the complete hardware type (e.g. Character, or Unsigned_32, or, in any reasonable implementation Integer), then you have to maintain and test a separate boolean bit. Not only does this double the register pressure, but also it generates potential pipeline breaks in many architectures which would be very harmful peformance. Of course there may be specialized architectures which make this kind of testing feasible, and of course you are certainly allowed to implement this in Ada 83 or Ada 95 (raising Program_Error as the result of failing the test), but it is interesting to note that there has been almost no demand for such implementations, since in the real world, the interest in performance and easy interface to the outside world would mean that these checks would almost always have to be suppressed. The challenge of the Ada design is to provide a reasonable selection of default runtime checks that do not seriously impact performance. It is of course possible to check everything at runtime, including for example incorrect use of unchecked_conversion and unchecked_deallocation, but these checks are deemed simply too expensive, given the goal of providing a usable high efficiency language. C and C++ take the position of checking nothing at runtime. Some other languages are completely protected (e.g. SNOBOL-4 or SETL). Ada tries to get most of the advantages of runtime checking without paying too high a price. Checking for uninitialized variables is deemed across the line (note that this decision was not particularly controversial, though it was discussed). One thing that John may not realize is that the intent is that the checks in Ada be inexpensive enough that many or most real applicatoins can afford to leave them on. I certainly understand that beginners may want an Ada system that checks uninitialized variables, and of course Ada/Ed always had this capability, but it does not seem a significant priority in commercial implementations of Ada (by commercial here, I mean usable in real applications). I certainly see nothing in this discussion that has added anything to the understanding of the issue when it was first discussed (with respect to Ada) twenty years ago. If anything the development of RISC architectural techniques has strengthened the argument *against* adding such a requirement, and it did not even come up in the revision (I can't even rememeber it being mentioned in the revision requests, and they sure mentioned lots of stuff!)