Enables relaxed or strict checking of call prototypes for COMP, BINARY, COMP-4, COMP-5 and COMP-X data items when used in
the BY VALUE or RETURNING clauses of a CALL statement. It also inhibits or enables the implicit copying of parameter types
from the prototype.
Syntax:
>>----.---.-----PROTOTYPE----"level"---------------------><
+-/-+
Parameters:
-
level
- One of:
- RELAXED
- Data items and parameter attributes are loosely checked against the prototype
- NORMAL
- Data items are strictly checked against the protoype, while parameter attributes are loosely checked
- STRICT
- Data items and parameter attributes are strictly checked against the proto
Properties:
Default:
|
PROTOTYPE"RELAXED
|
Phase:
|
Syntax check
|
$SET:
|
Any
|
Comments:
The PROTOTYPE directive gives you control over how calls to call prototypes are handled.
PROTOTYPE"RELAXED" can be particularly useful when you compile programs written on 32-bit systems that use call prototypes written on 64-bit systems.
By default, BY VALUE binary data-items are loosely type-checked (that is PROTOTYPE"RELAXED" is set). For example, a CALL statement can provide a PIC X(2) COMP data-item in its USING list, and that item can correspond to a PIC X(n) COMP data-item in a call prototype, where n can be from 1 to 4 on a 32-bit system, and 1 to 8 on a 64-bit system. If the value passed was larger than that specified for the receiving data item, truncation occurs. If you want to avoid truncation due to this loose type-checking, set PROTOTYPE"NORMAL"or PROTOTYPE"STRICT" when compiling your program.
If you set PROTOYPE"NORMAL" or PROTOTYPE"RELAXED", the attributes for the parameters of a call are copied from the prototype. If you set PROTOYPE"STRICT", this does not happen. For example, suppose you have the program:
If you set PROTOYPE"NORMAL", the call to my_api is converted by the Compiler to:
If you set PROTOTYPE"STRICT", the call to my_api is treated as if the parameters followed the normal rules. The call is therefore is converted to:
and the Compiler issues appropriate error messages. Similarly, if the call convention does not match that specified in the prototype, or is not specified to the CALL statement, error messages are issued.