* Re: stuff
1997-05-16 0:00 ` stuff Chris Sparks (Mr. Ada)
@ 1997-05-16 0:00 ` Samuel A. Mize
1997-05-16 0:00 ` stuff Robert Dewar
1997-05-17 0:00 ` stuff Robert A Duff
1 sibling, 1 reply; 6+ messages in thread
From: Samuel A. Mize @ 1997-05-16 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: stuff
1997-05-16 0:00 ` stuff Chris Sparks (Mr. Ada)
1997-05-16 0:00 ` stuff Samuel A. Mize
@ 1997-05-17 0:00 ` Robert A Duff
1997-05-18 0:00 ` stuff Nick Roberts
1 sibling, 1 reply; 6+ messages in thread
From: Robert A Duff @ 1997-05-17 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 6+ messages in thread