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,a2a089cd92fbc353 X-Google-Attributes: gid103376,public From: stt@houdini.camb.inmet.com (Tucker Taft) Subject: Re: Uninitialized Variables Date: 1999/01/25 Message-ID: #1/1 X-Deja-AN: 436868079 Sender: news@inmet.camb.inmet.com (USENET news) X-Nntp-Posting-Host: houdini.camb.inmet.com References: Organization: Intermetrics, Inc. Newsgroups: comp.lang.ada Date: 1999-01-25T00:00:00+00:00 List-Id: Roger Racine (rracine@draper.com) wrote: : One of the few areas where Ada programs exhibit non-deterministic behavior : (i.e. different behavior for different runs) is when variables are not set : before their use. : I am curious as to why the language designers did not think this was : sufficiently common enough of an error to protect against it. I don't know the Ada 83 history on this. However, simply default initializing all scalars to something like zero has its own problems, because it can make it less clear whether the default value is the desired initial value, or the programmer forgot to properly set the value. Initializing pointers by default to null has somewhat the same problem, but less so, since any dereference of a null pointer would be caught, whereas any use of a default scalar value would probably not be caught. In any case, Ada 95 does include a pragma "Normalize_Scalars" which forces the implementation to initialize all scalars to some unspecified value, ideally to a value outside of their declared range. The goal here is to create reproducibility, without allowing the programmer to "shirk" their responsibility of initializing the variable properly. : ... I understand : that having an initial value takes more memory and more CPU, but so do : constraint checks. And there could always have been a pragma to allow : uninitialized variables (akin to pragma SUPPRESS). I guess I agree that it is a relatively small price to pay, but it did not seem like something we could insert during the Ada 9X revision. We wanted performance to be compatible with Ada 83 as well! Certainly Bob Duff, a member of the Ada 9X design team, would agree with your suggestions. Note that in Ada 95 we did change the use of an uninitialized variable into a "bounded error" rather than "erroneous." Even this change drew some protests from implementors because of the potential performance effects. : By the way, I would be happy with a mechanism at link time that only : complained about (or implicitly created initial values for) data that was : determined might be used before being set. We have recently added to our Ada 95 front end detection of potentially uninitialized local variables. Detecting potentially uninitialized global variables would require some kind of link-time detection. : The problem is that different environments exhibit different behavior. Some : environments put zeros in all of RAM as part of initialization. This : sometimes masks the problem (which is fine if portability is not a concern). : Some put zeros in all static (non-stack, non-heap) variables. Some even allow : the user to specify the value to be put in RAM. And some do nothing at all. : Does anyone know why there is not at least a required link-time warning : message for variables possibly used before being set? Requiring specific warnings is generally treading on thin ice from a language specification point of view. Even specifying the form of error messages is difficult. This is really more of a quality-of-implementation issue, and not very easy to legislate via the language standard. : Roger Racine -- -Tucker Taft stt@averstar.com http://www.averstar.com/~stt/ Technical Director, Distributed IT Solutions (www.averstar.com/tools) AverStar (formerly Intermetrics, Inc.) Burlington, MA USA