Re: Uninitialized "out" parameters

[dewar@cs.nyu.edu (Robert Dewar)]

John Herro said

"     If "Ada, oh why?" does the same thing by default, it would use extra
memory and CPU time, but improve reliability and increase the chances of
detecting errors.  This is certainly in keeping with the Ada philosophy.
It's analogous to Ada doing bounds checking at run time, which can be
turned off with a pragma."


It is quite unlikely that the parameters that went into the original
Ada 83 decision will have changed, they certainly had not changed for
Ada 95, and I don't see any likelihood that architectures will develop
in a direction that makes this feasible.

It is not at all analogous to bounds checking. The point with bounds
checking is that the cost of this checking, with good compiler
optimization, is quite reasonable (in the 10-20% range at most, for
typical programs).

The cost of runtime checking of uninitialized variables is MUCH higher.
If you have a type which fills the complete hardware type (e.g. Character,
or Unsigned_32, or, in any reasonable implementation Integer), then
you have to maintain and test a separate boolean bit. Not only does this
double the register pressure, but also it generates potential pipeline
breaks in many architectures which would be very harmful peformance.

Of course there may be specialized architectures which make this kind of
testing feasible, and of course you are certainly allowed to implement
this in Ada 83 or Ada 95 (raising Program_Error as the result of failing
the test), but it is interesting to note that there has been almost no
demand for such implementations, since in the real world, the interest
in performance and easy interface to the outside world would mean that
these checks would almost always have to be suppressed.

The challenge of the Ada design is to provide a reasonable selection of
default runtime checks that do not seriously impact performance. It is
of course possible to check everything at runtime, including for example
incorrect use of unchecked_conversion and unchecked_deallocation, but
these checks are deemed simply too expensive, given the goal of providing
a usable high efficiency language.

C and C++ take the position of checking nothing at runtime. Some other
languages are completely protected (e.g. SNOBOL-4 or SETL). Ada tries
to get most of the advantages of runtime checking without paying too
high a price. Checking for uninitialized variables is deemed across
the line (note that this decision was not particularly controversial,
though it was discussed). One thing that John may not realize is that
the intent is that the checks in Ada be inexpensive enough that many
or most real applicatoins can afford to leave them on. 

I certainly understand that beginners may want an Ada system that checks
uninitialized  variables, and of course Ada/Ed always had this capability,
but it does not seem a significant priority in commercial implementations
of Ada (by commercial here, I mean usable in real applications).

I certainly see nothing in this discussion that has added anything to the
understanding of the issue when it was first discussed (with respect to
Ada) twenty years ago. If anything the development of RISC architectural
techniques has strengthened the argument *against* adding such a requirement,
and it did not even come up in the revision (I can't even rememeber it being
mentioned in the revision requests, and they sure mentioned lots of stuff!)