Uninitialized subtype variables

Uninitialized subtype variables

[Richard Pattis]

I cannot find anything in the LRM (mostly around 3.2.1) for Ada that says
after elaborating 
   X : NATURAL;
X's value is guaranteed to be >= 0. Is this in fact correct? Is there even a
guarantee that the bit pattern it contains can be interpreted as a
legal INTEGER?

Now, suppose I also declared PROCEDURE P (N : NATURAL); A smart compiler
could avoid checking the parameter constraint when calling P(X). But this could
lead to some interesting errors if X truly contained a negative value from its
(lack of) initialization.

Any comments?





-- 
------------------------------------------------------------------------------
  Richard E. Pattis			"Programming languages are like
  Department of Computer Science	 pizzas - they come in only "too"
    and Engineering			 sizes: too big and too small."

Re: Uninitialized subtype variables

[cis.ohio-state.edu!zaphod.mps.ohio-state.edu!wupost!micro-heart-of-gold.m]

In article <1992Oct21.234759.24972@beaver.cs.washington.edu> 
  pattis@cs.washington.edu (Richard Pattis) writes:

>I cannot find anything in the LRM (mostly around 3.2.1) for Ada that says
>after elaborating 
>   X : NATURAL;
>X's value is guaranteed to be >= 0. Is this in fact correct? Is there even a
>guarantee that the bit pattern it contains can be interpreted as a
>legal INTEGER?

No.  Any use of the value of an uninitialized scalar object is erroneous (i.e.
completely unpredictable effect) in Ada 83 (RM 3.2.1(18)).  
In Ada 9x we are proposing that such a use be a 
"bounded error" which means that no random memory
may be trashed nor may your disk be erased simply as a 
result of using the value
of an uninitialized scalar.

>Now, suppose I also declared PROCEDURE P (N : NATURAL); A smart compiler
>could avoid checking the parameter constraint when calling P(X). But this coul
d
>lead to some interesting errors if X truly contained a negative value from its
>(lack of) initialization.

Some Ada 83 optimizers presume all variables are within their subtype
at all times, whereas others presume only explicitly initialized variables
are within their subtype, plus those where data flow guarantees
some initialization has taken place.  It depends somewhat on the
philosophy of the authors of the optimizer -- whether they believe
erroneousness is uncommon and should be ignored (as is allowed
by the rules in the 83 RM), or is common and should be accommodated.

For Ada 9X we are trying to formulate rules which will allow optimizers
to eliminate most constraint checks based on declared subtypes,
but will still prevent random stores to memory, or random jumps.
One approach is to require constraint checks on array component assignments
(and similar memory-altering operations) even if 
subtype information implies the check can't fail,
but be more permissive elsewhere.  Of course if the data flow
analysis "proves" that even after ignoring the subtype information,
the index is within range, then the constraint check can still
be eliminated.

>Any comments?

It's a bag of worms, but we are still trying to do something about it ;-).
Uninitialized scalar variables are one of the few "holes" left in the
Ada safety net, and it would be nice to somehow narrow the hole a bit.
Of course, some kind of "pragma SUPPRESS" should be provided to rip
it open again on user request, but we would like the RM to specify
essentially "safe" semantics as the default, presuming it can
be done without unduly complicating the semantics nor significantly 
hurting code quality.

>------------------------------------------------------------------------------
>  Richard E. Pattis			"Programming languages are like
>  Department of Computer Science	 pizzas - they come in only "too"
>    and Engineering			 sizes: too big and too small."


S. Tucker Taft    stt@inmet.com
Ada 9X Mapping/Revision Team
Intermetrics, Inc.
Cambridge, MA  02138

Re: Uninitialized subtype variables

[bloom-picayune.mit.edu!enterpoop.mit.edu!snorkelwacker.mit.edu!tamsun.tam]

In article <1992Oct21.234759.24972@beaver.cs.washington.edu> pattis@cs.washingt
on.edu (Richard Pattis) writes:
>I cannot find anything in the LRM (mostly around 3.2.1) for Ada that says
>after elaborating 
>   X : NATURAL;
>X's value is guaranteed to be >= 0. Is this in fact correct? Is there even a
>guarantee that the bit pattern it contains can be interpreted as a
>legal INTEGER?
>
>Now, suppose I also declared PROCEDURE P (N : NATURAL); A smart compiler
>could avoid checking the parameter constraint when calling P(X). But this coul
d
>lead to some interesting errors if X truly contained a negative value from its
>(lack of) initialization.
>
>Any comments?
>
>------------------------------------------------------------------------------
>  Richard E. Pattis

