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-Thread: 103376,ec21c3c7cdc7ff3e X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news3.google.com!news4.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local01.nntp.dca.giganews.com!nntp.megapath.net!news.megapath.net.POSTED!not-for-mail NNTP-Posting-Date: Mon, 20 Mar 2006 18:22:15 -0600 From: "Randy Brukardt" Newsgroups: comp.lang.ada References: <1142279908.327131.230200@j52g2000cwj.googlegroups.com> Subject: Re: Uninitialized variables (was: Re: private types) Date: Mon, 20 Mar 2006 18:22:23 -0600 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Message-ID: <0JidneutULuq2oLZ4p2dnA@megapath.net> NNTP-Posting-Host: 64.32.209.38 X-Trace: sv3-0rmp95/MZEvXQPQrNpU0dzt4stbrUamCxV9Oe2tFeAEB6IwW6Q60vbhK8RwAqQcAKsgU7fLqcFBK2dK!Vkgbbc0Dd/2jOegtDVQeVXAkqa1SZgsF9zXYOMN/ZAqA4Sp2ooSpoBrCxB0yHPbgdoav4o9EPt9Y X-Complaints-To: abuse@megapath.net X-DMCA-Complaints-To: abuse@megapath.net X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.3.32 Xref: g2news1.google.com comp.lang.ada:3511 Date: 2006-03-20T18:22:23-06:00 List-Id: "Dirk Craeynest" wrote in message news:dvgh0s$rtu$1@apollo.cs.kuleuven.ac.be... > [This thread really is about uninitialized variables now, so I changed > the subject...] > > In article , > Randy Brukardt wrote: > >So I recommend initalizing everything (or assigning it immediately > >after the begin) that could be significant to performance. > > We did (and do) feel this is not a good approach, at least not when > using GNAT or another compiler that supports something like the pragma > Initialize_Scalars and enhanced validity checking. > > For much more about uninitialized variables in Ada code, the following > paper might be useful: > > "Exposing Uninitialized Variables: Strengthening and Extending > Run-Time Checks in Ada" [1], > Robert Dewar, Olivier Hainque, Dirk Craeynest, and Philippe > Waroquiers, > In "Proceedings of the 7th International Conference on Reliable > Software Technologies - Ada-Europe 2002" [2], Vienna, Austria, > June 17-21, 2002, Johan Blieberger and Alfred Strohmeier (Eds.), > volume 2361 of Lecture Notes in Computer Science, pages 193-204, > Springer-Verlag, 2002. > > The conclusion of that paper contains our recommendation: > > ---start-quote--- > > 5.3 Impact of Usage of Initialize Scalars on How to Program > > There is a trend in programming guidelines to "force" initializing > everything at declaration resulting in code like: > > B : Natural := 0; > > if .... then > B := 5; > else > B := 8; > end if; > > The difficulty with such an approach is that the initial value is > meaningless. If this value is used accidentally, the results are > potentially just as wrong as the use of an uninitialized value, and > furthermore, the explicit initialization precludes the approach we > have described in this paper, and thus may introduce bugs that are much > harder to find and fix. The automatic initialization under control of > the compiler using Initialize Scalars is a far preferable approach. > > We therefore recommend that when a scalar is declared, the programmer > should avoid initializing it if the code is supposed to set the value > on all paths. It is better to let Initialize Scalars + gnatVa detect > the bug in the code logic rather than trying to deal with meaningless > initial values. Even for safety-critical programs, we can first compile > with Initialize Scalars + gnatVa + invalid values and then, if needed, > field the code with Initialize Scalars + all zero values (if it is the > case that zero values give the code a better chance of avoiding > seriously improper behavior). > > ---end-quote--- > > The GNAT manuals provide more information on GNAT's pragma > Initialize_Scalars [3] and on enhanced validity checking [4]. > Reference [3] mentions: > > ---start-quote--- > > Note that pragma Initialize_Scalars is particularly useful in > conjunction with the enhanced validity checking that is now provided > in GNAT, which checks for invalid values under more conditions. > Using this feature (see description of the -gnatV flag in the users > guide) in conjunction with pragma Initialize_Scalars provides a > powerful new tool to assist in the detection of problems caused by > uninitialized variables. > > ---end-quote--- > > We can assure everyone that from a developers and testers point of view > the combination of Initialize_Scalars and enhanced validity checking is > indeed "particularly useful". > > References: > [1] > [2] > [3] > [4] > > Dirk > Dirk.Craeynest@cs.kuleuven.be (for Ada-Belgium/-Europe/SIGAda/WG9 mail) > > *** 11th Intl.Conf.on Reliable Software Technologies - Ada-Europe'2006 > *** June 5-9, 2006 ** Porto, Portugal ** http://www.ada-europe.org ***