Constraint checking of actuals passed to Attributes

Constraint checking of actuals passed to Attributes

[Matt Brennan]

Quick question:

Is an implementation required to generate code to check that an actual
parameter passed to an attribute (for example, 'Image of a scalar type)
is subtype conformant with the formal parameter? 

Opinions with ARM references most welcome! :-)

  Matt

Re: Constraint checking of actuals passed to Attributes

[Keith Thompson]

Matt Brennan <zschub@hotmail.com> writes:
> Is an implementation required to generate code to check that an actual
> parameter passed to an attribute (for example, 'Image of a scalar type)
> is subtype conformant with the formal parameter? 

Yes, but the formal parameter may not be what you expect it to be.

In the specific case of 'Image, 3.5(35..36) says:

    S'Image denotes a function with the following specification: 

           function S'Image(Arg : S'Base)
             return String

So, for example, Natural'Image(-1) is the same as Integer'Image(-1),
and will not raise Constraint_Error.

-- 
Keith Thompson (The_Other_Keith) kst@cts.com  <http://www.ghoti.net/~kst>
San Diego Supercomputer Center           <*>  <http://www.sdsc.edu/~kst>
Welcome to the last year of the 20th century.

Re: Constraint checking of actuals passed to Attributes

[Tucker Taft]

Matt Brennan wrote:
> 
> Quick question:
> 
> Is an implementation required to generate code to check that an actual
> parameter passed to an attribute (for example, 'Image of a scalar type)
> is subtype conformant with the formal parameter?

Most attribute functions like 'Image, 'Pos, etc., have the base subtype
as the parameter subtype, meaning that no constraints apply.
Hence, the only possible problem occurs if the actual parameter is
not a value of the *type* which could happen due to unchecked
conversion, (unchecked) binary input, or an uninitialized variable.

Implementations are not required to deal nicely with the unchecked
conversion or binary input situation, but are required to at least
"survive" the uninitialized variable situation in Ada 95.
This is because the first two are "erroneous" situations whereas
the last one is merely a "bounded error."  This means that in the
first two cases, anything could happen (incineration of disk drive,
etc.), whereas in the uninitialized case, Program_Error, Constraint_Error,
or producing some arbitrary value as the result would be acceptable.

In Ada 83, using uninitialized variables is erroneous as well,
so some compilers out there might still misbehave on them due
to bugs or ancestry. 

> Opinions with ARM references most welcome! :-)

RM95 A.13(17) -- unchecked binary input
RM95 13.9(11)/13.9.1(8) -- unchecked conversion/abnormality
RM95 13.9.1(9-11) -- uninitialized variable bounded error

> 
>   Matt

-- 
-Tucker Taft   stt@averstar.com   http://www.averstar.com/~stt/
Technical Director, Commercial Division, AverStar (formerly Intermetrics)
(http://www.averstar.com/services/IT_consulting.html)  Burlington, MA  USA

Re: Constraint checking of actuals passed to Attributes

[Robert Dewar]

In article <8f9c45$be5$1@nnrp1.deja.com>,
  Ted Dennison <dennison@telepath.com> wrote:
> Not having to have ever written a full Ada compiler, I'm not
> as aquainted with the nuances of the meaning of "abnormal" as
> it pertains to objects as many others here are.

The term "abnormal" has nothing to do with Ada compilers or any
other compilers, it is a term specifically coined for use in the
Ada RM, and fully defined therein.

> But my reading of the context of
> 13.9.1("Data Validity":3-7) implies more or less just that. It
> talks about objects that are "normal" having valid values for
> their type.

Nope, that's not careful enough reading. The whole point of
this section is to distinguish abnormal from other cases where
values may be outside the subtype range. An uninitialized
value is NOT abnorma. That's at the heart of the discussion
here, since referencing an abnormal object is for sure
erroneous:

8   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.

But an uninitialized variable may well not have
a valid value.

Confused? I am not surprised. I find this whole attempt to
differentiate between these two states pretty ill-defined.

> So it would seem that any requirement to keep objects "normal"
> means that they cannot have garbage values placed in them.
> What am I missing?

See above!


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Constraint checking of actuals passed to Attributes

[Robert Dewar]

In article <wcc4s8721fj.fsf@world.std.com>,
  Robert A Duff <bobduff@world.std.com> wrote:

> Well, it's clear to me.  ;-)
>
> Apparently, it's not clear to you, but I'm not sure what to do
> about that at this point.

You could try expressing your intent.

> I agree with you that the RM words do not precisely capture
> the intent.

Seeing as you agree the RM words do not capture the intent, I
guess the only way to determine the intent is to ask the
intenders to divulge otherwise unknowable information.

Seems to me that implementation-defined is pretty clear, you
apparently have in mind,
implementation-defined-but-please-don't-do-anything-I-did-not-in
tend

which is a harder concept to follow!

>
> - Bob
>


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Constraint checking of actuals passed to Attributes

[Ted Dennison]

In article <8f9sjg$v3t$1@nnrp1.deja.com>,
  Robert Dewar <robert_dewar@my-deja.com> wrote:
> Nope, that's not careful enough reading. The whole point of
> this section is to distinguish abnormal from other cases where
> values may be outside the subtype range. An uninitialized
> value is NOT abnorma. That's at the heart of the discussion

Ahh, I see. It looks like I mentally added an "ab" at an unfortunate
place in the first sentence of section 4.

> Confused? I am not surprised. I find this whole attempt to
> differentiate between these two states pretty ill-defined.

Horribly, yes. I'm not upset or grinding an axe here, just
curious and confused.

I still fail to see the reason for the distinction between a variable
that got hosed because an assignment was aborted and a variable that got
hosed because of an assignment to an inappropriate overlay on a
neighboring object. I can't think of any possible logical distinction,
other than that perhaps someone desparately wanted type-hosing overlays
to not be erronious anymore.

I guess you could say that the difference is that in the first case the
values it managed to put in were probably valid values, and the ones it
didn't were also valid; they just may not be valid together. But in the
second case the value really is completely undefined. But the other
listed "abnormailty" is when you get a garbage value from an imported
subprogram. So so much for that idea.

I mean, what's the difference *how* the garbage was achieved? The affect
of trying to work with it is what matters, and there is no difference I
can see there (no matter how you want to word the standard).

--
T.E.D.

http://www.telepath.com/~dennison/Ted/TED.html


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Constraint checking of actuals passed to Attributes

[Robert A Duff]

Ted Dennison <dennison@telepath.com> writes:

> I mean, what's the difference *how* the garbage was achieved? The affect
> of trying to work with it is what matters, and there is no difference I
> can see there (no matter how you want to word the standard).

The discussion was about uninitialized variables, completely within the
Ada world.  That's a big difference from "values" produced by
Unchecked_Conversion or interface to some other language.  The latter
are isolated in specific modules (one hopes), whereas variable
declarations appear all over the place.  It's fine with me if one has to
inspect the interfaced values carefully, or call 'Valid or some such,
but it shouldn't cause havoc to simply forget to initialize a variable
in plain vanilla Ada code.

- Bob

Re: Constraint checking of actuals passed to Attributes

[Robert A Duff]

Robert Dewar <robert_dewar@my-deja.com> writes:

> In article <wcc4s8721fj.fsf@world.std.com>,
>   Robert A Duff <bobduff@world.std.com> wrote:
> 
> > Well, it's clear to me.  ;-)
> >
> > Apparently, it's not clear to you, but I'm not sure what to do
> > about that at this point.
> 
> You could try expressing your intent.

Well.  First of all, it's not "my" intent.  It's the intent of the
language design team (of which I was but a part), and I think I
understand that intent, but I don't entirely agree with it.  (English
suffers from not having a clear singular for "your".;-))  My job was to
help write a coherent reference manual, and only secondarily to push for
my own wishes as to the language rules.