You are correct.  The elaboration of x: natural; 
makes NO guarantee about the bit pattern in the memory associated with x,
and that this does indeed lead to interesting errors, as compilers do often
optimize away checks because the "know" that the value must be positive.

The bottom line is that programs that read from un-initialized variables
are erroneous.  Some compilers will warn you about potential use before
assignment.

Ron Sercely

Re: Uninitialized subtype variables

[cis.ohio-state.edu!news.sei.cmu.edu!ajpo.sei.cmu.edu!falis]

My limited understanding is that there's no requirement for an uninitialized
variable to be in bounds.  This is why we provide an analysis of reads
of unitialized variables in our high level optimizer.  In many,
but not all, cases, we print a warning.  The redundant check eliminator
in our technology would require an explicit bounds check for the case
of the subprogram you cited as an example.

- Ed Falis, Alsys

Re: Uninitialized subtype variables

[Michael Feldman]

In article <1992Oct22.134607.17193@inmet.camb.inmet.com> stt@spock.camb.inmet.c
om (Tucker Taft) writes:

[good stuff deleted]
>
>It's a bag of worms, but we are still trying to do something about it ;-).
>Uninitialized scalar variables are one of the few "holes" left in the
>Ada safety net, and it would be nice to somehow narrow the hole a bit.
>Of course, some kind of "pragma SUPPRESS" should be provided to rip
>it open again on user request, but we would like the RM to specify
>essentially "safe" semantics as the default, presuming it can
>be done without unduly complicating the semantics nor significantly 
>hurting code quality.

At the very least, allow some sort of programmer-specified initialization
for all types, including scalar types. I know there are some tricky
problems with this, but inituitively there ought to be a way to make
it work (maybe restrict initializations of this kind to be static).

In Ada83, the only types for which I can supply initializers are record
types; wrapping a record around a scalar type just so I can initialize
it is rather too kludgy for my taste. Better that I can say:

  SUBTYPE Little IS Integer RANGE -10..10 := -10;

or even

  TYPE Vector IS ARRAY (Integer RANGE <>) OF Float := (OTHERS => 0.0);

Even with this unconstrained type, surely the compiler can defer the
initialization till object allocation time.

At one point this was to be in Ada-9X but was eliminated at some
stage. 

We've been around this loop before, and I know there are some sticky
situations, but as I recall they were rather pathological, so perhaps
the rules could be written to end-run them. From a teachability point
of view, this uniformity would be a big winner.

Comments, Tucker?

Mike Feldman
------------------------------------------------------------------------
Michael B. Feldman
co-chair, SIGAda Education Committee

Professor, Dept. of Electrical Engineering and Computer Science
School of Engineering and Applied Science
The George Washington University
Washington, DC 20052 USA
(202) 994-5253 (voice)
(202) 994-5296 (fax)
mfeldman@seas.gwu.edu (Internet)

"Americans wants the fruits of patience -- and they want them now."
------------------------------------------------------------------------

Re: Uninitialized subtype variables

[Alex Blakemore]

In article <EACHUS.92Oct23221628@Dr_No.mitre.org> eachus@Dr_No.mitre.org (Rober
t I. Eachus) writes:
 >      One slight addition to Tucker's list.  Another alternative that a
> compiler can take is to choose to initialize the variable instead of
> doing the check.

though this is a nice trick, it hurts portability.

an erroneous program could pass through rigorous testing without a hint of
the inherent problems.  They could then show up seemingly in random
places in another compiler.  At least, without this trick there is a decent
chance you will find the error - with or without optimizing the checks away.

even though this is allowed by Ada83. 
I would prefer the compiler did not initialze
variables that I did not initialize.  

It would be nice as a compilation option to choose
between allowing the optimizer to assume all variables were in range (fast code
)
and disallowing check removal which could depend on unitialized variable
being in range (safe code).  This is not the same as suppressing all checks.
-- 
---------------------------------------------------
Alex Blakemore alex@cs.umd.edu   NeXT mail accepted

