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/13 Message-ID: #1/1 X-Deja-AN: 264066473 References: <33ECF679.4B5D@lmco.com> Organization: The World Public Access UNIX, Brookline, MA Newsgroups: comp.lang.ada Date: 1997-08-13T00:00:00+00:00 List-Id: In article , Matthew Heaney wrote: >Here's a related example, something that happened to a member of our >development team just last week. You're mixing two issues here. The next example is about uninitialized variables, whereas stuff after that talks about input from hardware and so forth. In Ada 83, these were similar, in that any resulting garbage would cause execution to be erroneous. In Ada 95, however, use of uninit vars is *not* erroneous. Many cases of interfacing to hardware remain erroneous, in Ada 95. The difference makes sense, to me. Interfacing to the outside world can be isolated in specific modules, and carefully checked, whereas an uninitialized variable is something that might happen anywhere in the program. >...The code was something like this > >declare > type Atype is array (Itype) of T; > AO : Atype; > > Index : Itype; -- note that this doesn't have a default >begin > if P then > > Index := ; > ... AO (Index)... > > else > > ... AO (Index); -- oops! > > end if; >... >end; >The problem was that Index hadn't been initialized at that point at which >it was used to dereference the array, so the application was touching >memory that it wasn't supposed to, and so, for this compiler and operating >system, the application dumped core. This was correct behavior for Ada 83, but if it's an Ada 95 compiler, it has a bug. The indexing expression must either raise C_E or P_E or else return some value. It can't dump core. >The developer assumed that a Constraint_Error would be raised, but as I >pointed out in the previous post, this is never a safe, portable assumption >to make. The compiler can legally omit a range check, reasoning that since >Index is an object of type Itype, and Itype is the array index subtype, no >check is required, because Index has to be in the array's range. No longer true in Ada 95. >Robert may be thinking of GNAT, which I think always puts in a range check, >no matter what (or at least more often than other compilers). But you >can't depend on this behavior. GNAT eliminates range checks that it can prove won't fail. (I don't really know how smart it is about that.) In order to prove that properly, the initial value of a variable, or lack thereof, has to be taken into account. For "... A(I) ...", if I contains random stack junk, the compiler cannot eliminate the check, since it cannot prove I is in range. (In Ada 83, it could eliminate the check, because all it had to prove is "either I is in range, or uninitialized", since the uninitialized case was erroneous.) >My own lesson was learned the hard way on a VAX. I was reading into an >object of an enumeration type, and using that object in a case statement. >I would get ACCVIO (equivalent to a segmentation fault under UNIX) when I >got a flakey value from the hardware, which could happen at startup, and >when power was cycled. Ah, but this is a completely different issue (in Ada 95). I agree with you that when doing I/O or otherwise interfacing to the outside world, one must be very careful to avoid erroneousness. And I agree that part of that carefulness should be making certain interface variables exactly fill up the space allotted -- no extra bits lying around to cause trouble. - Bob