Robert Dewar wrote:
> Laurent GUERBY wrote:
> > On Mon, 2006-03-13 at 15:31 -0700, Jeffrey A Law wrote:
> >> On Mon, 2006-02-27 at 20:08 +0100, Waldek Hebisch wrote:
> >>
> >>> What do you mean by "abuse"? TYPE_MAX_VALUE means maximal value
> >>> allowed by given type.
> >> As long as you're *absolutely* clear that a variable with a
> >> restricted range can never hold a value outside that the
> >> restricted range in a conforming program, then I'll back off
> >> the "abuse" label and merely call it pointless :-)
> >
> > Variables in a non erroneous Ada program all have their value between
> > their type bounds from the optimizer perspective (the special 'valid
> > case put aside).
>
> Not quite right. If you have an uninitialized variable, the value is
> invalid and may be out of bounds, but this is a bounded error situation,
> not an erroneous program. So the possible effects are definitely NOT
> unbounded, and the use of such values cannot turn a program erroneous.
> (that's an Ada 95 change, this used to be erroneous in Ada 83).
>
What about initializing _all_ variables? If we allow out of range values
at one place than we loose usefull invariant. I see no way that a frontend
could allow out of range values and simultaneously use TYPE_MAX_VALUE for
optimization. Also, out of range values would make TYPE_MAX_VALUE of little
use to backend.
I see two drawbacks if we initialize all variables:
1) bigger program and lower runtime efficienecy
2) we loose diagnostics about uninitialized variables
I would guess that cost of extra initializiations will be small, because
backend will remove unused variables and obviously redundant initializations
so only tricky cases will remain. Also, extra initializiatin is likely to
be cheaper then extra tests which are needed otherwise.
I am more concerned about loss of diagnostics. That could be resolved if
forntend could mark generated initializations so that backend will generate
code to initialize variable, but also issue diagnostics if such initializatin
can not be removed (yes, I understand that it is conceptually a small
change but it would probably require largish change to backend code).
--
Waldek Hebisch
[EMAIL PROTECTED]