I suppose I could try expressing the intent by example:

If you say:

    Uninit: Integer; -- Uninitialized variable!
    ...
    if Uninit < 10 then
        ...

The condition must be either True or False, or it must raise an
exception.  It must not destroy other variable's values.  Inside the
if statement, Uninit must evaluate to a value less than 10.

Obviously that's not a formal definition -- it's just an example of the
intent.

If I could give a formal definition of the intent, I would have done so
in the RM -- I didn't then, because it's hard, and it's still hard
today.  I don't think it's impossible to formalize that intent.

If you start asking me about floating-point NaN's, or holes in
rep-speced enums, I'll start hemming and hawing.  But for plain old
integers and enums, I think I kown what was "intended".

At least I can give lots of examples.  ;-)

> > I agree with you that the RM words do not precisely capture
> > the intent.
> 
> Seeing as you agree the RM words do not capture the intent, I
> guess the only way to determine the intent is to ask the
> intenders to divulge otherwise unknowable information.

Correct.  ;-)

I'm not convinced that the RM always has to be read in such a
formal way.  Sometimes (most times) it should.  But there are
some rules of the form, "nudge, nudge, you know what I mean".

- Bob

Re: Constraint checking of actuals passed to Attributes

[Keith Thompson]

Robert A Duff <bobduff@world.std.com> writes:
[...]
> I suppose I could try expressing the intent by example:
> 
> If you say:
> 
>     Uninit: Integer; -- Uninitialized variable!
>     ...
>     if Uninit < 10 then
>         ...
> 
> The condition must be either True or False, or it must raise an
> exception.  It must not destroy other variable's values.  Inside the
> if statement, Uninit must evaluate to a value less than 10.
> 
> Obviously that's not a formal definition -- it's just an example of the
> intent.

