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,ad4aec717fd8556e X-Google-Attributes: gid103376,public From: bobduff@world.std.com (Robert A Duff) Subject: Re: 'size attribute inheritance Date: 1997/08/14 Message-ID: #1/1 X-Deja-AN: 264193073 References: <33ECF679.4B5D@lmco.com> Organization: The World Public Access UNIX, Brookline, MA Newsgroups: comp.lang.ada Date: 1997-08-14T00:00:00+00:00 List-Id: In article , Matthew Heaney wrote: >I figured to get this behavior you'd require support of the Safety Annex. >I didn't know Ada 95 comes that way out of the box. What the Safety annex gives you is pragma Normalize_Scalars. Given "X: Natural;" without pragma N_S, X could be initialized to a valid or invalid value. With N_S, it will be initialized to some negative number, which will increase the probability of getting an exception when you use X. But the rules about which uses of X need to do a range check are the same, with or without N_S. >Does unitialized variable checking only apply to array index variables? No, but that's where it makes the most difference. That and case statements. Array indexing can cause writes to arbitrary memory locations, and case statements can cause wild jumps, and these things make the error unbounded. It's a bounded error to read from an uninit var. You might get an in-range value, an out-of-range value, or an exception. If you say "if X in Natural then ..." an Ada 83 compiler can optimize this into "if True then ...", but an Ada 95 compiler must first prove that X was initialized before doing such an optimization. The Ada 9X team had a mandate to eliminate some erroneous situations. That's why the concept of "bounded error" exists -- it's like "erroneous", in that you can't be sure the error will be caught, but at least you know it won't do as much damage as something erroneous might (such as writing upon arbitrary memory locations, or taking wild jumps). For a bounded error, you know that if the error is detected, you'll get an exception, and otherwise, you'll get a well-defined effect. The point is to allow the compiler enough freedom to generate efficient code, without doing "too much" damage when things go wrong. >And do you have an AARM reference? AARM-3.3.1(21-21.b), 13.9.1(2,9-11). - Bob