schroed@fbihh.UUCP (Carsten Schroeder) (06/08/90)
Hi folks,
up to now we were running VAX-Ada 1.5 but 2 weeks ago we installed VAX-Ada 2.1.
When recompiling the whole stuff after converting the libraries I finally ended
up with a compilation-error in a package-body which could be compiled under
VAX-Ada 1.5 without any problems.
I tried to isolate the problem and append the sources at the end of this
article. All of the compilation-units given below can be compiled without any
problems under VAX-Ada 1.5. Under VAX-Ada 2.1 compiling the body of the package
tools (TOOLS.ADA) results in the following messages:
6 PACKAGE my_image_io IS NEW image_io (pixel_type,
7 image_type,
.................................................1
%ADAC-E-GENACTNOTCONSTR,
(1) Type image_type in tools at line 4 is not constrained
[LRM 12.3.2(4), 13.7a.1, 13.10.2(2+)]
%ADAC-I-GENACTNOCONST2,
(1) Corresponding formal type image_type in image_io at line 3 is used within
generic package image_io in image_io at line 1 as an actual corresponding
to formal type TARGET in predefined UNCHECKED_CONVERSION
%ADAC-I-GENACTNOCONST1U,
(1) Generic formal type TARGET in predefined UNCHECKED_CONVERSION does not
allow an unconstrained actual array type or an unconstrained actual type
with discriminants (with or without defaults)
You can make him compile the whole think if you choose another compilation
order, i.e. compiling the body of image_io at the very end, but then you'll get
the same error on compiling any program that uses the procedure
get_image_section_file provided in the package tools.
The package test_io at the end simply shows that the package image_io can be
instantiated with an unconstraind array without any problems in another
situation. The one thing different in this case, i.e. the known pixel_type,
is not what it makes working; you get the same error on compiling the
body of tools if you delete pixel_type as a generic formal type and define
it as a type (as an integer lets say) in the specification of the package
tools before the definition of the generic procedure get_image_section_file.
I suspect that this new behaviour results from a misinterpretation of
section 12.3.2(4) of the Ada Language Reference Manual by the implementors at
DEC. I myself do not fully understand this section ether (actually, I'm not a
lawyer) and I would be interested if anybody else does.
Is there anybody who has the same problem, knows whether the compiler
(i.e. DEC) is right at this point or not, understands section 12.3.2(4),
knows what could be done, or can provide any other information
about this problem?
Since I'm not reading comp.lang.ada every time, please reply to my address
given below. I'll forward the answers to anybody interested.
Thanks a lot in advance,
Carsten Schroeder | Universitaet Hamburg
| Fachbereich Informatik
phone: +49 40 4123 6144 | Bodenstedtstrasse 16
FAX: +49 40 4123 6530 | D-2000 Hamburg 50
schroeder@rz.informatik.uni-hamburg.dbp.de | Fed. Rep. Germany
-------------------------------------------------------------------------------
***** IMAGE_IO_.ADA ***********************************************************
GENERIC
TYPE pixel_type IS PRIVATE;
TYPE image_type IS ARRAY (natural RANGE <>,
natural RANGE <>) OF pixel_type;
TYPE image_pointer IS ACCESS image_type;
PACKAGE image_io IS
PROCEDURE get (image: OUT image_pointer;
file_name: IN string);
-- Read an image from disk if you do not know its size
END image_io;
***** IMAGE_IO.ADA ************************************************************
WITH text_io, sequential_io, unchecked_conversion;
PACKAGE BODY image_io IS
PROCEDURE get(image: OUT image_type;
file_name: IN string) IS
TYPE line_type IS ARRAY (image'RANGE(2)) OF pixel_type;
TYPE constr_image_type IS ARRAY (image'RANGE(1)) OF line_type;
PRAGMA pack (line_type);
PRAGMA pack (constr_image_type);
SUBTYPE new_image_type IS image_type (image'RANGE(1), image'RANGE(2));
FUNCTION convert_image IS NEW unchecked_conversion
(source => constr_image_type,
target => new_image_type);
PACKAGE line_io IS NEW sequential_io(line_type);
USE line_io;
file: file_type;
constr_image: constr_image_type;
BEGIN
open(file, in_file, file_name);
FOR row IN constr_image'RANGE
LOOP
read(file, constr_image(row));
END LOOP;
close(file);
image:= convert_image (constr_image);
END get;
PROCEDURE get (image: OUT image_pointer;
file_name: IN string) IS
rows : natural := 512; -- initialization only for test purposes
columns : natural := 512; -- see call of image_size below
foo : image_pointer;
BEGIN
-- image_size (file_name, rows, columns); -- commented out for test
foo:= NEW image_type (0 .. rows-1, 0 .. columns-1);
get (foo.ALL, file_name);
image:= foo;
END get;
END image_io;
**** TOOLS_.ADA ***************************************************************
PACKAGE tools IS
GENERIC
TYPE pixel_type IS PRIVATE;
TYPE image_type IS ARRAY (natural RANGE <>,
natural RANGE <>) OF pixel_type;
TYPE image_pointer IS ACCESS image_type;
PROCEDURE get_image_section_file (name : string);
END tools;
***** TOOLS.ADA ***************************************************************
WITH image_io;
PACKAGE BODY tools IS
PROCEDURE get_image_section_file (name : string) IS
PACKAGE my_image_io IS NEW image_io (pixel_type,
image_type,
image_pointer);
image : image_pointer;
BEGIN
my_image_io.get (image, name);
-- The interesting rest has been deleted for test purposes!
END get_image_section_file;
END tools;
**** TEST_IO_.ADA *************************************************************
WITH image_io;
PACKAGE test_io IS
GENERIC
TYPE pixel_type IS PRIVATE;
PACKAGE generic_image_types IS
TYPE mono_image IS ARRAY (natural RANGE <>,
natural RANGE <>) OF pixel_type;
TYPE mono_image_pointer IS ACCESS mono_image;
PRIVATE
PRAGMA pack (mono_image);
END generic_image_types;
PACKAGE int_image_types IS NEW generic_image_types (integer);
PACKAGE int_mono_image_io IS NEW image_io
(integer
int_image_types.mono_image,
int_image_types.mono_image_pointer);
END test_io;
*******************************************************************************karl@grebyn.com (Karl A. Nyberg) (06/08/90)
In article <410@fbihh.UUCP> schroed@fbihh.UUCP (Carsten Schroeder) writes: > 6 PACKAGE my_image_io IS NEW image_io (pixel_type, > 7 image_type, >.................................................1 >%ADAC-E-GENACTNOTCONSTR, > (1) Type image_type in tools at line 4 is not constrained > [LRM 12.3.2(4), 13.7a.1, 13.10.2(2+)] >%ADAC-I-GENACTNOCONST2, > (1) Corresponding formal type image_type in image_io at line 3 is used within > generic package image_io in image_io at line 1 as an actual corresponding > to formal type TARGET in predefined UNCHECKED_CONVERSION >%ADAC-I-GENACTNOCONST1U, > (1) Generic formal type TARGET in predefined UNCHECKED_CONVERSION does not > allow an unconstrained actual array type or an unconstrained actual type > with discriminants (with or without defaults) > >I suspect that this new behaviour results from a misinterpretation of >section 12.3.2(4) of the Ada Language Reference Manual by the implementors at >DEC. I myself do not fully understand this section ether (actually, I'm not a >lawyer) and I would be interested if anybody else does. This set of files compiles fine under VADS 6.0.1(a) for VAX/Ultrix. I'm not a language lawyer either (where's Bob Eachus when you need him - probably on his way to Dublin... :-)) Maybe what is missing is AI-00037/12-BI-WJ (a binding AI, approved all the way through ISO to the Director of the AJPO), which reads in part: For occurrences of the name of a formal private type at places where this name is used as an unconstrained subtype indication, the actual subtype can be an unconstrained type with discriminants that have defaults even if an occurrence of the formal type is at a place where either a constraint or default discriminants would be required for a type with discriminants. The same applies to occurrences of the name of a subtype of the formal type, and to occurrences of the name of any type or subtype derived, directly or indirectly, from the formal type. -- Karl --
eachus@linus.mitre.org (Robert I. Eachus) (06/09/90)
In article <20120@grebyn.com> karl@grebyn.com (Karl A. Nyberg) writes:
I'm not a language lawyer either (where's Bob Eachus when you need
him - probably on his way to Dublin...
Not yet... This case looks like a compiler bug pure and simple,
so I thought I'd give DEC a chance to respond first. AI-37 is just a
red herring here (it deals with record subtypes with default
discriminants).
The program as written appears to be legal, but whether this
particular use of UNCHECKED_CONVERSION must be accepted is currently
being studied, as is whether it is meaningful on all implementations
or has an implementation defined meaning. I would personally write
this conversion function in a portable manner, and hope that the
optimizer was good enough to just do a straight copy where possible.
The overead of the read and write operations will probably swamp any
slowdown due a portable copy, and may also result in better checking.
--
Robert I. Eachus
with STANDARD_DISCLAIMER;
use STANDARD_DISCLAIMER;
function MESSAGE (TEXT: in CLEVER_IDEAS) return BETTER_IDEAS is...schroed@fbihh.UUCP (Carsten Schroeder) (06/11/90)
karl@grebyn.com (Karl A. Nyberg) writes: >This set of files compiles fine under VADS 6.0.1(a) for VAX/Ultrix. I'm not >a language lawyer either (where's Bob Eachus when you need him - probably on >his way to Dublin... :-)) Maybe what is missing is AI-00037/12-BI-WJ (a >binding AI, approved all the way through ISO to the Director of the AJPO), >which reads in part: > For occurrences of the name of a formal private type at places where > this name is used as an unconstrained subtype indication, the actual > subtype can be an unconstrained type with discriminants that have > defaults even if an occurrence of the formal type is at a place > where either a constraint or default discriminants would be required > for a type with discriminants. The same applies to occurrences of > the name of a subtype of the formal type, and to occurrences of the > name of any type or subtype derived, directly or indirectly, from > the formal type. >-- Karl -- The VAX-Ada documentation states that AI-00037 was included in Version 2.1, but if I understand this interpretation right it does not apply to unconstraint arrays but only to unconstraint records. What is actually needed is a similar Ada-Interpretion applying to unconstraint arrays. I think this interpretation is a funny character, because it states almost the opposite of what the original LRM-section 12.3.2(4) states. Any disagreement? Thanks a lot,