If I understand the context of this example correctly, the intent is
to make these guarantees if Uninit is merely uninitialized, but not if
it's abnormal (say, if an assignment to it was disrupted; see
RM95-13.9.1).  The standard doesn't require bizarre things to happen
under such circumstances, it merely withdraws its usual guarantee that
bizarre things won't happen.  If the underlying hardware has no
abnormal representations for type Integer, Integers will never become
abnormal ("Whether or not an object actually becomes abnormal in these
cases is not specified.")

This kind of thing is more likely to show up (on most systems) for
things like composite objects with corrupted descriptors.  The most
plausible scenario for type Integer that I can think of is a system
that represents an integer as a floating-point value with the exponent
set to zero (I'm not sure whether Ada allows this); something like a
floating-point NaN would then be an abnormal value for type Integer.
A less plausible scenario is
an integer with the low-order bit set to 0.5.

I suppose the real requirement being imposed here is that, if the
underlying system has "abnormal" representations for a given type, the
Ada implementation must guarantee that an uninitialized variable isn't
set to one of those representations.

-- 
Keith Thompson (The_Other_Keith) kst@cts.com  <http://www.ghoti.net/~kst>
San Diego Supercomputer Center           <*>  <http://www.sdsc.edu/~kst>
Welcome to the last year of the 20th century.

Re: Constraint checking of actuals passed to Attributes

[Robert Dewar]

In article <39171B69.2F983487@averstar.com>,
  Tucker Taft <stt@averstar.com> wrote:

> but are required to at least "survive" the uninitialized
> variable situation in Ada 95. This is because the first two
> are "erroneous" situations whereas the last one is merely a
> "bounded error."  This means that in the first two cases,
> anything could happen (incineration of disk drive, etc.),
> whereas in the uninitialized case, Program_Error,
> Constraint_Error, or producing some arbitrary value as the
> result would be acceptable.

A lot of things would be acceptable, including incineration
of disk drives. Why? let's read the RM:

   11  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.

Unfortunately, implementation-defined is a HUGE hole, through
which almost any truck can be driven. OK, so it is probably
not acceptable for an implementation to say:

  In this implementation, the semantics of such operations
  is erroneous.

But I can't see anything wrong in a statement that says

  In this implementation, the semantics of such operations
  is that the following horrible things may happen:

    Long list of horrible consequences, which does not
    explicitly mention erroneousness or abnormal values,
    but whose consequences are equally severe.

OK, Bob and Tuck will argue that this does not meet the
"intent" of the authors in writing the above statement.

Arguments from intent are always suspect, but never more
so than when the intent is vague and unclear. I really
cannot see the thoughts behind trying to carefully bound
the effects of an error, and then allowing one of the
possible effects to be implementation defined.

The notion of "anything short of erroneous" is definitely
not one that is well defined, or testable.

Ken -- time for another of your complaints about dubious
requirements :-)





>
> In Ada 83, using uninitialized variables is erroneous as well,
> so some compilers out there might still misbehave on them due
> to bugs or ancestry.
>
> > Opinions with ARM references most welcome! :-)
>
> RM95 A.13(17) -- unchecked binary input
> RM95 13.9(11)/13.9.1(8) -- unchecked conversion/abnormality
> RM95 13.9.1(9-11) -- uninitialized variable bounded error
>
> >
> >   Matt
>
> --
> -Tucker Taft   stt@averstar.com
http://www.averstar.com/~stt/
> Technical Director, Commercial Division, AverStar (formerly
Intermetrics)
> (http://www.averstar.com/services/IT_consulting.html)
Burlington, MA  USA
>


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Constraint checking of actuals passed to Attributes

[Ted Dennison]

In article <8f93lm$1es$1@nnrp1.deja.com>,
  Robert Dewar <robert_dewar@my-deja.com> wrote:
> of disk drives. Why? let's read the RM:
>
>    11  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.
>
> Unfortunately, implementation-defined is a HUGE hole, through
> which almost any truck can be driven. OK, so it is probably
> not acceptable for an implementation to say:

It does seem that this constrains the possible effects to just the
object in question. To me that means that if I overlay a small object
with a large one, then the compiler has to somehow prevent writes to the
large object from hosing nearby objects. That can't be right.

--
T.E.D.

http://www.telepath.com/~dennison/Ted/TED.html


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Constraint checking of actuals passed to Attributes

[Robert Dewar]

In article <8f99gf$8eo$1@nnrp1.deja.com>,
  Ted Dennison <dennison@telepath.com> wrote:

> It does seem that this constrains the possible effects to just
> the object in question.

If you say so, I guess people can read all sorts of things into
a vague requirement that is not well stated. I certainly don't
see the slightest hint to justify this viewpoint. It only talks
about other values becoming abnormal, not about being affected
in other ways, e.g. having values outside their subtype.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Constraint checking of actuals passed to Attributes

[Robert A Duff]

Robert Dewar <robert_dewar@my-deja.com> writes:

> OK, Bob and Tuck will argue that this does not meet the
> "intent" of the authors in writing the above statement.

Yes.

> Arguments from intent are always suspect, 

True.  My rule of thumb is that you shouldn't argue from intent unless
you've found something wrong with the RM (an inconsistency, an onerous
implementation burden, a requirement that makes the language useless,
etc).  Having found such a bug, I think it makes sense to talk about
what the original authors must have meant, in some informal sense.
Sometimes, they can even *remember* what they meant.  ;-)

>...but never more
> so than when the intent is vague and unclear.

Well, it's clear to me.  ;-)

Apparently, it's not clear to you, but I'm not sure what to do about
that at this point.

I agree with you that the RM words do not precisely capture the intent.

- Bob

Re: Constraint checking of actuals passed to Attributes

[Ted Dennison]

In article <8f9a87$97r$1@nnrp1.deja.com>,
  Robert Dewar <robert_dewar@my-deja.com> wrote:
> In article <8f99gf$8eo$1@nnrp1.deja.com>,
>   Ted Dennison <dennison@telepath.com> wrote:
>
> > It does seem that this constrains the possible effects to just
> > the object in question.
>
> If you say so, I guess people can read all sorts of things into
> a vague requirement that is not well stated. I certainly don't
> see the slightest hint to justify this viewpoint. It only talks
> about other values becoming abnormal, not about being affected
> in other ways, e.g. having values outside their subtype.

