* Type conversion from Universal Integer
@ 1993-03-03 22:48 R. Muralidhar
1993-03-04 13:12 ` Dave Collard x7468
0 siblings, 1 reply; 2+ messages in thread
From: R. Muralidhar @ 1993-03-03 22:48 UTC (permalink / raw)
Hi,
I have the following piece of code
-------------------------------------------------------------------------
package P is
type A is range 1 .. 10;
type Array_Constrained_Type is array ( A range <> ) of Integer;
end P;
with P;
procedure test is
Const : constant := 5;
type Local_A is range 1 .. 10;
type Local_Array_Constrained_Type is array ( Local_A range <> ) of Integer;
subtype Array_type1 is P.Array_Constrained_Type(1 .. (const/2)); -- Line A
subtype Array_type2 is P.Array_Constrained_Type(1 .. P."/"(const,2)); -- Line B
subtype Array_type3 is Local_Array_Constrained_Type(1 .. (const/2)); -- Line C
begin
null;
end test;
-------------------------------------------------------------------------
detect an error on DEC Ada compiler, in the line marked "Line A", saying:
%ADAC-E-RESTYPINCON, (1) Result type of expression is inconsistent with its
context, which requires integer type A in P at line 2 [LRM 8.7]
But the same piece of code compiled fine under Verdix Ada Compiler on Sun.
Line B compiled fine in both compilers, so did Line C.
Am I dealing here with some interpretation of a language feature that is
implementation dependent? Or is it that one or the other compiler is wrong?
Also, LRM 4.6(15) says that "An implicit conversion of an operand of
universal integer to another integer type, ..., can only be applied if the
operand is either a numeric literal, a named number, or an attribute;"
I take it that the compiler tries to implicitly convert to the integer type A,
the upper and lower bounds of the specified ranges in all three lines,
Line A, Line B, and Line C. Since (const/2) is an expression and is not a
numeric literal, not a named number, and not an attribute, the compiler(s)
should have detected errors in all three lines.
Any help in explaining this situation will be greatly appreciated.
Thanks in advance.
_
/|/), , ;_ _ // .
(/ /(_<_/ '(_(_X_<_
murali@saifr00.cfsat.honeywell.com
Muralidhar Rajappa
Honeywell Commercial Flight Systems Group
Phoenix AZ
--
_
/|/), , ;_ _ // .
(/ /(_<_/ '(_(_X_<_
murali@saifr00.cfsat.honeywell.com
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: Type conversion from Universal Integer
1993-03-03 22:48 Type conversion from Universal Integer R. Muralidhar
@ 1993-03-04 13:12 ` Dave Collard x7468
0 siblings, 0 replies; 2+ messages in thread
From: Dave Collard x7468 @ 1993-03-04 13:12 UTC (permalink / raw)
In <1993Mar3.224845.18874@saifr00.cfsat.honeywell.com> murali@saifr00.cfsat.honeywell.com (R. Muralidhar) writes:
> -------------------------------------------------------------------------
>package P is
> type A is range 1 .. 10;
> type Array_Constrained_Type is array ( A range <> ) of Integer;
>end P;
>with P;
>procedure test is
> Const : constant := 5;
> type Local_A is range 1 .. 10;
> type Local_Array_Constrained_Type is array ( Local_A range <> ) of Integer;
> subtype Array_type1 is P.Array_Constrained_Type(1 .. (const/2)); -- Line A
> subtype Array_type2 is P.Array_Constrained_Type(1 .. P."/"(const,2)); -- Line B
> subtype Array_type3 is Local_Array_Constrained_Type(1 .. (const/2)); -- Line C
>begin
> null;
>end test;
> -------------------------------------------------------------------------
> detect an error on DEC Ada compiler, in the line marked "Line A", saying:
>%ADAC-E-RESTYPINCON, (1) Result type of expression is inconsistent with its
> context, which requires integer type A in P at line 2 [LRM 8.7]
>But the same piece of code compiled fine under Verdix Ada Compiler on Sun.
no comment.
>Line B compiled fine in both compilers, so did Line C.
>Am I dealing here with some interpretation of a language feature that is
>implementation dependent? Or is it that one or the other compiler is wrong?
>Also, LRM 4.6(15) says that "An implicit conversion of an operand of
>universal integer to another integer type, ..., can only be applied if the
>operand is either a numeric literal, a named number, or an attribute;"
>I take it that the compiler tries to implicitly convert to the integer type A,
>the upper and lower bounds of the specified ranges in all three lines,
>Line A, Line B, and Line C. Since (const/2) is an expression and is not a
>numeric literal, not a named number, and not an attribute, the compiler(s)
>should have detected errors in all three lines.
Ah, but Const IS a named number and 2 is a numeric literal, so,
In line B, Const and 2 are converted to type P.A because the only P."/" available
that matches the required return type (P.A) is the inherited division operator
for type P.A.
In line C the same thing is true except replace P.A with Local_A.
Now Line A. The expression (const/2) MUST evaluate to type P.A. The only
division operator available that returns P.A is the one inherited in package
P when the type A was derived. That operation is not visible (as you did not
use P). Therefore, no division operator is visible which returns type P.A.
The DEC compiler is correct (as usual).
--Thor
collard@capsrv.jhuapl.edu
dlc@ddsdx2.jhuapl.edu
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~1993-03-04 13:12 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1993-03-03 22:48 Type conversion from Universal Integer R. Muralidhar
1993-03-04 13:12 ` Dave Collard x7468
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox