• Aucun résultat trouvé

If the value returned has different attributes from those specified in the

Dans le document OS PL/I (Page 128-131)

parameter descriptor, conversion is performed. For example:

Chapter 9: Subroutines and Functions 115

A: PROCEDURE;

DECLARE B ENTRY,

C ENTRY(FLOAT);

x

= C(B);

END A;

In this case, B is invoked and its returned value is passed to C.

Consider the following example:

CALLP: PROCEDURE;

DECLARE RREAD ENTRY,

SUBR ENTRY (ENTRY, FLOAT, FIXED BINARY, LABEL);

GET LIST (R,S);

CALL SUBR (RREAD, SQRT(R), 5, LABl) ;

LABl: CALL ERRT (5) ;

END CALLP;

SUBR: PROCEDURE (NAME, X, J, TRANPT);

DECLARE NAME ENTRY, TRANPT LABEL;

IF X

>

J THEN CALL NAME(J);

ELSE GO TO TRANPT;

END SUBR;

In this example, assume that CALLP, SUBR, and RREAD are external. In CALLP, both RREAD and SUBR are explicitly declared to have the ENTRY attribute. The explicit declaration for SUBR is used to provide information about the characteristics of the parameters of SUBR. Four arguments are specified in the CALL SUBR statement.

These arguments are interpreted as follows:

1. The first argument, ~READ, is

recognized as an entry name (because of the ENTRY attribute declaration).

This argument is not in conflict with the first parameter descriptor

specified in the ENTRY attribute declaration for SUBR in CALLP.

116 OS PL/I CKT AND OPT LRM PART I

Therefore, since RREAD is recognized as an entry name and not as a £unction reference, the entry name is passed at invocation. Since NAME is an entry parameter, i t is given the attribute VARIABLE by default. Since RREAD is a constant, a dummy entry argument is created, and this is passed to NAME.

2. The second argument, SQRT(R), is recognized as a built-in function reference because of the argument list accompanying the entry name. SQRT is invoked, and the value returned by SQRT is aSSigned to a dummy argument, which will be passed to the subroutine SUBR. The attributes of the dummy argument agree with those of the second parameter, as specified in the parameter attribute list declaration.

When SUBR is invoked, the dummy argument is passed to it.

3. The third argument, S, is simply a decimal floating-point element variable. However, since its

attributes do not agree with those of the third parameter, a dummy argument is created containing the value of 5 converted to the attributes of the third parameter. When SUBR is

invoked, the dummy argument is passed.

4. The fourth argument, LABl, is a statement-label constant. Its attributes agree with those of the fourth parameter. But since i t is a constant, a dummy argument is created for it. When SUBR is invoked, the dummy argument is passed.

In SUBR, four parameters are explicitly declared in the PROCEDURE statement. If no further explicit declarations were given for these parameters, arithmetic default attributes would be supp~ied for each.

Therefore, since NAME must represent an entry name, i t is explicitly declared with the ENTRY attribute, and since TRANPT must represent a statement label, i t is

explicitly declared with the LABEL

attribute. X and J are arithmetic, so the defaults are allowed to apply.

Note that the appearance of NAME in the CALL statement does not constitute a

contextual declaration of NAME as a built-in procedure. Such a contextual

declaration is made if no explicit declaration applies. However the appearance of NAME in the PROCEDURE

statement of SUBR constitutes an explicit declaration of NAME as a parameter. If the attributes of a parameter are not

explicitly declared in a complementary DECLARE statement, arithmetic defaults apply. Consequently, NAME must be explicitly declared to have the ENTRY

attribute: otherwise, i t would be assumed tQ be a binary fixed-point variable, and its use in the CALL statement would result in an error.

ALLOCATION OF PARAMETERS

Since a parameter has no associated storage within the invoked procedure. i t cannot be declared to have any of the storage class attributes STATIC, AUTOMATIC, or BASED. It can, however, be declared to have the

CONTROLLED attribute. ThUS, there are two classes of parameters, as far as storage allocation is concerned: those that have no storage class, i.e., simple parameters, and those that have the CONTROLLED

attribute, i.e., controlled parameters.

A simple parameter may be associated with an argument of any storage class.

However, if more than one generation of the argument exists, the parameter is

associated only with that generation existing at the time of invocation.

A controlled parameter must always have a corresponding controlled argument. Such an argument cannot be subscripted, cannot be an element of a structure, and cannot cause a dummy to be created. If more than one generation of the argument exists at the time of invocation, the parameter corresponds to the entire stack of these generations. Thus, at the time of

invocation, a controlled parameter

represents the current generation of the corresponding argument. A controlled

parameter may be allocated and freed in the invoked procedure, thus allowing the

manipulation of the allocation stack of the associated argument. A simple parameter cannot be specified in an ALLOCATE or FREE statement.

When no parameter descriptor is given, the entire stack is passed. In this case, the parameter may be Simple or controlled and be correspondingly associated with either the latest generation or the entire stack.

Parameter Attributes

IParameters cannot be declared with the lattributes DEFINED or BASED. A parameter lalways has the attribute INTERNAL. It must

lbe

a level-one identifier.

I

I Variables that are used in record-loriented input/output, or as the base for IDEFINED items, must be in connected

I storage. If such a variable is a parameter land an aggregate, i t should have the

ICONNECTED attribute, both in its

Ideclaration in the subroutine, and, where applicable, in the descriptor list of the subroutine entry declaration.

In the subroutine, the CONNECTED attribute specifies that the parameter represents connected storage. In the entry declaration, i t specifies that, if the argument is in non-connected storage, a dummy argument in connected storage is to be created.

Note that elements, arrays, and major structures are always allocated in

connected storage. References to non-connected storage arise only when the programmer refers to an aggregate that is Imade up of non-contiguous items from a Ilarger aggregate. For example, in the I structure:

I I I I I

1 A(10), 2 B, 2 C;

Ithe interleaved arrays A.B and A.C are both lin non-connected storage.

I I For array cross-sections, the rule is as I follows: i f a non-asterisk bound appears Ito the right of the left-most asterisk I bound, the array cross-section is in non-Iconnected storage. Thus A(4,*,*) is in Iconnected storage; A(*,2,.) is not. iSUB-Idefined variables are always regarded as Ibeing in non-connected storage.

Parameter Bounds, Lengths, and Sizes

If an argument is an array, a string, or an area, the bounds of the array, the length of the string, or the size of the area must be declared for the corresponding

parameter. The number of dimensions and the bounds of an array parameter, or the length and size of an area or string parameter, must be the same as the current generation of the corresponding argument.

Usually, this can be assured simply by specifying actual numbers for the bounds, length, or size of the parameter.

If the bounds, length, or size are not known at the time the subroutine or

function is written, they may be specified by asterisks, for simple parameters, or asterisks or expressions for controlled parameters.

Chapter 9: Subroutines and Functions 117

Simple Parameter Bounds, Lengths, and

Dans le document OS PL/I (Page 128-131)