Re: Uninitialized subtype variables

[math.fu-berlin.de!news.netmbx.de!Germany.EU.net!mcsun!sunic!seunet!enea!s]

Robert I. Eachus (eachus@Dr_No.mitre.org) writes:
>     One slight addition to Tucker's list.  Another alternative that a
>compiler can take is to choose to initialize the variable instead of
>doing the check.  This turns out to be a pretty "neat" trick when the
>compiler back-end eliminates assignments of unused values.  If the
>initial value is never used (and the compiler can figure it out) the
>extra assignment is eliminated, otherwise the assignment is usually
>cheaper than the check (for scalars).

Sounds indeed palatable, but...

The variable is no more initialized because the compiler assigned
a value to it, and your program may still behave in mysterious
ways. And since you never stumble on a range check you're likely
to be even more confused.

Or even worse, you develop with the compiler initialization, con-
sciounsly or by mistake, everything works fine, until the day you
port to new compiler which never initializes variables and what used
to be a fine working program is now an inferno of unexplainable random
behaviour.
-- 
Erland Sommarskog - ENEA Data, Stockholm - sommar@enea.se
N{r busen hejdar sin st}lskodda klack en centimeter innan din t}h{tta,
och v{ser "n{sta g}ng...", det {r d} du f}tt andrum till varnagel.

Re: Uninitialized subtype variables

[munnari.oz.au!ariel!ucsvc.ucs.unimelb.edu.au!phillip.edu.au!dale]

On the subject of initialisation one problem that I encounter often in 
teaching CS1 Ada course is that of an out parameter that is not
initialized.

For example the following search procedure 


	procedure search(x    :in     string10;
                         key  :in     character;
                         found:   out boolean;
                         index:   out string10_range);


will set index to a value _only_ if the item is found (why should it do 
anything else?).

If the actual parameter associated with index is subtyped, then not finding
'key' often results in a constraint error. This is particuarly galling when
the actual for index is itself not initialised (why should it be?), and 
(because of the copy in/copy out semantics of scalars) produces the erroneous
result in the first place. 

The _only_ solution for first year students is to say "yes well that is a 
problem. Why don't you just make it an in out parameter and forget about it"
(well, this is almost what I say... :-) );

The other solution is to create a variable with a set/unset field...

         type result(found :boolean ) is
                record
                        case found is
                                when false => null;
                                when true  => index  :string10_range;
                        end case;
                end record;

and then modifying the procedure search accordingly.

Certainly simulating return values like this is the pure (but painful) way of
maintaining the correct parameter modes for a procedure such as search.

???
Perhaps variables should have a special value (Null) that indicates that 
they have not been initialised?

???
Perhaps another field could be set aside to maintain the initialisation
status *by the compiler*

???
Perhaps a pragma could be provided to disable this useful (development?)
feature.

Remember the days when array index checking was not the norm?
First it came in during program testing, and now during program operation?
Will variable initialisation testing follow?

---------------------------------------------------------------------------
Dale Stanbrough
Royal Melbourne Institute of Technology
Melbourne, Australia
dale@phillip.edu.au

Re: Uninitialized subtype variables

[Robert I. Eachus]

In article <61435@mimsy.umd.edu> alex@cs.umd.edu (Alex Blakemore) writes:

   though this is a nice trick, it hurts portability.

   an erroneous program could pass through rigorous testing without a hint of
   the inherent problems.  They could then show up seemingly in random
   places in another compiler.  At least, without this trick there is a decent
   chance you will find the error - with or without optimizing the checks away.

   even though this is allowed by Ada83.  I would prefer the compiler
   did not initialze variables that I did not initialize.

   It would be nice as a compilation option to choose between allowing
   the optimizer to assume all variables were in range (fast code) and
   disallowing check removal which could depend on unitialized
   variable being in range (safe code).  This is not the same as
   suppressing all checks.

   Hmmm!  The compiler we did this on notified the user in a warning
message.  I used to go through them religiously and find the ones
where I goofed, and the ones where the compiler goofed (couldn't
figure out that all paths were safe even with sufficient information).
The latter category shrank quickly, and the remainder--it was okay but
the compiler didn't have the information to know--accounted for less
than 30% of the uninitialized scalar variable warnings.

--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...