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,start
X-Google-Attributes: gid103376,public
From: "Chris Sparks (Mr. Ada)" <sparks@AISF.COM>
Subject: Re: stuff
Date: 1997/05/16
Message-ID: <337C8911.6BD@aisf.com>#1/1
X-Deja-AN: 241941207
Sender: Ada programming language <INFO-ADA@LISTSERV.NODAK.EDU>
References: <md5:AEB770CC4F41F9C14E5056EEB8BA8D66>
Comments: cc: stewart@hongkong.aisf.com
Organization: McDonnell Douglas
Newsgroups: comp.lang.ada
Date: 1997-05-16T00:00:00+00:00
List-Id: <comp.lang.ada>


I received this e-mail from a fellow engineer.  I thought it was worthy
of flaming! :-)

> 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.
>
> 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.

Why isn't this program erroneous?  It certainly is not safe!

Chris Sparks