Not having to have ever written a full Ada compiler, I'm not as
aquainted with the nuances of the meaning of "abnormal" as it pertains
to objects as many others here are. But my reading of the context of
13.9.1("Data Validity":3-7) implies more or less just that. It talks
about objects that are "normal" having valid values for their type.

So it would seem that any requirement to keep objects "normal" means
that they cannot have garbage values placed in them. What am I missing?

--
T.E.D.

http://www.telepath.com/~dennison/Ted/TED.html


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Constraint checking of actuals passed to Attributes

[Robert A Duff]

Keith Thompson <kst@cts.com> writes:

> If I understand the context of this example correctly, the intent is
> to make these guarantees if Uninit is merely uninitialized, but not if
> it's abnormal

Yes.

> I suppose the real requirement being imposed here is that, if the
> underlying system has "abnormal" representations for a given type, the
> Ada implementation must guarantee that an uninitialized variable isn't
> set to one of those representations.

Yes, that's necessary.  Eg, an uninitialized array has to have bounds
or whatever dope the implementation uses properly initialized, so that
things like "A(1) := ...;" will work.

But the real bone of contention here, I think, is the requirement that,
for example:

    My_String: String(1..10);
    My_Index: Integer range 1..5;
    ...
    My_String(My_Index) := ...;

will need a check (that My_Index is in 1..10) unless the compiler can
prove that My_Index is initialized.  (Or, more precisely, is valid.)  In
Ada 83, no such check was required, because either My_Index is in 1..5,
and therefore in 1..10, or else the program was erroneous, and therefore
can do anything.  This intended change was a deliberate attempt to
increase safety at the expense of a small inefficiency.

In the run-time model the AverStar compiler chooses, the compiler can
prove validity quite often.  For example, an 'in' parameter of an
integer type is always valid, because it was constraint checked at the
call site.  The constraint check at the call site is not required -- the
compiler is allowed to propagate invalid values all over the place, but
I think that's less efficient, because then you have more checks inside
the called procedure.  We also do flow analysis, to find cases where
variables are initialized by assignment statements on every path leading
to some place, rather than on the variable's declaration.

Again, I'm talking about the *intent* of the language design team.
Whether Robert Dewar or anyone else can see that intent in the RM
wording is another story.

- Bob

Re: Constraint checking of actuals passed to Attributes

[Robert A Duff]

Robert Dewar <robert_dewar@my-deja.com> writes:

> Now wait a cotton pickin moment (is that the way that phrase
> is spelled? :-)
> 
> What does the RM say:
>...

You asked me about the *intent*.  I don't claim that the RM precisely
specifies the intended rules, so you're quoting of the RM is irrelevant.
I do claim that the intent should be clear, at least for simple things
like integers, to someone who doesn't use an overly legalistic reading
of the RM.

After all, you argue that the RM wording has the same effect as the Ada
83 wording.  Clearly, if that were the intent of the language design
team, then we would have left the wording as in Ada 83, because it's
much simpler wording -- it just says that using an uninit scalar var is
erroneous.  We must have intended to make *some* change, since we
introduced new terminology ("invalid", "abnormal"), and new rules.

> That's why I dislike this business of divining intent so
> intensely. You end up asking the design team what they remember
> having in mind, and they may not even remember correctly.

It is indeed possible that I don't remember the intent correctly, or
never understood it correctly.

> This is perfectly predictable, quite reasonable (think about
> NaN's in floating point, and ENTIRELY allowable from the quoted
> paragraph read in the most friendly form possible).

Yes, NaN's are part of the reason the "intent" is so hard to specify
precisely, which is why the RM doesn't try.

> Similarly if I was on an IBM 7040, then it would be free to
> cause a fatal parity error terminating the program on any
> access to an uninitialized variable, and that would be just
> fine too (again, very NICE behavior, at least during the
> testing phase). ...

I believe the intent was not to allow such abrupt termination of the
program.  I agree that's "NICE behavior".  I've always thought Ada
should have a notion of killing a program (like "exit" or "abort" in C)
stronger than exceptions.  But it doesn't, and there was no mandate to
add such a notion in Ada 9X, so the only possible way of notifying of
errors is to raise an exception.

>... The WATFOR compiler used to do this (it used
> the hardware diagnostic instruction to set parity wrong on
> all uninitialized data).

ASIDE: You have to be careful about these low-level hardware-oriented
implementations, because they might not match Ada's notions.  For
example, in Ada, it is perfectly OK to copy an array full of
uninitialized components, using an assignment statement.  If the
hardware complains about that, then it's wrong.  I learned this when
writing an Ada compiler for the Symbolics Lisp machine, which had a
4-bit tag on every word, and there was an "undefined" tag, and it
detected any load of an undefined word.  But we had to disable that (by
zeroing uninit vars), which was kind of sad.

> It was my understanding that we put the words implementation
> defined in that paragraph precisely to allow a variety of
> possible implementations, all of which are reasonable.

Perhaps, but if doing so allows absolutely anything, then we made a
mistake (ie, we didn't write words precisely defining our intent).  We
certainly did not intend to allow the use of an uninit var as an array
index to trash arbitrary memory locations.  I realize that some
reviewers didn't like that (Bevin Brett, for example, thought the
trade-off should be in favor of efficiency).

- Bob

Re: Constraint checking of actuals passed to Attributes

