* Uninitialized variable and the effects they have
@ 2005-11-24 9:36 Maciej Sobczak
2005-11-24 11:49 ` Martin Dowie
2005-11-24 16:33 ` Wilhelm Spickermann
0 siblings, 2 replies; 3+ messages in thread
From: Maciej Sobczak @ 2005-11-24 9:36 UTC (permalink / raw)
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/
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Uninitialized variable and the effects they have
2005-11-24 9:36 Uninitialized variable and the effects they have Maciej Sobczak
@ 2005-11-24 11:49 ` Martin Dowie
2005-11-24 16:33 ` Wilhelm Spickermann
1 sibling, 0 replies; 3+ messages in thread
From: Martin Dowie @ 2005-11-24 11:49 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Uninitialized variable and the effects they have
2005-11-24 9:36 Uninitialized variable and the effects they have Maciej Sobczak
2005-11-24 11:49 ` Martin Dowie
@ 2005-11-24 16:33 ` Wilhelm Spickermann
1 sibling, 0 replies; 3+ messages in thread
From: Wilhelm Spickermann @ 2005-11-24 16:33 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2005-11-24 16:33 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2005-11-24 9:36 Uninitialized variable and the effects they have Maciej Sobczak
2005-11-24 11:49 ` Martin Dowie
2005-11-24 16:33 ` Wilhelm Spickermann
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox