Re: Concatenation and Characters

[Jim Rogers <jimmaureenrogers@worldnet.att.net>]

Programmer Dude wrote:


> I guess I'm wondering what behavior the language requires.  If it is
> required that uninitialized variables never be evaluated, I can see
> an implementation choosing not to attempt to diagnose this at compile
> time and using another mechanism to detect it at run-time (such as
> special values or descriptor bits or whatever).
>



One of the reasons default initialization is difficult for numerics
in Ada is because Ada allows you to define your own numeric types.
This means that the language cannot assume any particular value is
always a correct value for any numeric type.

You can write your code to get around this using the scalar attributes
'First or 'Last as values for explicit initialization. When using
compound types such as arrays or record types you can use explicit
initialization syntax. Record definitions also allow you to specify
your own initial value for each field. In fact, these initial values
go a long way to providing the capabilities of default constructors in
other languages.

Note that the 'Valid attribute can be checked before accessing any
variable. This attribute returns TRUE when the variable contains a
valid value and FALSE when the variable contains an invalid value.

Following is an excerpt from the Ada Language Reference Manual.

13.9.1 Data Validity

Certain actions that can potentially lead to erroneous execution are not 
directly erroneous, but instead can cause objects to become abnormal. Subsequent 
uses of abnormal objects can be erroneous.

A scalar object can have an invalid representation, which means that the 
object's representation does not represent any value of the object's subtype. 
The primary cause of invalid representations is uninitialized variables.

Abnormal objects and invalid representations are explained in this subclause.

Dynamic Semantics

When an object is first created, and any explicit or default initializations 
have been performed, the object and all of its parts are in the normal state. 
Subsequent operations generally leave them normal. However, an object or part of 
an object can become abnormal in the following ways:

� An assignment to the object is disrupted due to an abort (see 9.8) or due to 
the failure of a language-defined check (see 11.6).

� The object is not scalar, and is passed to an in out or out parameter of an 
imported procedure or language-defined input procedure, if after return from the 
procedure the representation of the parameter does not represent a value of the 
parameter's subtype.

Whether or not an object actually becomes abnormal in these cases is not 
specified. An abnormal object becomes normal again upon successful completion of 
an assignment to the object as a whole.

Erroneous Execution

It is erroneous to evaluate a primary that is a name denoting an abnormal 
object, or to evaluate a prefix that denotes an abnormal object.

Bounded (Run-Time) Errors

If the representation of a scalar object does not represent a value of the 
object's subtype (perhaps because the object was not initialized), the object is 
said to have an invalid representation. It is a bounded error to evaluate the 
value of such an object. If the error is detected, either Constraint_Error or 
Program_Error is raised. Otherwise, execution continues using the invalid 
representation. The rules of the language outside this subclause assume that all 
objects have valid representations. The semantics of operations on invalid 
representations are as follows:

� If the representation of the object represents a value of the object's type, 
the value of the type is used.

� If the representation of the object does not represent a value of the object's 
type, the semantics of operations on such representations is 
implementation-defined, but does not by itself lead to erroneous or 
unpredictable execution, or to other objects becoming abnormal.

Erroneous Execution

A call to an imported function or an instance of Unchecked_Conversion is 
erroneous if the result is scalar, and the result object has an invalid 
representation.

The dereference of an access value is erroneous if it does not designate an 
object of an appropriate type or a subprogram with an appropriate profile, if it 
designates a nonexistent object, or if it is an access-to-variable value that 
designates a constant object. Such an access value can exist, for example, 
because of Unchecked_Deallocation, Unchecked_Access, or Unchecked_Conversion.

NOTES

18 Objects can become abnormal due to other kinds of actions that directly 
update the object's representation; such actions are generally considered 
directly erroneous, however.




Jim Rogers