[David C. Hoos, Sr.]

----- Original Message ----- 
From: Robert A Duff <bobduff@world.std.com>
Newsgroups: comp.lang.ada
Sent: May 09, 2000 6:13 PM
Subject: Re: Constraint checking of actuals passed to Attributes


<snip>  (English
> suffers from not having a clear singular for "your".;-))
How about "thine?"

Yes, I saw the smiley -- but I think modern "English" usage
is to 17th-/18th-century English somewhat as C is to Ada.
----- Original Message ----- 
From: Robert A Duff <bobduff@world.std.com>
Newsgroups: comp.lang.ada
Sent: May 09, 2000 6:13 PM
Subject: Re: Constraint checking of actuals passed to Attributes


<snip>  (English
> suffers from not having a clear singular for "your".;-))
How about "thine?"

Yes, I saw the smiley -- but I think modern "English" usage
is to 17th-/18th-century English somewhat as C is to Ada --
less to be desired.  Give me precision over brevity every time.

<snip>

Re: Constraint checking of actuals passed to Attributes

[Robert Dewar]

In article <wccitwnmi4r.fsf@world.std.com>,
  Robert A Duff <bobduff@world.std.com> wrote:
> I suppose I could try expressing the intent by example:
>
> If you say:
>
>     Uninit: Integer; -- Uninitialized variable!
>     ...
>     if Uninit < 10 then
>         ...
>
> The condition must be either True or False, or it must raise
> an exception.  It must not destroy other variable's values.
> Inside the if statement, Uninit must evaluate to a value less
> than 10.

Now wait a cotton pickin moment (is that the way that phrase
is spelled? :-)

What does the RM say:

9   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:

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

   11  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.

Where on earth do you manage to narrow down the result to
raising CE or PE or proceeding normally. It would be absolutely
FINE to terminate the program with an error message, and we
SPECIFICALLY discussed this as an appropriate meaning of
implementation-defined when we discussed this clause.

That's why I dislike this business of divining intent so
intensely. You end up asking the design team what they remember
having in mind, and they may not even remember correctly.

I can't see any possible way to read the "implementation
defined" above [which applies ONLY if you do NOT recognize
the situation and raise CE or PE) as being anywhere NEAR
as restrictive as Bob implies.

For example, the following is quite reasonable:

If an object in a boolean expression has an invalid value,
the result will always be false, regardless of the form
of the expression, e.g. a > 10 and a < 10 will both be
false.

This is perfectly predictable, quite reasonable (think about
NaN's in floating point, and ENTIRELY allowable from the quoted
paragraph read in the most friendly form possible).

In fact I would find a compiler that initialized all
"uninitialized" floating point values to NaN and then
said the predictable behavior was specified by the IEEE
rules for handling NaN's to be a very good implementation
of uninitialized.

Similarly if I was on an IBM 7040, then it would be free to
cause a fatal parity error terminating the program on any
access to an uninitialized variable, and that would be just
fine too (again, very NICE behavior, at least during the
testing phase). The WATFOR compiler used to do this (it used
the hardware diagnostic instruction to set parity wrong on
all uninitialized data).

It was my understanding that we put the words implementation
defined in that paragraph precisely to allow a variety of
possible implementations, all of which are reasonable.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Constraint checking of actuals passed to Attributes

[Matt Brennan]

Tucker Taft wrote:
> 
> Implementations are not required to deal nicely with the unchecked
> conversion or binary input situation, but are required to at least
> "survive" the uninitialized variable situation in Ada 95.

Tucker (and all others),
			thanks for your views and references. It seems another grey,
'implementation defined' area to investigate more fully with our
compiler vendor...

Regards,

  Matt 

--
-- Matt Brennan || Vision Systems Ltd || +61 8 8300 4686
--

Re: Constraint checking of actuals passed to Attributes

[Ted Dennison]

In article <391C543F.83B2A408@averstar.com>,
  Tucker Taft <stt@averstar.com> wrote:
 versus "abnormal" distinction.  Imagine the following:
>
>     Y : Very_Long_Integer range -5..5 := 4;
>    ...
>     Y := -5;  -- imagine abort or other "disruption" happens in middle
>            -- of this multi-word assignment, and Y ends up with a
weird value
>            -- like -4 billion (due to setting the high 32 bits to -1,
>            -- while leaving the low 32 bits as +4).
>            -- If then in finalization code or an exception handler
>            -- we write "A(Y) := 36".  Y might be abnormal and the
>            -- implementation is free to trash random memory.
>
> In other words, abnormal means out of range due to disruption, or
> "bad" binary input or unchecked conversion,
> whereas invalid means out of range due to lack of initialization or
> other "normal" behavior.  The implementation is supposed to "survive"

Thanks for the explanation. That distinction was exactly what I was
wondering about.

But I still don't understand the logic behind making misuse of an
overlay an "invalid" case rather than an "abonormal" (and thus
erronious) case. Couldn't it cause the same -4 billion value to get
placed into Y? The compiler would have no easy way to detect that the
state has changed to "invalid". How do you enforce that the program
"survives" this?

--
T.E.D.

http://www.telepath.com/~dennison/Ted/TED.html


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Constraint checking of actuals passed to Attributes

[Robert A Duff]

Ted Dennison <dennison@telepath.com> writes:

