Uninitialized variable and the effects they have

Uninitialized variable and the effects they have

[Maciej Sobczak]

Hello,

Consider:

procedure Hello is
    I : Integer;  -- uninitialized
begin
    case I is
       when 5 => Put("I got five!");
       when others => Put("I got something else");
    end case;

    -- continue with further statements
    -- ...

end Hello;

Is the behaviour of this program well-defined?
I mean - I consider it to be well defined if it's guaranteed that 
exactly one of the branches is chosen and later statements are executed 
without any restrictions.

What bothers me is the fact that AARM seems to guarantee this 
(5.4/10.b), but at the same time this would mean that the implementation 
may need to take some special steps to make it happen. On the platform 
where the integer type is allowed to have trap values in its 
representation (ie. there are possible bit patterns that are not 
considered to be valid numbers, which may cause the CPU to trigger bus 
error events or alike), the Ada implementation would need to somehow 
take care of them and route them to the "others" category. On the other 
hand, catching CPU critical errors might not be possible at all, or 
might in fact hide true hardware errors. Granted, the implementation is 
not obliged to use the underlying hardware in the straightforward way. 
What is really intended here?

This can be also restated another way:

I : Integer; -- uninitialized
J : Integer := I + 2;

What can be said about this code, with similar issues in mind?

Note that in C++ using (let's say reading) the uninitialized variable 
causes undefined behaviour, so both examples above could cause whatever 
effect on more exotic platform (including hardware lockup - why not?). 
If Ada makes it well-defined, I would like to know how it does it.
Please do not hesitate to point me to relevant AARM chapters.

Regards,

-- 
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/

Re: Uninitialized variable and the effects they have

[Martin Dowie]

Maciej Sobczak wrote:
[snip]
> I : Integer; -- uninitialized

It's likely that "I" will contain a valid value - you just don't know what
it is! If it was a float it might be a different matter.


> J : Integer := I + 2;

The assignment may raise a Constraint_Error depending on what happened to be
in I at the time.

That's (yet another) reason to declare your own types and preferably ones
that are not full range with respect to their base type. Combine that with
"pragme Normalize_Scalars;" (see H.1) and you have a chance.

In general, see 13.9.1.

Cheers

-- Martin

Re: Uninitialized variable and the effects they have

[Wilhelm Spickermann]

Maciej Sobczak wrote:

> Is the behaviour of this program well-defined?
> I mean - I consider it to be well defined if it's guaranteed
> that exactly one of the branches is chosen and later statements
> are executed without any restrictions.
> 

I don't think so. ("No", in the sense of your definition)

Referencing an uninitialized variable may raise Program_Error.

As it is a scalar, it is guaranteed to be a legal (= belonging to
the subtype) or illegal value of the type otherwise. You can use
I'VALID to find out which one it is and this usage of the
variable "I" will never raise Program_Error. But if you don't do
that, Constraint_Error may be raised when executing the
case-statement or sometime later. (provided there are any bit
patterns in the representation which do not belong to subtype
Integer).

So it is not "undefined behaviour" in the sense of "anything may
happen".

Wilhelm