| This problem propmted us to change DEC Ada's behavior. See text below.
We are now changing that behavior in a V3.3 ECO kit.
--------------
This text describes changes to the OpenVMS Alpha V3.3 ECO compiler
concerning exported subprogram's passing mechanisms for string data.
A series of customer problem reports have made changes and
clarification necessary.
The fix described below will be in an Ada ECO kit, ADAAE23033,
which is currently being processed for ECO submission. Look for an
announcement in note stream 3644.*, or contact me directly if you
need an early kit.
This change affects exported subprograms only on DEC Ada on OpenVMS
Alpha only. This memo will also document what the new behavior will
be for a variety of situations.
History of this issue:
1. DEC Ada V3.0 used VAX Descriptors for passing string data in
exported subprograms, which conforms to the VMS calling
standard.
2. DEC Ada V3.2 changed to use dope vectors (different format,
internal to DEC Ada format) to pass string data. This was
for several reasons, including efficiency, and support of
array indexes with 64 bit integer types (descriptors can not
be used for this case).
3. IPMT HPAQ73436, Ada note 3602. User reported
problems with V3.2, exporting an Ada subprogram and calling
it from Fortran. Fortran passes a VAX Descriptor, and Ada
used it as if it were a dope vector. Program got an access
violation, because Fortran did not understand dope vectors.
4. DEC Ada V3.3 was changed, intending to return to the V3.0
behavior, to use VAX descriptors for exported subprograms.
This change fixed IPMT HPAQ73436, but made the importing and
exporting of an Ada subprogram use different passing
mechanisms (importing Ada subprograms default to dope vectors
unless an explicit passing mechanism is given).
5. IMPT ZUO100962, Ada note 3784. User had problems with V3.3
change for HPAQ73436.
Ada engineering answered that the new behavior is was
expected, explained why, and gave recommended source changes.
6. Ada note 3819. Same user reports problem with variant record
and CONSTRAINT_ERROR. They had changed their source, due to
Ada's answer for IPMT ZUO100962, specifying "default" to
pragma interface, instead of "ada". This does not pass
information on the constrainedness of in-out and out record
parameters.
DEC Ada V3.3 ECO for OpenVMS Alpha will return to the V3.2 behavior.
Dope vectors will be the default for exported Ada subprograms without
pragmas detailing what parameter's passing mechanism should be.
Note that subprograms explicitly giving passing mechanisms in pragmas
will get the mechanisms specified in the pragma. That will not be
changed by this compiler change.
Users exporting Ada subprograms to non-Ada languages with string data
may again need to specify passing mechanisms of descriptors for use
with other subprograms not written in Ada:
pragma export_procedure( ...
mechanism => DESCRIPTOR (class => <class_name>))
See the Language Reference Manual, section 13.9a.1.4 for more
information.
Alternatively, a new compiler switch can be used:
/EXPORT_INTERFACE = { ADA | FORTRAN | DEFAULT }
which will specify a preferred language interface for exported
subprograms as is done with the INTERFACE pragma for imported
subprograms. This compiler qualifier will be in effect for all
exported subprograms in a compilation unless a specific pragma is
given with a passing mechanism.
o ADA will specify to use the dope vector passing mechanism.
o FORTRAN or DEFAULT will specify the descriptor passing
mechanism.
|