> But I still don't understand the logic behind making misuse of an
> overlay an "invalid" case rather than an "abonormal" (and thus
> erronious) case. Couldn't it cause the same -4 billion value to get
> placed into Y? The compiler would have no easy way to detect that the
> state has changed to "invalid". How do you enforce that the program
> "survives" this?

I'm not sure what you mean, here.  Could you post a specific example?
(Maybe you already did, but I've long since forgotten about it. ;-))

Certainly you can cause abnormal objects, and erroneousness, by certain
misuses of address clauses and unchecked conversions of access values,
both of which can be used to make overlays.

- Bob

Re: Constraint checking of actuals passed to Attributes

[Ted Dennison]

In article <wccsnvnsdpv.fsf@world.std.com>,
  Robert A Duff <bobduff@world.std.com> wrote:
> Ted Dennison <dennison@telepath.com> writes:
>
> > But I still don't understand the logic behind making misuse of an
> > overlay an "invalid" case rather than an "abonormal" (and thus

> Certainly you can cause abnormal objects, and erroneousness, by
certain
> misuses of address clauses and unchecked conversions of access values,
> both of which can be used to make overlays.

Can you? The relevant section in 13.9.1 only mentions aborted
assignements and parameters passed to imported procedures. But then
paragraph 14 does say that objects can become abnormal in other ways
too. Perhaps my problem is that I'm missing where "abmormal" is truly
defined.

--
T.E.D.

http://www.telepath.com/~dennison/Ted/TED.html


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Constraint checking of actuals passed to Attributes

[Tucker Taft]

Keith Thompson wrote:
> ...
> If I understand the context of this example correctly, the intent is
> to make these guarantees if Uninit is merely uninitialized, but not if
> it's abnormal (say, if an assignment to it was disrupted; see
> RM95-13.9.1).  The standard doesn't require bizarre things to happen
> under such circumstances, it merely withdraws its usual guarantee that
> bizarre things won't happen.  If the underlying hardware has no
> abnormal representations for type Integer, Integers will never become
> abnormal ("Whether or not an object actually becomes abnormal in these
> cases is not specified.")
> 
> This kind of thing is more likely to show up (on most systems) for
> things like composite objects with corrupted descriptors.  The most
> plausible scenario for type Integer that I can think of is a system
> that represents an integer as a floating-point value with the exponent
> set to zero (I'm not sure whether Ada allows this); something like a
> floating-point NaN would then be an abnormal value for type Integer.
> A less plausible scenario is
> an integer with the low-order bit set to 0.5.
> 
> I suppose the real requirement being imposed here is that, if the
> underlying system has "abnormal" representations for a given type, the
> Ada implementation must guarantee that an uninitialized variable isn't
> set to one of those representations.

That wasn't the problem we worried about when inventing the "invalid"
versus "abnormal" distinction.  Imagine the following:

    X : Very_Long_Integer range -5..5;
    Y : Very_Long_Integer range -5..5 := 4;
    A : array(Very_Long_Integer range -5..5) of Integer;

   ...

    A(X) := 37;  -- X might be invalid here, but not abnormal.
                 -- the implementation should not trash random memory
    A(Y) := 37;  -- Y is valid here (and normal)
    Y := -5;  -- imagine abort or other "disruption" happens in middle
           -- of this multi-word assignment, and Y ends up with a weird value
           -- like -4 billion (due to setting the high 32 bits to -1,
           -- while leaving the low 32 bits as +4).
           -- If then in finalization code or an exception handler
           -- we write "A(Y) := 36".  Y might be abnormal and the 
           -- implementation is free to trash random memory.

In other words, abnormal means out of range due to disruption, or
"bad" binary input or unchecked conversion,
whereas invalid means out of range due to lack of initialization or
other "normal" behavior.  The implementation is supposed to "survive"
out-of-range due to "normal" behavior (e.g. forgetting an initializer)
but not due to one of these "bad" things like disruption, etc.
Without this distinction, the implementation would have to assume
the worst about the value stored in a constrained object in many
more cases, making it that much harder to eliminate redundant range checks.

> 
> --
> Keith Thompson (The_Other_Keith) kst@cts.com  <http://www.ghoti.net/~kst>
> San Diego Supercomputer Center           <*>  <http://www.sdsc.edu/~kst>
> Welcome to the last year of the 20th century.

-- 
-Tucker Taft   stt@averstar.com   http://www.averstar.com/~stt/
Technical Director, Commercial Division, AverStar (formerly Intermetrics)
(http://www.averstar.com/services/IT_consulting.html)  Burlington, MA  USA

Re: Constraint checking of actuals passed to Attributes

[Simon Wright]

Robert A Duff <bobduff@world.std.com> writes:

> In the run-time model the AverStar compiler chooses, the compiler can
> prove validity quite often.  For example, an 'in' parameter of an
> integer type is always valid, because it was constraint checked at the
> call site.

Presumably this isn't true if the subprogram was exported ..

Re: Constraint checking of actuals passed to Attributes

[Bill Greene]

Robert Dewar wrote:
> 
> Now wait a cotton pickin moment (is that the way that phrase
> is spelled? :-)

"cotton-pickin' minute"

-- 
William R. Greene                              1100 Perimeter Park Drive
Ganymede Software, Inc.                                        Suite 104
http://www.ganymede.com                       Morrisville, NC  27560 USA
Phone: (919) 469-0997, ext. 280                      Fax: (919) 469-5553

Re: Constraint checking of actuals passed to Attributes

[Robert A Duff]

Ted Dennison <dennison@telepath.com> writes:

> 
> In article <wccsnvnsdpv.fsf@world.std.com>,
>   Robert A Duff <bobduff@world.std.com> wrote:
> > Certainly you can cause abnormal objects, and erroneousness, by
> certain
> > misuses of address clauses and unchecked conversions of access values,
> > both of which can be used to make overlays.
> 
> Can you? The relevant section in 13.9.1 only mentions aborted
> assignements and parameters passed to imported procedures.

Well, for address clauses, I guess I should have said just "cause
erroneousness".  If it can do that, then it can do any other bad thing
you can name, so it's kind of silly to argue about whether it can cause
abnormal values.  13.3(13) says it can be erroneous.

For unchecked conversions, 13.9(11) says the result can be abnormal
except in certain (non-pointerish) cases.

The difference between abnormal and erroneous is pretty small --
abnormal is just one small step short of disaster (where erroneous =
disaster).

>... But then
> paragraph 14 does say that objects can become abnormal in other ways
> too. Perhaps my problem is that I'm missing where "abmormal" is truly
> defined.

Well, I was going to admonish you to look it up in the index, but I see
the index is incomplete in this case.  :-(
I suggest you get the plain-ascii version of the AARM, and search for
abnormal.

- Bob

Re: Constraint checking of actuals passed to Attributes

[Ted Dennison]

In article <wccln1a5wh8.fsf@world.std.com>,
  Robert A Duff <bobduff@world.std.com> wrote:
> Ted Dennison <dennison@telepath.com> writes:
> > Can you? The relevant section in 13.9.1 only mentions aborted
> > assignements and parameters passed to imported procedures.
>
> Well, for address clauses, I guess I should have said just "cause
> erroneousness".  If it can do that, then it can do any other bad thing
> you can name, so it's kind of silly to argue about whether it can
cause
> abnormal values.  13.3(13) says it can be erroneous.

That just said that the address has to be "valid", not the value at that
address. So I had interpreted that to mean that the address had to be
within the program's adddress space, and perhaps allocated. For
instance, on DOS it can't refer to an unallocated I/O memory location.
In VMS, it can't have the high address bit set, etc.

After all, one could argue that any address on the stack is "valid".
Some may not contain valid values for type Foo, but the addresses
themselves are valid.

> > too. Perhaps my problem is that I'm missing where "abmormal" is
> > truly defined.
>
> Well, I was going to admonish you to look it up in the index, but I
> see the index is incomplete in this case.  :-(

:-) Thanks for checking. I *did* try that first.


> I suggest you get the plain-ascii version of the AARM, and search for
> abnormal.

Done. 7.6.1(2) sort of defines it by context.


The whole reason for this LRM-diving expedition on my part was to try to
figure out how exactly the 95 LRM views the address clause type-hosing
technique. In the old Ada it used be erronious.

My reading of what I have seen in the LRM says that it is not defined by
the language to ever be erronious, as long as the addressee object
exists and any extra bytes the addressor type needs also happen to be in
existing objects. Since there's no way to guarantee the latter, then one
could say its perfectly OK, as long as the addressee object is at least
as large as the addressor.

Based on your text above about the meaning of 13.3(13), I'm guessing
you'd say that the execution can be erronious if the value at that
address is not valid for the addressor's type. However, using 13.3(13)
for this purpose seems inconvienent, because it is only talking about
the addressor object. So technically its not defined as erronious if the
program causes the value to be invalid for the addressee type by
assigning that value via the addressor type.

--
T.E.D.

http://www.telepath.com/~dennison/Ted/TED.html


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Constraint checking of actuals passed to Attributes

[Robert A Duff]

Simon Wright <simon@pogner.demon.co.uk> writes:

> Robert A Duff <bobduff@world.std.com> writes:
> 
> > In the run-time model the AverStar compiler chooses, the compiler can
> > prove validity quite often.  For example, an 'in' parameter of an
> > integer type is always valid, because it was constraint checked at the
> > call site.
> 
> Presumably this isn't true if the subprogram was exported ..

You mean exported as in pragma Export?  It's true even in that case.
Eg:

    procedure P(X: Positive) is
	S: String(1..10);
    begin
        S(X) := 'x';
    end P;

Inside P, we assume X is in Positive.  On the assignment, the generated
code will check that X <= 10, but will *not* check that X >= 1.  If you
call P from C code, it's your responsibility to pass the correct stuff.
If you pass in a negative value, you will overwrite an arbitrary memory
location.

This is always true: you always lose all checking (compile time and run
time) at the interface between Ada and some foreign language.

- Bob

Re: Constraint checking of actuals passed to Attributes

[Robert Dewar]

In article <wccln1a5wh8.fsf@world.std.com>,
  Robert A Duff <bobduff@world.std.com> wrote:
> The difference between abnormal and erroneous is pretty small
> abnormal is just one small step short of disaster (where
> erroneous disaster).

Hmmm! It would clearly be absolutely conformant to have
a compiler which when you accessed an abnormal variable
and caused erroneousity which in practice was mild in
effect, and on the other hand where any access to an
uninitialized variable was defined by the implementation
to delete all picture and movie files from your disk,
send messages to all the people on your outlook
list, and send messages about your configuration back
to the Phillipines. As long as this was appropriately
documented (see thread on documentation requirements),
this would be valid behavior.

Trying to categorize levels of disaster is a tricky game :-)

No doubt Bob will protest that the reference to implementation
defined that I am exploiting here was not intend to allow
this *particular* definition, arguing from (reverant music
starts --- O R I G I N A L   I N T E N T).

In practice, I think the important thing is that compilers do
reasonable things, and have several modes corresponding to
various desirable behaviors in terms of undefined behavior.




Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Constraint checking of actuals passed to Attributes

[Kenneth Almquist]

Robert A Duff wrote:
> I suppose I could try expressing the intent by example:
>
> If you say:
>
>     Uninit: Integer; -- Uninitialized variable!
>     ...
>     if Uninit < 10 then
>         ...
>
> The condition must be either True or False, or it must raise an
> exception.  It must not destroy other variable's values.  Inside the
> if statement, Uninit must evaluate to a value less than 10.
>
> Obviously that's not a formal definition -- it's just an example of the
> intent.
>
> If I could give a formal definition of the intent, I would have done so
> in the RM -- I didn't then, because it's hard, and it's still hard
> today.  I don't think it's impossible to formalize that intent.
>
> If you start asking me about floating-point NaN's, or holes in
> rep-speced enums, I'll start hemming and hawing.  But for plain old
> integers and enums, I think I kown what was "intended".
>
> At least I can give lots of examples.  ;-)

As I understand it, the main reason for deviating from Ada 83 was that
in Ada 83 an uninitialized variable could result in memory overwrites
when used as a subscript and wild jumps when used in a case statement:
	type Index is new Integer range 1 .. 5;
	A : array(Index) of Integer;
	I : Index;
	A(I) := 1;	-- The compiler need not check that I is in 1..5.
	case I is	-- The compiler may generate code that branches
	    ...		-- to an arbitrary location if I is not in 1..5.
	end case;

Fixing these two problems is tedious, but not particularly hard.
In outline:

  1.  The value of an uninitialized scalar variable or scalar component
      of a composite type is either a valid value of the specified
      subtype, or an "illegal value."

  2.  If the value of X is an illegal value, then X'Valid is false.

  3.  If the value of X is an illegal value, then reading the value
      of X is a bounded error.  The possible results are:
      1.  Program_Error is raised,
      2.  Constraint_Error is raised,
      3.  the result is an illegal value, or
      4.  the result is some valid value.

  4.  If X names a scalar object, then assigning an illegal value to
      X is a bounded error.  The possible effects are:
      1.  Program_Error is raised,
      2.  Constraint_Error is raised,
      3.  X is set to an illegal value, or
      4.  X is set to some valid value.

  5.  Using an illegal value as the operand to a predefined operator,
      or as the argument to a function specified by the attributes
      S'floor, S'ceil, S'adjacent, S'leading_part, S'length, S'max,
      S'min, S'pos, S'pred, S'succ, or S'val, is a bounded error.  The
      possible results are the same as those for reading a variable
      with an illegal value.

  6.  The result of applying the T'Image operation to an illegal value
      is implementation defined.

  7.  Using an illegal value as a subscript is a bounded error.  The
      possible results are:
      1.  Program_Error is raised,
      2.  Constraint_Error is raised,
      3.  a valid value is substituted for the illegal value, or
      4.  the result of the subscript operation refers to an "illegal
          object".

  8.  Reading the value of an illgal object or a component of an
      illegal object is a bounded error.  If the type of the object
      or component is not a pointer type, then the possible results
      are the same as those for reading an uninitialized variable.
      Otherwise, the possibilities are that Program_Error is raised,
      Constraint_Error is raised, or a null pointer value is returned.

  9.  Writing to an illegal object is a bounded error.  It has no
      effect except for possibly raising Program_Error or Constraint_
      Error.

 10.  It is a bounded error to use an illegal value as the control value
      for an if, while, or case statement.  The possible results are:
      1.  Program_Error is raised,
      2.  Constraint_Error is raised,
      3.  a valid value is substituted for the illegal value.

 11.  It is a bounded error for the limit on a range used in a subtype
      or array type specification to be an illegal value.  The result
      is that the set of values included in the range is undefined.
      In addition, the use of attributes defined in terms of the
      illegal value (X'first, X'last, X'length) is a bounded error;
      the possible results are the same as those for reading an
      uninitalized variable.

 12.  It is a bounded error for the limit on the range in a "for"
      statement to be an illegal value.  The results is that the
      sequence of values taken on by the control variable of the
      for loop is undefined.  [We don't require the sequence to be
      finite because a sequence of length 2**64 (which is possible
      on 64 bit machines) is effectively infinite.]

Probably I've missed a few cases, but it should be fairly obvious
how to fill in the gaps.

Your requirement that, "Inside the if statement, Uninit must evaluate
to a value less than 10," does not have anything to do with safety
that I can see (unless the value of Uinit is passed to a routine
written in another language).  So your example makes it clear that
the intent goes beyond avoiding the memory overwrite and wild jump
problems that I list at the start of this article.  However, I still
have no clue as to what this additional intent is.  So my question
is:  Beyond avoiding the two problems that I identified above, what
else was the team attempting to accompish?
				Kenneth Almquist