comp.lang.ada
 help / color / mirror / Atom feed
From: James Rogers <jimmaureenrogers@worldnet.att.net>
Subject: Re: Ada 0x: Re: Representation clause
Date: Mon, 26 Feb 2001 20:20:15 GMT
Date: 2001-02-26T20:20:15+00:00	[thread overview]
Message-ID: <3A9ABAF9.F3EABF90@worldnet.att.net> (raw)
In-Reply-To: 3tym6.3352$7e6.1360491@homer.alpha.net

Randy Brukardt wrote:
> 
> James Rogers wrote in message <3A97F419.6E2F075@worldnet.att.net>...
> >My assertion that Program_Error will be raised is based upon the result
> >of tests using GNAT 3.13p. Note that my code does NOT rely on that or
> >any other exception being raised to run properly. It detects the
> >erroneous condition without causing any exception to be raised.
> 
> Basing it on the RM, rather than a particular compiler, would be better.

This is a curious statement. How does the RM solve this problem?
Section 13.9 discusses unchecked conversion issues. Section 13.9.1
states that use of Ada.Unchecked_Conversion can result in an
invalid representation. 13.9.1 states "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.

If the representation of a scalar object does not represent a value
of the object's subtype, 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."

Note that the GNAT 3.13p action of raising Program_Error is fully
supported by this clause in the RM.

Also note that my code compeletly avoids the creation of invalid
data by checking the numeric value against all correct valid
internal representations for the enumerated type. This check is
done before converting the numeric value to the enumerated type.
If the numeric value is not in the set of valid internal 
representation values for the enumerated type, my code raises its
own exception "Out_Of_Range_Error". This is appropriate rather
than raising Constraint_Error or Program_Error because no invalid
representation is created. 

>
> >It does raise its own exception when an erroneous condition is
> >detected.
> >
> >I admit that I may have generalized the response too much based upon
> >testing with one compiler. On the other hand, my solution does not
> >rely on that generalization. I therefore feel that my solution is only
> >half bad :-).
> 
> Why didn't you use the 'Valid attribute for the check? Then you can can
> avoid the erroneous behavior. (Your current code is erroneous if the
> representation is out of range, and while it *probably* will work on all
> Ada compilers, there is no guarentee of that.)

Note that section 13.9 states that data can contain an invalid
representation. The code is only erroneous if one attempts to 
evaluate the data containing an invalid representation. The
program is not erroneous if an invalid representation never occurs.

I would have to create an invalid representation in order to perform
a 'Valid check. Why is this preferred over detecting an out of
range source for conversion, and raising an exception to avoid
an invalid representation? As has been demonstrated above, it is
possible for a compiler to detect the invalid representation and
raise either Constraint_Error of Program_Error. What is the value
of attempting to use the 'Valid attribute if the compiler will
raise an exception before the 'Valid attribute can be checked?

Jim Rogers
Colorado Springs, Colorado USA



  reply	other threads:[~2001-02-26 20:20 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-02-23  2:39 Representation clause Anatoly Chernyshev
2001-02-23  3:59 ` James Rogers
2001-02-23  8:46   ` Ada 0x: " Martin Dowie
2001-02-23  9:01     ` Lutz Donnerhacke
2001-02-23 10:22       ` David C. Hoos, Sr.
2001-02-23 13:56         ` Florian Weimer
2001-02-23 14:57           ` David C. Hoos, Sr.
2001-02-23 21:38             ` Florian Weimer
2001-02-23 21:12     ` Randy Brukardt
2001-02-24  5:44       ` James Rogers
2001-02-24 10:43         ` Florian Weimer
2001-02-24 17:47           ` James Rogers
2001-02-26 19:51             ` Randy Brukardt
2001-02-26 20:20               ` James Rogers [this message]
     [not found]                 ` <WURm6.3437$7e6.1392211@homer.alpha.net>
2001-02-28  2:32                   ` James Rogers
2001-02-23 13:25 ` Marc A. Criley
2001-02-23 14:08 ` Des Walker
2001-02-24 13:26 ` David C. Hoos, Sr.
2001-02-24 14:45   ` Ken Garlington
2001-02-25 20:22     ` David C. Hoos, Sr.
2001-02-26  0:53       ` Ken Garlington
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox