Re: stuff

Re: stuff

[Robert Dewar]

Sam Mize said

<<Why isn't it erroneous?  Because the Ada designers felt it would cost
too much run-time and memory for Ada to detect the use of uninitialzed
variables.

Sam Mize>>


Presumably there is an extra negative here, and you mean "Why is it
erroneous" ....
\x1adp

Re: stuff

[Samuel A. Mize]

Chris Sparks (Mr. Ada) wrote:
> 
> I received this e-mail from a fellow engineer.  I thought it was worthy
> of flaming! :-)

I don't consider any serious question, however basic or ill-informed, to
be "worthy" of flaming.

"5" may not be right, but it isn't wrong either.  There is no defined
value for ui1; any value may be used, including one that will raise
constraint_error at run time.

We might expect a compiler, when not optimizing, to allocate a
memory location, and then use whatever trash was sitting there.
However, there is no requirement for it to do so.  With optimization,
this seems a reasonable compiler output.

It would be nice if the compiler detected the use of an uninitialized
variable and emitted a warning.  However, there is no requirement for
it to do so.

You ask:
> Why isn't this program erroneous?  It certainly is not safe!

It is erroneous.  It just isn't illegal.

What that means is, you can compile and run it because it's legal.
However, you can't depend on it having any particular behavior.

(I'm not sure if it's formally an erroneous program, as defined in the
Ada Reference Manual, but it IS a programmer error.)

Why isn't it erroneous?  Because the Ada designers felt it would cost
too much run-time and memory for Ada to detect the use of uninitialzed
variables.

Sam Mize


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

-- Samuel Mize           (817) 619-8622               "Team Ada"
-- Hughes Training Inc.  PO Box 6171 m/s 400, Arlington TX 76005

Re: stuff

[Chris Sparks (Mr. 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

Re: stuff

[Robert A Duff]

In article <337C8911.6BD@aisf.com>,
Chris Sparks (Mr. Ada) <sparks@AISF.COM> 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

Re: stuff

[Nick Roberts]

You all seem to be missing the fact here that the compiled code returns
R26, having computed (loaded) 9 into R0. So, in fact, the function does
indeed return a junk value (unknown context notwithstanding), just as you
would expect it to. Of course, if it did always return 9, this would also
be acceptable behaviour (according to the RM).

Nick.

Re: stuff

[Samuel A. Mize]

Robert Dewar wrote:
> 
> Sam Mize said
> 
> <<Why isn't it erroneous?  Because the Ada designers felt it would cost
> too much run-time and memory for Ada to detect the use of uninitialzed
> variables.
> 
> Sam Mize>>
> 
> Presumably there is an extra negative here, and you mean "Why is it
> erroneous" ....

Nope, I used "erroneous" for "illegal."  Sorry; good catch.


-- Samuel Mize           (817) 619-8622               "Team Ada"
-- Hughes Training Inc.  PO Box 6171 m/s 400, Arlington TX 76005