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,1bef33dd6d805c1a X-Google-Attributes: gid103376,public From: bobduff@world.std.com (Robert A Duff) Subject: Re: stuff Date: 1997/05/17 Message-ID: #1/1 X-Deja-AN: 242017720 References: <337C8911.6BD@aisf.com> Organization: The World Public Access UNIX, Brookline, MA Newsgroups: comp.lang.ada Date: 1997-05-17T00:00:00+00:00 List-Id: In article <337C8911.6BD@aisf.com>, Chris Sparks (Mr. Ada) wrote: >I received this e-mail from a fellow engineer. I thought it was worthy >of flaming! :-) Who are you flaming? The fellow engineer, somebody who sent this to your fellow engineer, the Ada language, some particular Ada compiler, ... ? >> In searching for an answer for the problem report C970502-2892 regarding >> uninitialized variables, I discovered the following problem. >> >> Using ADA3.3 on OSF4.0 (and also ADA3.2 on OSF3.2G), I compiled the follwing >> source code with these options: >> >> $setenv ADALISFLAGS "+m"; ada -A"@adalib" -g3 -O3 -i1 -V uninit.ada >> >> The source code is: >> ========================================================= >> >> FUNCTION Test RETURN INTEGER IS >> >> ui1 : INTEGER; >> ui2 : INTEGER; >> i3 : INTEGER := 2468; >> >> bool : BOOLEAN := FALSE; >> >> BEGIN >> >> IF bool THEN >> ui1 := 5; >> END IF; >> >> ui2 := 1; >> i3 := 3; >> >> RETURN(ui1 + ui2 + i3); >> >> END Test; >> >> ========================================================= >> >> The output listing file contains this: >> >> ========================================================= >> Test Machine Code Listing 2-May-1997 13:00:50 DEC Ada V3.3-9-318O >> 01 Test 2-May-1997 13:36:15 uninit.ada >> >> .section $CODE$, OCTA, exe, nord, nowrt >> 0000 Test:: > > ; 000001 >> 47E13400 0000 mov 9, r0 ; 9, r0 >> ; 000021 >> 6BFA8001 0004 ret r26 ; r26 >> ========================================================= >> >> The instruction generated by the compiler "mov 9, r0" is incorrect. The >> compiler should not assume that variable ui1 = 5 when the program runs, since >> bool will always be false. The compiler looks fine, to me. If bool is true, then ui1 is 5. If bool is false, then ui1 is who-knows-what (but could certainly be 5). So the compiler is quite correct to assume that ui1 is always 5. >> Although this code snippet may not be a "real world" example, I am concerned >> that the compiler error that is causing this may affect a more common >> ADA construct. Please let me know the scope of this problem and possible >> fixes/suggestions. >> >> ============================================================================= >> 5/7/97 >> >> Paul Hill from DEC support requests the code snippet above. Sent >> to his email at p_hill@csc32.cxo.dec.com. > >I, myself, tried this with GNAT 3.09 under HP-UX 10.20. When I compiled >it (gcc -O2) >I expected to be told that U1 was basically unitialized and that the >assignment on >return would be undefined. Well, it would be *nice* for the compiler to tell you that, but the RM certainly doesn't *require* that. >Why isn't this program erroneous? It certainly is not safe! Yes, this program's execution is erroneous. And not safe. Therefore, you should be happy that it prints "9" instead of, say, causing flames to erupt from your keyboard and burn your fingers, which is one allowed behavior of erroneous programs, according to the RM. ;-) - Bob