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=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,ec21c3c7cdc7ff3e X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news3.google.com!border1.nntp.dca.giganews.com!border2.nntp.dca.giganews.com!nntp.giganews.com!cyclone1.gnilink.net!spamkiller2.gnilink.net!gnilink.net!trndny05.POSTED!0f19ed38!not-for-mail From: "Frank J. Lhota" Reply-To: NOSPAM.lhota@adarose.com User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: private types References: <1142279908.327131.230200@j52g2000cwj.googlegroups.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Message-ID: Date: Fri, 17 Mar 2006 16:41:21 GMT NNTP-Posting-Host: 141.154.219.35 X-Complaints-To: abuse@verizon.net X-Trace: trndny05 1142613681 141.154.219.35 (Fri, 17 Mar 2006 11:41:21 EST) NNTP-Posting-Date: Fri, 17 Mar 2006 11:41:21 EST Xref: g2news1.google.com comp.lang.ada:3406 Date: 2006-03-17T16:41:21+00:00 List-Id: Maciej Sobczak wrote: > Justin Gombos wrote: > >> .... >> >> Beyond access types, I would not consider that feature you're >> describing helpful. In fact, it's more of a disservice. > > So you have the whole pragma as such "disservice": > > http://www.adaic.org/standards/95aarm/html/AA-H-1.html Actually, the purpose of the Normalize_Scalars pragma is to eliminate any dependency on default initializations. The idea is to fill those scalars that are not initialized by the user with some extreme value, preferably out of range, so that any use of an uninitialized value can be readily detected. The Normalize_Scalars pragma is the high level version of the "DEAD BEEF" option provided by many Unix C compilers / linkers. As you may recall, the C standard specifies that any static data not initialized by the user is implicitly initialized to 0. With the "DEAD BEEF" option, the static data not initialized in the code is filled with the hex bytes 0xDEADBEEF, which results in outrageous integer / floating point / string values. Again, the point of this option is to eliminate dependence on implicit initialization. >> The first problem: initializing to zero, or some other "dummy" value >> of the compilers choice is likely to result in a valid value >> (sometimes), which only serves to /hide/ bugs in the cases where the >> object is used prior to a meaningful assignment. > > Right. Then, why not minimize the scope of the object to the extent when > it's never even visible before being initialized with the value that is > meaningful in the given context? It's not always possible, of course, > but in many (most?) cases programmers tend to put all variables at the > beginning of some rather coarse-grained scope (for example, beginning of > the procedure or function), and later wonder what is the "right" initial > value for them. It's the misplacement of declaration that is a primary > source of problems and this is what should be actually addressed. > >> Then problem with user forced initialization (which is what the OP is >> after): it could mask the cases where reassignment is inevitable. >> IOW, suppose you have subprograms like this: >> >> function exists return boolean is >> >> --Later assignment to found_it is evitable >> -- >> found_it : boolean := false; >> >> begin >> >> if some_precondition then >> >> found_it := some_other_condition; >> >> end if; >> >> return found_it; >> >> end exists; > > Single entry - single exit syndrome? :) > > -- "All things extant in this world, Gods of Heaven, gods of Earth, Let everything be as it should be; Thus shall it be!" - Magical chant from "Magical Shopping Arcade Abenobashi" "Drizzle, Drazzle, Drozzle, Drome, Time for the this one to come home!" - Mr. Lizard from "Tootor Turtle"