only blank characters. When m and w are both zero, and the internal value consists of all zero bits, one blank
character is produced.
13.7.3 Logical editing
be of type logical. The G edit descriptor also may be used to edit logical data (<IP_ADDRESS>).2 The standard form of the input field consists of optional blanks, optionally followed by a period, followed by a T
for true or F for false. The T or F may be followed by additional characters in the field, which are ignored. If the3 A lower-case letter is equivalent to the corresponding upper-case letter in a logical input field.input field does not have the standard form, and is not acceptable to the processor, an error condition occurs.
NOTE 13.174 The output field consists of w−1 blanks followed by a T or F, depending on whether the internal value is true orThe logical constants .TRUE. and .FALSE. are acceptable input forms.
false, respectively.1 The A[w] edit descriptor is used with an input/output list item of type character. The G edit descriptor also may13.7.4 Character editing
be used to edit character data (<IP_ADDRESS>). The kind type parameter of all characters transferred and converted2 If a field width w is specified with the A edit descriptor, the field consists of w characters. If a field width w isunder control of one A or G edit descriptor is implied by the kind of the corresponding list item.
not specified with the A edit descriptor, the number of characters in the field is the length of the corresponding3 Let len be the length of the input/output list item. If the specified field width w for an A edit descriptorlist item, regardless of the value of the kind type parameter.
corresponding to an input item is greater than or equal to len, the rightmost len characters will be taken from the4 If the specified field width w for an A edit descriptor corresponding to an output item is greater than len, theinput field. If the specified field width w is less than len, the w characters will appear left justified with len−w
trailing blanks in the internal value.
output field will consist of w−len blanks followed by the len characters from the internal value. If the specified5 If the file is connected for stream access, the output may be split across more than one record if it containsfield width w is less than or equal to len, the output field will consist of the leftmost w characters from the internal
value.
NOTE 13.18
For nondefault character kinds, the blank padding character is processor dependent.
newline characters. A newline character is a nonblank character returned by the intrinsic function NEW_LINE.1 The Gw, Gw.d and Gw.d Ee edit descriptors are used with an input/output list item of any intrinsic type. WhenBeginning with the first character of the output field, each character that is not a newline is written to the current
record in successive positions; each newline character causes file positioning at that point as if by slash editing
278 ⃝ c ISO/IEC 2017 – All rights reserved
ISO/IEC DIS 1539-1:2017 (E)
(the current record is terminated at that point, a new empty record is created following the current record, this
new record becomes the last and current record of the file, and the file is positioned at the beginning of this new
record).
NOTE 13.19
If the intrinsic function NEW_LINE returns a blank character for a particular character kind, then the
processor does not support using a character of that kind to cause record termination in a formatted stream
file.
13.7.5 Generalized editing
<IP_ADDRESS> Overview
w is nonzero, these edit descriptors indicate that the external field occupies w positions. For real or complex1 When used to specify the input/output of integer, real, and complex data, the Gw, Gw.d and Gw.d Ee editdata the fractional part consists of a maximum of d digits and the exponent part consists of e digits. When these
edit descriptors are used to specify the input/output of integer, logical, or character data, d and e have no effect.
When w is zero the processor selects the field width. On input, w shall not be zero.
<IP_ADDRESS> Generalized numeric editing
descriptors follow the general rules for numeric editing (13.7.2).1 When used to specify the input/output of integer data, the Gw, Gw.d, and Gw.d Ee edit descriptors follow theNOTE 13.20
The Gw.d Ee edit descriptor follows any additional rules for the Ew.d Ee edit descriptor.
<IP_ADDRESS>.1 Generalized integer editing
rules for the Iw edit descriptor (<IP_ADDRESS>). Note that w cannot be zero for input editing (<IP_ADDRESS>).1 The form and interpretation of the input field for Gw.d and Gw.d Ee editing is the same as for Fw.d editing<IP_ADDRESS>.2 Generalized real and complex editing
(<IP_ADDRESS>.2). The rest of this subclause applies only to output editing.2 If w is nonzero and d is zero, kPEw.0 or kPEw.0Ee editing is used for Gw.0 editing or Gw.0Ee editing respectively.
3 When used to specify the output of real or complex data that is not an IEEE infinity or NaN, the G0 and G0.d
edit descriptors follow the rules for the Gw.dEe edit descriptor, except that any leading or trailing blanks are4 For an internal value that is an IEEE infinity or NaN, the form of the output field for the Gw.d and Gw.d Eeremoved. Reasonable processor-dependent values of w, d (if not specified), and e are used with each output value.
edit descriptors is the same as for Fw.d, and the form of the output field for the G0 and G0.d edit descriptors is5 Otherwise, the method of representation in the output field depends on the magnitude of the internal valuethe same as for F0.0.
being edited. If the internal value is zero, let s be one. If the internal value is a number other than zero, let N6 The value of w−n shall be positive.be the decimal value that is the result of converting the internal value to d significant digits according to the
input/output rounding mode and let s be the integer such that 10s−1 ≤ |N | < 10s . If s < 0 or s > d, kPEw.d or
kPEw.dEe editing is used for Gw.d editing or Gw.dEe editing respectively, where k is the scale factor (13.8.5).
If 0 ≤ s ≤ d, the scale factor has no effect and F(w − n).(d − s),n(’b’) editing is used where b is a blank and n is
4 for Gw.d editing, e + 2 for Gw.dEe editing if e > 0, and 4 for Gw.dE0 editing.
⃝c ISO/IEC 2017 – All rights reserved 2791 When used to specify the input/output of logical data, the Gw.d and Gw.d Ee edit descriptors with nonzero w
ISO/IEC DIS 1539-1:2017 (E)
NOTE 13.21
The scale factor has no effect on output unless the magnitude of the datum to be edited is outside the range
that permits effective use of F editing.
<IP_ADDRESS> Generalized logical editing
follow the rules for the Lw edit descriptor (13.7.3). When used to specify the output of logical data, the G0 and1 When used to specify the input/output of character data, the Gw.d and Gw.d Ee edit descriptors with nonzeroG0.d edit descriptors follow the rules for the L1 edit descriptor.
<IP_ADDRESS> Generalized character editing
w follow the rules for the Aw edit descriptor (13.7.4). When used to specify the output of character data, the G01 The DT edit descriptor specifies that a user-provided procedure shall be used instead of the processor’s defaultand G0.d edit descriptors follow the rules for the A edit descriptor with no field width.
13.7.6 User-defined derived-type editing
input/output formatting for processing a list item of derived type.2 The DT edit descriptor may include a character literal constant. The character value “DT” concatenated with the
character literal constant is passed to the defined input/output procedure as the iotype argument (<IP_ADDRESS>). The3 If a derived-type variable or value corresponds to a DT edit descriptor, there shall be an accessible interface tov values of the edit descriptor are passed to the defined input/output procedure as the v_list array argument.
NOTE 13.22
For the edit descriptor DT’Link List’(10, 4, 2), iotype is "DTLink List" and v_list is [10, 4, 2].
a corresponding defined input/output procedure for that derived type (<IP_ADDRESS>). A DT edit descriptor shall not1 The position edit descriptors T, TL, TR, and X, specify the position at which the next character will be transmit-correspond to a list item that is not of a derived type.
13.8 Control edit descriptors
13.8.1 Position edit descriptors
<IP_ADDRESS> Position editing
ted to or from the record. If any character skipped by a position edit descriptor is of type nondefault character,2 On input, if the position specified by a position edit descriptor is before the current position, portions of a recordand the unit is a default character internal file or an external non-Unicode file, the result of that position editing
is processor dependent.
can be processed more than once, possibly with different editing.3 On input, a position beyond the last character of the record may be specified if no characters are transmitted
from such positions.4 On output, a position edit descriptor does not by itself cause characters to be transmitted and therefore does not
by itself affect the length of the record. If characters are transmitted to positions at or after the position specified5 On output, a character in the record can be replaced. A position edit descriptor never directly causes a characterby a position edit descriptor, positions skipped and not previously filled are filled with blanks. The result is as if
the entire record were initially filled with blanks.
280 ⃝1 The left tab limit affects file positioning by the T and TL edit descriptors. Immediately prior to nonchild datac ISO/IEC 2017 – All rights reserved
ISO/IEC DIS 1539-1:2017 (E)
already placed in the record to be replaced, but it might result in positioning such that subsequent editing causes
a replacement.
<IP_ADDRESS> T, TL, and TR editing
transfer (<IP_ADDRESS>.3), the left tab limit becomes defined as the character position of the current record or the2 The Tn edit descriptor indicates that the transmission of the next character to or from a record is to occur atcurrent position of the stream file. If, during data transfer, the file is positioned to another record, the left tab
limit becomes defined as character position one of that record.
the nth character position of the record, relative to the left tab limit. This position can be in either direction3 The TLn edit descriptor indicates that the transmission of the next character to or from the record is to occur atfrom the current position.
the character position n characters backward from the current position. However, if n is greater than the difference4 The TRn edit descriptor indicates that the transmission of the next character to or from the record is to occurbetween the current position and the left tab limit, the TLn edit descriptor indicates that the transmission of
the next character to or from the record is to occur at the left tab limit.
at the character position n characters forward from the current position.1 The nX edit descriptor indicates that the transmission of the next character to or from a record is to occur at<IP_ADDRESS> X editing
the character position n characters forward from the current position.1 The slash edit descriptor indicates the end of data transfer to or from the current record.NOTE 13.23
An nX edit descriptor has the same effect as a TRn edit descriptor.
13.8.2 Slash editing
2 On input from a file connected for sequential or stream access, the remaining portion of the current record is
skipped and the file is positioned at the beginning of the next record. This record becomes the current record.3 For a file connected for direct access, the record number is increased by one and the file is positioned at theOn output to a file connected for sequential or stream access, a new empty record is created following the current
record; this new record then becomes the last and current record of the file and the file is positioned at the
beginning of this new record.
beginning of the record that has that record number, if there is such a record, and this record becomes the4 The repeat specification is optional in the slash edit descriptor. If it is not specified, the default value is one.current record.
NOTE 13.24
A record that contains no characters can be written on output. If the file is an internal file or a file connected
for direct access, the record is filled with blank characters.
An entire record can be skipped on input.
13.8.3 Colon editing1 The colon edit descriptor terminates format control if there are no more effective items in the input/output list
(12.6.3). The colon edit descriptor has no effect if there are more effective items in the input/output list.1 The SS, SP, and S edit descriptors temporarily change (12.5.2) the sign mode (<IP_ADDRESS>, <IP_ADDRESS>) for the⃝c ISO/IEC 2017 – All rights reserved 281
ISO/IEC DIS 1539-1:2017 (E)
13.8.4 SS, SP, and S editing
connection. The edit descriptors SS, SP, and S set the sign mode corresponding to the SIGN= specifier values2 The sign mode controls optional plus characters in numeric output fields. When the sign mode is PLUS, theSUPPRESS, PLUS, and PROCESSOR_DEFINED, respectively.
processor shall produce a plus sign in any position that normally contains an optional plus sign. When the3 The SS, SP, and S edit descriptors affect only I, F, E, EN, ES, D, and G editing during the execution of an outputsign mode is SUPPRESS, the processor shall not produce a plus sign in such positions. When the sign mode is
PROCESSOR_DEFINED, the processor has the option of producing a plus sign or not in such positions, subject
to 13.7.2(5).
statement. The SS, SP, and S edit descriptors have no effect during the execution of an input statement.1 The kP edit descriptor temporarily changes (12.5.2) the scale factor for the connection to k. The scale factor13.8.5 P editing
affects the editing done by the F, E, EN, ES, EX, D, and G edit descriptors for real and complex quantities.2 The scale factor k affects the appropriate editing in the following manner.
• On input, with F, E, EN, ES, EX, D, and G editing (provided that no exponent exists in the field), theeffect is that the externally represented number equals the internally represented number multiplied by 10k ;
the scale factor is applied to the external decimal value and then this is converted using the input/output
rounding mode.
• On input, with F, E, EN, ES, EX, D, and G editing, the scale factor has no effect if there is an exponent
in the field.
• On output, with F output editing, the effect is that the externally represented number equals the internally
represented number multiplied by 10k ; the internal value is converted using the input/output rounding
mode and then the scale factor is applied to the converted decimal value.
• On output, with E and D editing, the effect is that the significand (R715) part of the quantity to be
produced is multiplied by 10k and the exponent is reduced by k.
• On output, with G editing, the effect is suspended unless the magnitude of the datum to be edited is outside
the range that permits the use of F editing. If the use of E editing is required, the scale factor has the same
effect as with E output editing.
• On output, with EN, ES, and EX editing, the scale factor has no effect.
13.8.6 BN and BZ editing 1 The BN and BZ edit descriptors temporarily change (12.5.2) the blank interpretation mode (<IP_ADDRESS>, <IP_ADDRESS>)
for the connection. The edit descriptors BN and BZ set the blank interpretation mode corresponding to the2 The blank interpretation mode controls the interpretation of nonleading blanks in numeric input fields. SuchBLANK= specifier values NULL and ZERO, respectively.
blank characters are interpreted as zeros when the blank interpretation mode has the value ZERO; they are3 The blank interpretation mode affects only numeric editing (13.7.2) and generalized numeric editing (<IP_ADDRESS>)ignored when the blank interpretation mode has the value NULL. The effect of ignoring blanks is to treat the
input field as if blanks had been removed, the remaining portion of the field right justified, and the blanks replaced
as leading blanks. However, a field containing only blanks has the value zero.
on input. It has no effect on output.1 The round edit descriptors temporarily change (12.5.2) the connection’s input/output rounding mode (<IP_ADDRESS>,13.8.7 RU, RD, RZ, RN, RC, and RP editing
<IP_ADDRESS>, <IP_ADDRESS>.8). The round edit descriptors RU, RD, RZ, RN, RC, and RP set the input/output rounding1 The decimal edit descriptors temporarily change (12.5.2) the decimal edit mode (<IP_ADDRESS>, <IP_ADDRESS>, 13.6) for282 ⃝c ISO/IEC 2017 – All rights reserved
ISO/IEC DIS 1539-1:2017 (E)
mode corresponding to the ROUND= specifier values UP, DOWN, ZERO, NEAREST, COMPATIBLE, and
PROCESSOR_DEFINED, respectively. The input/output rounding mode affects the conversion of real and
complex values in formatted input/output. It affects only D, E, EN, ES, F, and G editing.
13.8.8 DC and DP editing
the connection. The edit descriptors DC and DP set the decimal edit mode corresponding to the DECIMAL=2 The decimal edit mode controls the representation of the decimal symbol (13.6) during conversion of real andspecifier values COMMA and POINT, respectively.
complex values in formatted input/output. The decimal edit mode affects only D, E, EN, ES, F, and G editing.1 A character string edit descriptor shall not be used on input.13.9 Character string edit descriptors
2 The character string edit descriptor causes characters to be written from the enclosed characters of the edit
descriptor itself, including blanks. For a character string edit descriptor, the width of the field is the number of1 List-directed input/output allows data editing according to the type of the list item instead of by a formatcharacters between the delimiting characters. Within the field, two consecutive delimiting characters are counted
as a single character.
NOTE 13.25
A delimiter for a character string edit descriptor is either an apostrophe or quote.
13.10 List-directed formatting
13.10.1 Purpose of list-directed formatting
specification. It also allows data to be free-field, that is, separated by commas (or semicolons) or blanks.1 The characters in one or more list-directed records constitute a sequence of values and value separators. The end13.10.2 Values and value separators
of a record has the same effect as a blank character, unless it is within a character constant. Any sequence of two2 Each value is either a null value, c, r*c, or r*, where c is a literal constant, optionally signed if integer or real,or more consecutive blanks is treated as a single blank, unless it is within a character constant.
or an undelimited character constant and r is an unsigned, nonzero, integer literal constant. Neither c nor r3 A value separator isshall have kind type parameters specified. The constant c is interpreted as though it had the same kind type
parameter as the corresponding list item. The r*c form is equivalent to r successive appearances of the constant
c, and the r* form is equivalent to r successive appearances of the null value. Neither of these forms may contain
embedded blanks, except where permitted within the constant c.
• a comma optionally preceded by one or more contiguous blanks and optionally followed by one or morecontiguous blanks, unless the decimal edit mode is COMMA, in which case a semicolon is used in place of
the comma,
• a slash optionally preceded by one or more contiguous blanks and optionally followed by one or more
contiguous blanks, or
• one or more contiguous blanks between two nonblank values or following the last nonblank value, where a
nonblank value is a constant, an r*c form, or an r* form.
⃝c ISO/IEC 2017 – All rights reserved 283
ISO/IEC DIS 1539-1:2017 (E)
NOTE 13.26Although a slash encountered in an input record is referred to as a separator, it actually causes termination
of list-directed and namelist input statements; it does not actually separate two values.
NOTE 13.27
If no list items are specified in a list-directed input/output statement, one input record is skipped or one
empty output record is written.
13.10.3 List-directed input <IP_ADDRESS> List-directed input forms 1 Input forms acceptable to edit descriptors for a given type are acceptable for list-directed formatting, except as noted below. If the form of the input value is not acceptable to the processor for the type of the next effective2 For the r*c form of an input value, the constant c is interpreted as an undelimited character constant if the firstitem in the list, an error condition occurs. Blanks are never used as zeros, and embedded blanks are not permitted
in constants, except within character constants and complex constants as specified below.
list item corresponding to this value is default, ASCII, or ISO 10646 character, there is a nonblank character3 When the next effective item is of type integer, the value in the input record is interpreted as if an Iw editimmediately after r*, and that character is not an apostrophe or a quotation mark; otherwise, c is interpreted as
a literal constant.
NOTE 13.28
The end of a record has the effect of a blank, except when it appears within a character constant.
descriptor with a suitable value of w were used.4 When the next effective item is of type real, the input form is that of a numeric input field. A numeric input field
is a field suitable for F editing (<IP_ADDRESS>.2) that is assumed to have no fractional digits unless a decimal symbol5 When the next effective item is of type complex, the input form consists of a left parenthesis followed by anappears within the field.
ordered pair of numeric input fields separated by a comma (if the decimal edit mode is POINT) or semicolon6 When the next effective item is of type logical, the input form shall not include value separators among the(if the decimal edit mode is COMMA), and followed by a right parenthesis. The first numeric input field is the
real part of the complex constant and the second is the imaginary part. Each of the numeric input fields may be
preceded or followed by any number of blanks and ends of records. The end of a record may occur after the real
part or before the imaginary part.
optional characters permitted for L editing.7 When the next effective item is of type character, the input form consists of a possibly delimited sequence of zero
or more rep-chars whose kind type parameter is implied by the kind of the effective item. Character sequences8 If the next effective item is default, ASCII, or ISO 10646 character andmay be continued from the end of one record to the beginning of the next record, but the end of record shall
not occur between a doubled apostrophe in an apostrophe-delimited character sequence, nor between a doubled
quote in a quote-delimited character sequence. The end of the record does not cause a blank or any other
character to become part of the character sequence. The character sequence may be continued on as many
records as needed. The characters blank, comma, semicolon, and slash may appear in default, ASCII, or ISO
10646 character sequences.
• the character sequence does not contain value separators,• the character sequence does not cross a record boundary,
• the first nonblank character is not a quotation mark or an apostrophe,
284 ⃝c ISO/IEC 2017 – All rights reserved
ISO/IEC DIS 1539-1:2017 (E)• the leading characters are not digits followed by an asterisk, and
• the character sequence contains at least one character,
the delimiting apostrophes or quotation marks are not required. If the delimiters are omitted, the character sequence is terminated by the first blank, comma (if the decimal edit mode is POINT), semicolon (if the decimal
edit mode is COMMA), slash, or end of record; in this case apostrophes and quotation marks within the datum
are not to be doubled.
9 Let len be the current length of the next effective item, and let w be the length of the character sequence. If len is less than or equal to w, the leftmost len characters of the sequence are transmitted to the next effective item.1 A null value is specified byIf len is greater than w, the sequence is transmitted to the leftmost w characters of the next effective item and
the remaining len−w characters of the next effective item are filled with blanks.
NOTE 13.29
An allocatable, deferred-length character effective item does not have its allocation status or allocated
length changed as a result of list-directed input.
<IP_ADDRESS> Null values
• the r* form,2 A null value has no effect on the definition status of the next effective item. A null value shall not be used for• no characters between consecutive value separators, or
• no characters before the first value separator in the first record read by each execution of a list-directed
input statement.
NOTE 13.30
The end of a record following any other value separator, with or without separating blanks, does not specify
a null value in list-directed input.
either the real or imaginary part of a complex constant, but a single null value may represent an entire complex3 A slash encountered as a value separator during execution of a list-directed input statement causes terminationconstant.
of execution of that input statement after the transference of the previous value. Any characters remaining in the1 The form of the values produced is the same as that required for input, except as noted otherwise. With thecurrent record are ignored. If there are additional items in the input list, the effect is as if null values had been
supplied for them. Any do-variable in the input list becomes defined as if enough null values had been supplied
for any remaining input list items.
NOTE 13.31
All blanks encountered during list-directed input are considered to be part of some value separator except
for
• blanks embedded in a character sequence,
• embedded blanks surrounding the real or imaginary part of a complex constant, and
• leading blanks in the first record read by each execution of a list-directed input statement, unless
immediately followed by a slash or comma.
NOTE 13.32
List-directed input example:
INTEGER I; REAL X (8); CHARACTER (11) P; COMPLEX Z; LOGICAL G
...
READ *, I, X, P, Z, G
⃝c ISO/IEC 2017 – All rights reserved 285
ISO/IEC DIS 1539-1:2017 (E)
NOTE 13.32 (cont.)
The input data records are:
12345,12345,,2*1.5,4*
ISN’T_BOB’S,(123,0),.TEXAS$
The results are:
Variable Value
I 12345
X (1) 12345.0
X (2) unchanged
X (3) 1.5
X (4) 1.5
X (5) – X (8) unchanged
P ISN’T_BOB’S
Z (123.0,0.0)
G true
13.10.4 List-directed output
exception of adjacent undelimited character sequences, the values are separated by one or more blanks or by a2 The processor may begin new records as necessary, but the end of record shall not occur within a constant exceptcomma, or a semicolon if the decimal edit mode is COMMA, optionally preceded by one or more blanks and
optionally followed by one or more blanks. Two undelimited character sequences are considered adjacent when
both were written using list-directed input/output, no intervening data transfer or file positioning operations on
that unit occurred, and both were written either by a single data transfer statement, or during the execution of
a parent data transfer statement along with its child data transfer statements. The form of the values produced
by defined output (<IP_ADDRESS>) is determined by the defined output procedure; this form need not be compatible
with list-directed input.
as specified for complex constants and character sequences. The processor shall not insert blanks within character3 Logical output values are T for the value true and F for the value false.sequences or within constants, except as specified for complex constants.
4 Integer output constants are produced with the effect of an Iw edit descriptor.
5 Real constants are produced with the effect of either an F edit descriptor or an E edit descriptor, depending on
the magnitude x of the value and a range 10d1 ≤ x < 10d2 , where d1 and d2 are processor-dependent integers. If6 For numeric output, reasonable processor-dependent values of w, d, and e are used for each of the numericthe magnitude x is within this range or is zero, the constant is produced using 0PFw.d; otherwise, 1PEw.d Ee is
used.
constants output.7 Complex constants are enclosed in parentheses with a separator between the real and imaginary parts, each
produced as defined above for real constants. The separator is a comma if the decimal edit mode is POINT; it8 Character sequences produced when the delimiter mode has a value of NONEis a semicolon if the decimal edit mode is COMMA. The end of a record may occur between the separator and
the imaginary part only if the entire constant is as long as, or longer than, an entire record. The only embedded
blanks permitted within a complex constant are between the separator and the end of a record and one blank at
the beginning of the next record.
• are not delimited by apostrophes or quotation marks,
286 ⃝c ISO/IEC 2017 – All rights reserved
ISO/IEC DIS 1539-1:2017 (E)• are not separated from each other by value separators,
• have each internal apostrophe or quotation mark represented externally by one apostrophe or quotation
mark, and• have a blank character inserted by the processor at the beginning of any record that begins with the
continuation of a character sequence from the preceding record.9 Character sequences produced when the delimiter mode has a value of QUOTE are delimited by quotes, are
preceded and followed by a value separator, and have each internal quote represented on the external medium by10 Character sequences produced when the delimiter mode has a value of APOSTROPHE are delimited by apo-two contiguous quotes.
strophes, are preceded and followed by a value separator, and have each internal apostrophe represented on the11 If two or more successive values in an output record have identical values, the processor has the option of producingexternal medium by two contiguous apostrophes.
a repeated constant of the form r*c instead of the sequence of identical values.12 Slashes, as value separators, and null values are not produced as output by list-directed formatting.
13 Except for new records created by explicit formatting within a defined output procedure or by continuation of delimited character sequences, each output record begins with a blank character.1 Namelist input/output allows data editing with name-value subsequences. This facilitates documentation of inputNOTE 13.33
The length of the output records is not specified and is processor dependent.
13.11 Namelist formatting
13.11.1 Purpose of namelist formatting
and output files and more flexibility on input.1 The characters in one or more namelist records constitute a sequence of name-value subsequences, each of which13.11.2 Name-value subsequences
consists of an object designator followed by an equals and followed by one or more values and value separators.2 Each object designator shall begin with a name from the namelist-group-object-list (8.9) and shall follow theThe equals may optionally be preceded or followed by one or more contiguous blanks. The end of a record has the
same effect as a blank character, unless it is within a character constant. Any sequence of two or more consecutive
blanks is treated as a single blank, unless it is within a character constant.
syntax of designator (R901). It shall not contain a vector subscript or an image-selector and shall not designate a3 A value separator for namelist formatting is the same as for list-directed formatting (13.10.2), or one or morezero-sized array, a zero-sized array section, or a zero-length character string. Each subscript, stride, and substring
range expression shall be an optionally signed integer literal constant with no kind type parameter specified. If
a section subscript list appears, the number of section subscripts shall be equal to the rank of the object. If
the namelist group object is of derived type, the designator in the input record may be either the name of the
variable or the designator of one of its components, indicated by qualifying the variable name with the appropriate
component name. Successive qualifications may be applied as appropriate to the shape and type of the variable
represented. Each designator may be preceded and followed by one or more optional blanks but shall not contain
embedded blanks.
contiguous blanks between a nonblank value and the following object designator or namelist comment (<IP_ADDRESS>).ISO/IEC DIS 1539-1:2017 (E)⃝c ISO/IEC 2017 – All rights reserved 287
13.11.3 Namelist input <IP_ADDRESS> Overall syntax 1 Input for a namelist input statement consists of (1) optional blanks and namelist comments,NOTE 13.34(2) the character & followed immediately by the namelist-group-name as specified in the NAMELIST
statement,
(3) one or more blanks,
(4) a sequence of zero or more name-value subsequences separated by value separators, and
(5) a slash to terminate the namelist input.
A slash encountered in a namelist input record causes the input statement to terminate. A slash cannot be
used to separate two values in a namelist input statement.
2 The order of the name-value subsequences in the input records need not match the order of the namelist-group- object-list. The input records need not specify all objects in the namelist-group-object-list. They may specify a3 A group name or object name is without regard to case.part of an object more than once.
<IP_ADDRESS> Namelist input processing1 The name-value subsequences are evaluated serially, in left-to-right order. A namelist group object designator
may appear in more than one name-value subsequence. The definition status of an object that is not a subobject2 When the designator in the input record represents an array variable or a variable of derived type, the effect isof a designator in any name-value subsequence remains unchanged.
as if the variable represented were expanded into a sequence of scalar list items, in the same way that formatted3 A slash encountered as a value separator during the execution of a namelist input statement causes terminationinput/output list items are expanded (12.6.3). The number of values following the equals shall not exceed the
number of list items in the expanded sequence, but may be less; in the latter case, the effect is as if sufficient
null values had been appended to match any remaining list items in the expanded sequence. Except as noted
elsewhere in this subclause, if an input value is not acceptable to the processor for the type of the list item in the
corresponding position in the expanded sequence, an error condition occurs.
NOTE 13.35
For example, if the designator in the input record designates an integer array of size 100, at most 100
values, each of which is either a digit string or a null value, can follow the equals; these values would then
be assigned to the elements of the array in array element order.
of execution of that input statement after transference of the previous value. If there are additional items in the4 Successive namelist records are read by namelist input until a slash is encountered; the remainder of the recordnamelist group object being transferred, the effect is as if null values had been supplied for them.
is ignored.5 A namelist comment may appear after any value separator except a slash (which terminates namelist input). A
namelist comment is also permitted to start in the first nonblank position of an input record except within a1 Each value is either a null value (<IP_ADDRESS>), c, r*c, or r*, where c is a literal constant, optionally signed if integercharacter literal constant.
<IP_ADDRESS> Namelist input values
or real, and r is an unsigned, nonzero, integer literal constant. A kind type parameter shall not be specified for c2 The datum c (13.11) is any input value acceptable to format specifications for a given type, except for a restriction288 ⃝c ISO/IEC 2017 – All rights reserved
ISO/IEC DIS 1539-1:2017 (E)
or r. The constant c is interpreted as though it had the same kind type parameter as the corresponding effective
item. The r*c form is equivalent to r successive appearances of the constant c, and the r* form is equivalent to r
successive null values. Neither of these forms may contain embedded blanks, except where permitted within the
constant c.
on the form of input values corresponding to list items of types logical, integer, and character as specified in this3 When the next effective item is of type real, the input form of the input value is that of a numeric input field. Asubclause. The form of a real or complex value is dependent on the decimal edit mode in effect (13.6). The form
of an input value shall be acceptable for the type of the namelist group object list item. The number and forms
of the input values that may follow the equals in a name-value subsequence depend on the shape and type of
the object represented by the name in the input record. When the name in the input record is that of a scalar
variable of an intrinsic type, the equals shall not be followed by more than one value. Blanks are never used
as zeros, and embedded blanks are not permitted in constants except within character constants and complex
constants as specified in this subclause.
numeric input field is a field suitable for F editing (<IP_ADDRESS>.2) that is assumed to have no fractional digits unless4 When the next effective item is of type complex, the input form of the input value consists of a left parenthesisa decimal symbol appears within the field.
followed by an ordered pair of numeric input fields separated by a comma (if the decimal edit mode is POINT) or5 When the next effective item is of type logical, the input form of the input value shall not include equals or valuea semicolon (if the decimal edit mode is COMMA), and followed by a right parenthesis. The first numeric input
field is the real part of the complex constant and the second field is the imaginary part. Each of the numeric
input fields may be preceded or followed by any number of blanks and ends of records. The end of a record may
occur between the real part and the comma or semicolon, or between the comma or semicolon and the imaginary
part.
separators among the optional characters permitted for L editing (13.7.3).6 When the next effective item is of type integer, the value in the input record is interpreted as if an Iw edit
descriptor with a suitable value of w were used.7 When the next effective item is of type character, the input form consists of a sequence of zero or more rep-chars
whose kind type parameter is implied by the kind of the corresponding list item, delimited by apostrophes or8 Let len be the length of the next effective item, and let w be the length of the character sequence. If len is lessquotes. Such a sequence may be continued from the end of one record to the beginning of the next record, but the
end of record shall not occur between a doubled apostrophe in an apostrophe-delimited sequence, nor between a
doubled quote in a quote-delimited sequence. The end of the record does not cause a blank or any other character
to become part of the sequence. The sequence may be continued on as many records as needed. The characters
blank, comma, semicolon, and slash may appear in such character sequences.
NOTE 13.36
The delimiters in the input form for a namelist input item of type character avoid the ambiguity that could
arise between undelimited character sequences and object names. The value of the DELIM= specifier, if
any, in the OPEN statement for an external file is ignored during namelist input (<IP_ADDRESS>).
than or equal to w, the leftmost len characters of the sequence are transmitted to the next effective item. If len1 A null value is specified byis greater than w, the constant is transmitted to the leftmost w characters of the next effective item and the
remaining len−w characters of the next effective item are filled with blanks. The effect is as though the sequence
were assigned to the next effective item in an intrinsic assignment statement (<IP_ADDRESS>).
<IP_ADDRESS> Null values
• the r* form,
⃝c ISO/IEC 2017 – All rights reserved 289
ISO/IEC DIS 1539-1:2017 (E)
• blanks between two consecutive nonblank value separators following an equals,2 A null value has no effect on the definition status of the corresponding input list item. If the namelist group• a value separator that is the first nonblank character following an equals, or
• two consecutive nonblank value separators.
object list item is defined, it retains its previous value; if it is undefined, it remains undefined. A null value shall1 All blanks in a namelist input record are considered to be part of some value separator except fornot be used as either the real or imaginary part of a complex constant, but a single null value may represent an
entire complex constant.
NOTE 13.37
The end of a record following a value separator, with or without intervening blanks, does not specify a null
value in namelist input.
<IP_ADDRESS> Blanks
• blanks embedded in a character constant,• embedded blanks surrounding the real or imaginary part of a complex constant,
• leading blanks following the equals unless followed immediately by a slash or comma, or a semicolon if the
decimal edit mode is COMMA, and
• blanks between a name and the following equals.
<IP_ADDRESS> Namelist comments 1 Except within a character literal constant, a “!” character after a value separator or in the first nonblank position of a namelist input record initiates a comment. The comment extends to the end of the record and may contain1 The form of the output produced by intrinsic namelist output shall be suitable for input, except for characterany graphic character in the processor-dependent character set. The comment is ignored. A slash within the
namelist comment does not terminate execution of the namelist input statement. Namelist comments are not
allowed in stream input because comments depend on record structure.
NOTE 13.38
Namelist input example:
INTEGER I; REAL X (8); CHARACTER (11) P; COMPLEX Z; LOGICAL G
NAMELIST / TODAY / G, I, P, Z, X
READ (*, NML = TODAY)
The input data records are:
&TODAY I = 12345, X(1) = 12345, X(3:4) = 2*1.5, I=6, ! This is a comment.
P = ’’ISN’T_BOB’S’’, Z = (123,0)/
The results stored are:
Variable Value
I 6
X (1) 12345.0
X (2) unchanged
X (3) 1.5
X (4) 1.5
X (5) – X (8) unchanged
P ISN’T_BOB’S
Z (123.0,0.0)
G unchanged
290 ⃝c ISO/IEC 2017 – All rights reserved
ISO/IEC DIS 1539-1:2017 (E)
13.11.4 Namelist output
<IP_ADDRESS> Form of namelist output
output. The names in the output are in upper case. With the exception of adjacent undelimited character2 Namelist output shall not include namelist comments.values, the values are separated by one or more blanks or by a comma, or a semicolon if the decimal edit mode is
COMMA, optionally preceded by one or more blanks and optionally followed by one or more blanks. The form
of the output produced by defined output (<IP_ADDRESS>) is determined by the defined output procedure; this form
need not be compatible with namelist input.
3 The processor may begin new records as necessary. However, except for complex constants and character values,
the end of a record shall not occur within a constant, character value, or name, and blanks shall not appear1 Values in namelist output records are edited as for list-directed output (13.10.4).within a constant, character value, or name.
NOTE 13.39
The length of the output records is not specified exactly and is processor dependent.
<IP_ADDRESS> Namelist output editing
NOTE 13.40Namelist output records produced with a DELIM= specifier with a value of NONE and which contain a
character sequence might not be acceptable as namelist input records.
<IP_ADDRESS> Namelist output records 1 If two or more successive values for the same namelist group item in an output record produced have identical
values, the processor has the option of producing a repeated constant of the form r*c instead of the sequence of2 The name of each namelist group object list item is placed in the output record followed by an equals and a listidentical values.
of values of the namelist group object list item.3 An ampersand character followed immediately by a namelist-group-name is placed at the start of the first output
record to indicate which particular group of data objects is being output. A slash is placed in the output record4 A null value is not produced by namelist formatting.to indicate the end of the namelist formatting.
5 Except for new records created by explicit formatting within a defined output procedure or by continuation of
delimited character sequences, each output record begins with a blank character.ISO/IEC DIS 1539-1:2017 (E)⃝c ISO/IEC 2017 – All rights reserved 291
(Blank page)
1 A Fortran main program is a program unit that does not contain a SUBROUTINE, FUNCTION, MODULE,
292 c ISO/IEC 2017 – All rights reserved14 Program units
ISO/IEC DIS 1539-1:2017 (E)
14.1 Main program
SUBMODULE, or BLOCK DATA statement as its first statement.R1401 main-program is [ program-stmt ]
[ specification-part ]
[ execution-part ]
[ internal-subprogram-part ]
end-program-stmt
R1402 program-stmt is PROGRAM program-name
R1403 end-program-stmt is END [ PROGRAM [ program-name ] ]
C1401 (R1401) The program-name may be included in the end-program-stmt only if the optional program-stmt
is used and, if included, shall be identical to the program-name specified in the program-stmt.
NOTE 14.1
The program name is global to the program (19.2). For explanatory information about uses for the program
name, see subclause C.9.1.
NOTE 14.2
An example of a main program is:
PROGRAM ANALYZE
REAL A, B, C (10,10) ! Specification part CALL FIND ! Execution part CONTAINS
SUBROUTINE FIND ! Internal subprogram ...
END SUBROUTINE FIND
END PROGRAM ANALYZE
2 The main program may be defined by means other than Fortran; in that case, the program shall not contain a
main-program program unit.3 A reference to a Fortran main-program shall not appear in any program unit in the program, including itself.
14.2 Modules1 A module contains declarations, specifications, and definitions. Public identifiers of module entities are accessible14.2.1 Module syntax and semantics
to other program units by use association as specified in 14.2.2. A module that is provided as an inherent part2 Procedures and types defined in an intrinsic module are not themselves intrinsic.of the processor is an intrinsic module. A nonintrinsic module is defined by a module program unit or a means
other than Fortran.
⃝c ISO/IEC 2017 – All rights reserved 2933 If a procedure declared in the scoping unit of a module has an implicit interface, it shall be given the EXTERNAL
ISO/IEC DIS 1539-1:2017 (E)
R1404 module is module-stmt
[ specification-part ]
[ module-subprogram-part ]
end-module-stmt
R1405 module-stmt is MODULE module-name
R1406 end-module-stmt is END [ MODULE [ module-name ] ]
R1407 module-subprogram-part is contains-stmt
[ module-subprogram ] ...
R1408 module-subprogram is function-subprogram
or subroutine-subprogram
or separate-module-subprogram
C1402 (R1404) If the module-name is specified in the end-module-stmt, it shall be identical to the module-name
specified in the module-stmt.
C1403 (R1404) A module specification-part shall not contain a stmt-function-stmt , an entry-stmt, or a format-stmt.
attribute in that scoping unit; if it is a function, its type and type parameters shall be explicitly declared in a4 If an intrinsic procedure is declared in the scoping unit of a module, it shall explicitly be given the INTRINSICtype declaration statement in that scoping unit.
attribute in that scoping unit or be used as an intrinsic procedure in that scoping unit.1 The USE statement specifies use association. A USE statement is a reference to the module it specifies. At theNOTE 14.3
The module name is global to the program (19.2).
NOTE 14.4
Although statement function definitions, ENTRY statements, and FORMAT statements cannot appear in the spe-
cification part of a module, they can appear in the specification part of a module subprogram in the module.
NOTE 14.5
For a discussion of the impact of modules on dependent compilation, see subclause C.9.2.
NOTE 14.6
For examples of the use of modules, see subclause C.9.3.
14.2.2 The USE statement and use association
time a USE statement is processed, the public portions of the specified module shall be available. A module shall2 The USE statement provides the means by which a scoping unit accesses named data objects, derived types,not reference itself, either directly or indirectly.
procedures, abstract interfaces, generic identifiers, and namelist groups in a module. The entities in the scoping3 A use-stmt without a module-nature provides access either to an intrinsic or to a nonintrinsic module. If theunit are use associated with the entities in the module. The accessed entities have the attributes specified
in the module, except that an accessed entity may have a different accessibility attribute, it may have the
ASYNCHRONOUS attribute even if the associated module entity does not, and if it is not a coarray it may have
the VOLATILE attribute even if the associated module entity does not. The entities made accessible are identified
by the names or generic identifiers used to identify them in the module. By default, the accessed entities are
identified by the same identifiers in the scoping unit containing the USE statement, but it is possible to specify
294 ⃝c ISO/IEC 2017 – All rights reserved
ISO/IEC DIS 1539-1:2017 (E)
that different identifiers are used. A use-associated variable is considered to have been previously declared; any
other use-associated entity is considered to have been previously defined.
NOTE 14.7
The accessibility of module entities can be controlled by accessibility attributes (<IP_ADDRESS>, 8.5.2), and the
ONLY option of the USE statement. Definability of module entities can be controlled by the PROTECTED
attribute (8.5.15).
R1409 use-stmt is USE [ [ , module-nature ] :: ] module-name [ , rename-list ]
or USE [ [ , module-nature ] :: ] module-name ,
ONLY : [ only-list ]
R1410 module-nature is INTRINSIC
or NON_INTRINSIC
R1411 rename is local-name => use-name
or OPERATOR (local-defined-operator) =>
OPERATOR (use-defined-operator)
R1412 only is generic-spec
or only-use-name
or rename
R1413 only-use-name is use-name
C1404 (R1409) If module-nature is INTRINSIC, module-name shall be the name of an intrinsic module.
C1405 (R1409) If module-nature is NON_INTRINSIC, module-name shall be the name of a nonintrinsic module.
C1406 (R1409) A scoping unit shall not directly reference an intrinsic module and a nonintrinsic module of the
same name.
C1407 (R1411) OPERATOR (use-defined-operator) shall not identify a type-bound generic interface.
C1408 (R1412) The generic-spec shall not identify a type-bound generic interface.
NOTE 14.8
Constraints C1407 and C1408 do not prevent accessing a generic-spec that is declared by an interface block,
even if a type-bound generic interface has the same generic-spec.
C1409 Each generic-spec, use-name, and use-defined-operator in a USE statement shall be a public identifier of
the module.
C1410 An only-use-name shall be a nongeneric name.
R1414 local-defined-operator is defined-unary-op
or defined-binary-op
R1415 use-defined-operator is defined-unary-op
or defined-binary-op
module-name is the name of both an intrinsic and a nonintrinsic module, the nonintrinsic module is accessed.4 The USE statement without the ONLY option provides access to all public entities in the specified module.
5 A USE statement with the ONLY option provides access only to those entities that appear as generic-specs,
use-names, or use-defined-operators in the only-list.6 More than one USE statement for a given module may appear in a specification part. If one of the USE statements⃝c ISO/IEC 2017 – All rights reserved 295
ISO/IEC DIS 1539-1:2017 (E)
is without an ONLY option, all public entities in the module are accessible. If all the USE statements have ONLY7 An accessible entity in the referenced module is associated with one or more accessed entities, each with its ownoptions, only those entities in one or more of the only-lists are accessible.
identifier. These identifiers are8 An ultimate entity is a module entity that is not accessed by use association. An accessed entity shall not be• the identifier of the entity in the referenced module if that identifier appears as an only-use-name or as the
defined-operator of a generic-spec in any only for that module,
• each of the local-names or local-defined-operators that the entity is given in any rename for that module,
and
• the identifier of the entity in the referenced module if that identifier does not appear as a use-name or
use-defined-operator in any rename for that module.
associated with two or more ultimate entities unless its identifier is not used, or the ultimate entities are generic9 The local identifier of an entity made accessible by a USE statement shall not appear in any other nonexecutableinterfaces. Generic interfaces are handled as described in <IP_ADDRESS>.
NOTE 14.9
There is no prohibition against a use-name or use-defined-operator appearing multiple times in one USE
statement or in multiple USE statements involving the same module. As a result, it is possible for one
use-associated entity to be accessible by more than one local identifier.
statement that would cause any attribute (8.5) of the entity to be specified in the scoping unit that contains the10 An entity in a scoping unit that is accessed by use association through more than one use path, has the ASYN-USE statement, except that it may appear in a PUBLIC or PRIVATE statement in the scoping unit of a module
and it may be given the ASYNCHRONOUS or VOLATILE attribute.
CHRONOUS or VOLATILE attribute in any of those use paths, and is not given that attribute in that scopingunit, shall have that attribute in all use paths.
NOTE 14.10
The constraints in subclauses 8.10.1, 8.10.2, and 8.9 prohibit the local-name from appearing as a common-
block-object in a COMMON statement, an equivalence-object in an EQUIVALENCE statement, or a namelist-group-name
in a NAMELIST statement, respectively. There is no prohibition against the local-name appearing as a
common-block-name or a namelist-group-object.
NOTE 14.11
For a discussion of the impact of the ONLY option and renaming on dependent compilation, see subclause
C.9.2.1.
NOTE 14.12
Examples:
USE STATS_LIB
provides access to all public entities in the module STATS_LIB.
USE MATH_LIB; USE STATS_LIB, SPROD => PROD
provides access to all public identifiers in both MATH_LIB and STATS_LIB. If MATH_LIB contains an
entity named PROD, it can be accessed by that name, while the entity PROD of STATS_LIB can be
accessed by the name SPROD.
296 c ISO/IEC 2017 – All rights reservedNOTE 14.12 (cont.)
ISO/IEC DIS 1539-1:2017 (E)
USE STATS_LIB, ONLY: YPROD; USE STATS_LIB, ONLY : PROD
provides access to YPROD and PROD in STAT_LIB.
USE STATS_LIB, ONLY : YPROD; USE STATS_LIB
provides access to all public identifiers in STAT_LIB.
14.2.3 Submodules 1 A submodule is a program unit that extends a module or another submodule. The program unit that it extends
is its host, and is specified by the parent-identifier in the submodule-stmt.2 A module or submodule is an ancestor program unit of all of its descendants, which are its submodules and their
descendants. The submodule identifier is the ordered pair whose first element is the ancestor module name and3 A submodule may provide implementations for separate module procedures (<IP_ADDRESS>), each of which is declaredwhose second element is the submodule name; the submodule name by itself is not a local or global identifier.
NOTE 14.13
A module and its submodules stand in a tree-like relationship one to another, with the module at the root.
Therefore, a submodule has exactly one ancestor module and can have one or more ancestor submodules.
(<IP_ADDRESS>) within that submodule or one of its ancestors, and declarations and definitions of other entities that1 A block data program unit is used to provide initial values for data objects in named common blocks.are accessible by host association in its descendants.
R1416 submodule is submodule-stmt
[ specification-part ]
[ module-subprogram-part ]
end-submodule-stmt
R1417 submodule-stmt is SUBMODULE ( parent-identifier ) submodule-name
R1418 parent-identifier is ancestor-module-name [ : parent-submodule-name ]
R1419 end-submodule-stmt is END [ SUBMODULE [ submodule-name ] ]
C1411 (R1416) A submodule specification-part shall not contain a format-stmt, entry-stmt, or stmt-function-stmt .
C1412 (R1418) The ancestor-module-name shall be the name of a nonintrinsic module that declares a separate
module procedure; the parent-submodule-name shall be the name of a descendant of that module.
C1413 (R1416) If a submodule-name appears in the end-submodule-stmt, it shall be identical to the one in the
submodule-stmt.
14.3 Block data program units
R1420 block-data is block-data-stmt2 If an object in a named common block is initially defined, all storage units in the common block storage sequence shall be specified[ specification-part ]
end-block-data-stmt
R1421 block-data-stmt is BLOCK DATA [ block-data-name ]
R1422 end-block-data-stmt is END [ BLOCK DATA [ block-data-name ] ]
C1414 (R1420) The block-data-name shall be included in the end-block-data-stmt only if it was provided in the block-data-stmt
and, if included, shall be identical to the block-data-name in the block-data-stmt.
⃝c ISO/IEC 2017 – All rights reserved 297
ISO/IEC DIS 1539-1:2017 (E)
C1415 (R1420) A block-data specification-part shall contain only derived-type definitions and ASYNCHRONOUS, BIND, COM-
MON, DATA, DIMENSION, EQUIVALENCE, IMPLICIT, INTRINSIC, PARAMETER, POINTER, SAVE, TARGET,
USE, VOLATILE, and type declaration statements.
C1416 (R1420) A type declaration statement in a block-data specification-part shall not contain ALLOCATABLE, EXTERNAL,
or BIND attribute specifiers.
even if they are not all initially defined. More than one named common block may have objects initially defined in a single block3 Only an object in a named common block may be initially defined in a block data program unit.data program unit.
4 The same named common block shall not be specified in more than one block data program unit in a program.
5 There shall not be more than one unnamed block data program unit in a program.
298 ⃝c ISO/IEC 2017 – All rights reserved1 The concept of a procedure was introduced in 5.2.3. This clause contains a complete description of procedures.
ISO/IEC DIS 1539-1:2017 (E)
15 Procedures
15.1 Concepts
The actions specified by a procedure are performed when the procedure is invoked by execution of a reference to2 The sequence of actions encapsulated by a procedure has access to entities in the procedure reference by way ofit.
argument association (15.5.2). A name that appears as a dummy-arg-name in the SUBROUTINE, FUNCTION,1 The definition of a procedure specifies it to be a function or a subroutine. A reference to a function either appearsor ENTRY statement in the declaration of a procedure (R1536) is a dummy argument. Dummy arguments are
also specified for intrinsic procedures and procedures in intrinsic modules in Clauses 16, 17, and 18.
15.2 Procedure classifications
15.2.1 Procedure classification by reference
explicitly as a primary within an expression, or is implied by a defined operation (10.1.6) within an expression.2 A procedure is classified as elemental if it is a procedure that may be referenced elementally (15.8).A reference to a subroutine is a CALL statement, a defined assignment statement (<IP_ADDRESS>), the appearance of
an object processed by defined input/output (<IP_ADDRESS>) in an input/output list, or finalization (7.5.6).
15.2.2 Procedure classification by means of definition1 A procedure that is provided as an inherent part of the processor is an intrinsic procedure.<IP_ADDRESS> Intrinsic procedures
<IP_ADDRESS> External, internal, and module procedures1 An external procedure is a procedure that is defined by an external subprogram or by a means other than Fortran.
2 An internal procedure is a procedure that is defined by an internal subprogram. Internal subprograms may
appear in the main program, in an external subprogram, or in a module subprogram. Internal subprograms shall3 A module procedure is a procedure that is defined by a module subprogram.not appear in other internal subprograms. Internal subprograms are the same as external subprograms except
that the name of the internal procedure is not a global identifier, an internal subprogram shall not contain an ENTRY
statement, and the internal subprogram has access to host entities by host association.
4 A subprogram defines a procedure for the SUBROUTINE or FUNCTION statement. If the subprogram has one or
more ENTRY statements, it also defines a procedure for each of them.1 A dummy argument that is specified to be a procedure or appears as the procedure designator in a procedure<IP_ADDRESS> Dummy procedures
reference is a dummy procedure. A dummy procedure with the POINTER attribute is a dummy procedure1 A procedure pointer is a procedure that has the EXTERNAL and POINTER attributes; it may be pointerpointer.
⃝c ISO/IEC 2017 – All rights reserved 299
ISO/IEC DIS 1539-1:2017 (E)
<IP_ADDRESS> Procedure pointers
associated with an external procedure, an internal procedure, an intrinsic procedure, a module procedure, or a1 A function that is defined by a single statement is a statement function (15.6.4).dummy procedure that is not a procedure pointer.
<IP_ADDRESS> Statement functions
15.3 Characteristics1 The characteristics of a procedure are the classification of the procedure as a function or subroutine, whether it15.3.1 Characteristics of procedures
is pure, whether it is elemental, whether it has the BIND attribute, the characteristics of its dummy arguments,1 Each dummy argument has the characteristic that it is a dummy data object, a dummy procedure, or an asteriskand the characteristics of its function result if it is a function.
15.3.2 Characteristics of dummy arguments
<IP_ADDRESS> General
(alternate return indicator).1 The characteristics of a dummy data object are its declared type, its type parameters, its shape (unless it is<IP_ADDRESS> Characteristics of dummy data objects
assumed-rank), its corank, its codimensions, its intent (8.5.10, 8.6.9), whether it is optional (8.5.12, 8.6.10),1 The characteristics of a dummy procedure are the explicitness of its interface (15.4.2), its characteristics as awhether it is allocatable (8.5.3), whether it has the ASYNCHRONOUS (8.5.4), CONTIGUOUS (8.5.7), VALUE
(8.5.18), or VOLATILE (8.5.19) attributes, whether it is polymorphic, and whether it is a pointer (8.5.14, 8.6.12)
or a target (8.5.17, 8.6.15). If a type parameter of an object or a bound of an array is not a constant expression,
the exact dependence on the entities in the expression is a characteristic. If a rank, shape, size, type, or type
parameter is assumed or deferred, it is a characteristic.
<IP_ADDRESS> Characteristics of dummy procedures
procedure if the interface is explicit, whether it is a pointer, and whether it is optional (8.5.12, 8.6.10).1 A dummy argument that is an asterisk has no other characteristic.<IP_ADDRESS> Characteristics of asterisk dummy arguments
15.3.3 Characteristics of function results1 The characteristics of a function result are its declared type, type parameters, rank, whether it is polymorphic,
whether it is allocatable, whether it is a pointer, whether it has the CONTIGUOUS attribute, and whether it is a1 The interface of a procedure determines the forms of reference through which it may be invoked. The procedure’sprocedure pointer. If a function result is an array that is not allocatable or a pointer, its shape is a characteristic.
If a type parameter of a function result or a bound of a function result array is not a constant expression, the
exact dependence on the entities in the expression is a characteristic. If type parameters of a function result are
deferred, which parameters are deferred is a characteristic. Whether the length of a character function result is assumed
is a characteristic.
300 ⃝c ISO/IEC 2017 – All rights reserved
ISO/IEC DIS 1539-1:2017 (E)
15.4 Procedure interface
15.4.1 Interface and abstract interface
interface consists of its name, binding label, generic identifiers, characteristics, and the names of its dummy2 An abstract interface is a set of procedure characteristics with the dummy argument names.arguments. The characteristics and binding label of a procedure are fixed, but the remainder of the interface may
differ in differing contexts, except that for a separate module procedure body (<IP_ADDRESS>), the dummy argument
names and whether it has the NON_RECURSIVE attribute shall be the same as in its corresponding module
procedure interface body (<IP_ADDRESS>).
15.4.2 Implicit and explicit interfaces1 The interface of a procedure is either explicit or implicit. It is explicit if it is<IP_ADDRESS> Interfaces and scopes
• an internal procedure, module procedure, or intrinsic procedure,Otherwise, the interface of the identifier is implicit. The interface of a statement function is always implicit.• a subroutine, or a function with a separate result name, within the scoping unit that defines it, or
• a procedure declared by a procedure declaration statement that specifies an explicit interface, or by an
interface body.
NOTE 15.1For example, the subroutine LLS of C.9.3.4 has an explicit interface.
<IP_ADDRESS> Explicit interface 1 Within the scope of a procedure identifier, the procedure shall have an explicit interface if it is not a statement
function and1 The interface for an internal, external, module, or dummy procedure is specified by a FUNCTION, SUB-(1) a reference to the procedure appears with an argument keyword (15.5.2),
(2) the procedure is used in a context that requires it to be pure (15.7),
(3) the procedure has a dummy argument that
(a) has the ALLOCATABLE, ASYNCHRONOUS, OPTIONAL, POINTER, TARGET, VALUE,
or VOLATILE attribute,
(b) is an assumed-shape array,
(c) is assumed-rank,
(d) is a coarray,
(e) is of a parameterized derived type, or
(f) is polymorphic,
(4) the procedure has a result that
(a) is an array,
(b) is a pointer or is allocatable, or
(c) has a nonassumed type parameter value that is not a constant expression,
(5) the procedure is elemental, or
(6) the procedure has the BIND attribute.
⃝c ISO/IEC 2017 – All rights reserved 301
ISO/IEC DIS 1539-1:2017 (E)
15.4.3 Specification of the procedure interface
<IP_ADDRESS> General
ROUTINE, or ENTRY statement and by specification statements for the dummy arguments and the result of1 An external or module subprogram specifies a specific interface for each procedure defined in that subprogram.a function. These statements may appear in the procedure definition, in an interface body, or both, except that
the ENTRY statement shall not appear in an interface body.
NOTE 15.2
An interface body cannot be used to describe the interface of an internal procedure, a module procedure
that is not a separate module procedure, or an intrinsic procedure because the interfaces of such procedures
are already explicit. However, the name of a procedure can appear in a PROCEDURE statement in an
interface block (<IP_ADDRESS>).
<IP_ADDRESS> Interface block
R1501 interface-block is interface-stmt
[ interface-specification ] ...
end-interface-stmt
R1502 interface-specification is interface-body
or procedure-stmt
R1503 interface-stmt is INTERFACE [ generic-spec ]
or ABSTRACT INTERFACE
R1504 end-interface-stmt is END INTERFACE [ generic-spec ]
R1505 interface-body is function-stmt
[ specification-part ]
end-function-stmt
or subroutine-stmt
[ specification-part ]
end-subroutine-stmt
R1506 procedure-stmt is [ MODULE ] PROCEDURE [ :: ] specific-procedure-list
R1507 specific-procedure is procedure-name
R1508 generic-spec is generic-name
or OPERATOR ( defined-operator )
or ASSIGNMENT ( = )
or defined-io-generic-spec
R1509 defined-io-generic-spec is READ (FORMATTED)
or READ (UNFORMATTED)
or WRITE (FORMATTED)
or WRITE (UNFORMATTED)
C1501 (R1501) An interface-block in a subprogram shall not contain an interface-body for a procedure defined
by that subprogram.
C1502 (R1501) If the end-interface-stmt includes a generic-spec, the interface-stmt shall specify the same
generic-spec, except that if one generic-spec has a defined-operator that is .LT., .LE., .GT., .GE., .EQ.,
or .NE., the other generic-spec may have a defined-operator that is the corresponding operator <, <=,
>, >=, ==, or /=.
302 ⃝c ISO/IEC 2017 – All rights reserved
ISO/IEC DIS 1539-1:2017 (E)
C1503 (R1503) If the interface-stmt is ABSTRACT INTERFACE, then the function-name in the function-stmt
or the subroutine-name in the subroutine-stmt shall not be the same as a keyword that specifies an
intrinsic type.
C1504 (R1502) A procedure-stmt is allowed only in an interface block that has a generic-spec.
C1505 (R1505) An interface-body of a pure procedure shall specify the intents of all dummy arguments except
alternate return indicators, dummy procedures, and arguments with the POINTER or VALUE attribute.
C1506 (R1505) An interface-body shall not contain a data-stmt, format-stmt, entry-stmt, or stmt-function-stmt .
C1507 (R1506) If MODULE appears in a procedure-stmt, each procedure-name in that statement shall denote a
module procedure.
C1508 (R1507) A procedure-name shall denote a nonintrinsic procedure that has an explicit interface.
C1509 (R1501) An interface-specification in a generic interface block shall not specify a procedure that was
specified previously in any accessible interface with the same generic identifier.
2 An interface block introduced by ABSTRACT INTERFACE is an abstract interface block. An interface body
in an abstract interface block specifies an abstract interface. An interface block with a generic specification is3 The name of the entity declared by an interface body is the function-name in the function-stmt or the subroutine-a generic interface block. An interface block with neither ABSTRACT nor a generic specification is a specific
interface block.
name in the subroutine-stmt that begins the interface body.4 A module procedure interface body is an interface body whose initial statement contains the keyword MODULE.
It specifies the interface for a separate module procedure (<IP_ADDRESS>). A separate module procedure is accessible5 An interface body in a generic or specific interface block specifies the EXTERNAL attribute and an explicitby use association if and only if its interface body is declared in the specification part of a module and is public.
If a corresponding (<IP_ADDRESS>) separate module procedure is not defined, the interface may be used to specify an
explicit specific interface but the procedure shall not be used in any other way.
specific interface for an external procedure, dummy procedure, or procedure pointer. If the name of the declared6 An interface body specifies all of the characteristics of the explicit specific interface or abstract interface. Theprocedure is that of a dummy argument in the subprogram containing the interface body, the procedure is a
dummy procedure. If the procedure has the POINTER attribute, it is a procedure pointer. If it is not a dummy
procedure or procedure pointer, it is an external procedure.
specification part of an interface body may specify attributes or define values for data entities that do not7 If an explicit specific interface for an external procedure is specified by an interface body or a procedure declarationdetermine characteristics of the procedure. Such specifications have no effect.
statement (<IP_ADDRESS>), the characteristics shall be consistent with those specified in the procedure definition, exceptthat the interface may specify a procedure that is not pure even if the procedure is defined to be pure. An interface
for a procedure defined by an ENTRY statement may be specified by using the entry name as the procedure name in the interface body.
If an external procedure does not exist in the program, an interface body for it may be used to specify an explicit
specific interface but the procedure shall not be used in any other way. A procedure shall not have more than
one explicit specific interface in a given scoping unit, except that if the interface is accessed by use association,
there may be more than one local name for the procedure. If a procedure is accessed by use association, each
access shall be to the same procedure declaration or definition.
NOTE 15.3
The dummy argument names in an interface body can be different from the corresponding dummy argument
names in the procedure definition because the name of a dummy argument is not a characteristic.
⃝c ISO/IEC 2017 – All rights reserved 303
ISO/IEC DIS 1539-1:2017 (E)
NOTE 15.4
An example of a specific interface block is:
INTERFACE
SUBROUTINE EXT1 (X, Y, Z)
REAL, DIMENSION (100, 100) :: X, Y, ZEND SUBROUTINE EXT1
SUBROUTINE EXT2 (X, Z)
REAL X
COMPLEX (KIND = 4) Z (2000)
END SUBROUTINE EXT2
FUNCTION EXT3 (P, Q)
LOGICAL EXT3END FUNCTION EXT3INTEGER P (1000)
LOGICAL Q (1000)
END INTERFACE
This interface block specifies explicit interfaces for the three external procedures EXT1, EXT2, and EXT3.
Invocations of these procedures can use argument keywords (15.5.2); for example:
PRINT *, EXT3 (Q = P_MASK (N+1 : N+1000), P = ACTUAL_P)
<IP_ADDRESS> GENERIC statement 1 A GENERIC statement specifies a generic identifier for one or more specific procedures, in the same way as a
generic interface block that does not contain interface bodies.2 If access-spec appears, it specifies the accessibility (8.5.2) of generic-spec.R1510 generic-stmt is GENERIC [ , access-spec ] :: generic-spec => specific-procedure-list
C1510 (R1510) A specific-procedure in a GENERIC statement shall not specify a procedure that was specified
previously in any accessible interface with the same generic identifier.
<IP_ADDRESS> Generic interfaces1 A generic interface block specifies a generic interface for each of the procedures in the interface block. The<IP_ADDRESS>.1 Generic identifiers
PROCEDURE statement lists procedure pointers, external procedures, dummy procedures, or module procedures2 The generic-spec in an interface-stmt is a generic identifier for all the procedures in the interface block. Thethat have this generic interface. A GENERIC statement specifies a generic interface for each of the procedures
named in its specific-procedure-list. A generic interface is always explicit.
generic-spec in a GENERIC statement is a generic identifier for all of the procedures named in its specific-3 A generic name is a generic identifier that refers to all of the procedure names in the generic interface. A genericprocedure-list. The rules specifying how any two procedures with the same generic identifier shall differ are given
in <IP_ADDRESS>.5. They ensure that any generic invocation applies to at most one specific procedure. If a specific
procedure in a generic interface has a function dummy argument, that argument shall have its type and type
parameters explicitly declared in the specific interface.
name may be the same as any one of the procedure names in the generic interface, or the same as any accessible4 A generic name may be the same as a derived-type name, in which case all of the procedures in the genericgeneric name.
interface shall be functions.5 An interface-stmt having a defined-io-generic-spec is an interface for a defined input/output procedure (<IP_ADDRESS>).304 ⃝c ISO/IEC 2017 – All rights reserved
ISO/IEC DIS 1539-1:2017 (E)
NOTE 15.5An example of a generic procedure interface is:
INTERFACE SWITCH
SUBROUTINE INT_SWITCH (X, Y)
INTEGER, INTENT (INOUT) :: X, Y
END SUBROUTINE INT_SWITCH
SUBROUTINE REAL_SWITCH (X, Y)
REAL, INTENT (INOUT) :: X, Y
END SUBROUTINE REAL_SWITCH
SUBROUTINE COMPLEX_SWITCH (X, Y) COMPLEX, INTENT (INOUT) :: X, Y
END SUBROUTINE COMPLEX_SWITCH
END INTERFACE SWITCH
Any of these three subroutines (INT_SWITCH, REAL_SWITCH, COMPLEX_SWITCH) can be ref-
erenced with the generic name SWITCH, as well as by its specific name. For example, a reference to
INT_SWITCH could take the form:
CALL SWITCH (MAX_VAL, LOC_VAL) ! MAX_VAL and LOC_VAL are of type INTEGER
NOTE 15.6
A type-bound-generic-stmt within a derived-type definition (7.5.5) specifies a generic identifier for a set of
type-bound procedures.
<IP_ADDRESS>.2 Defined operations 1 If OPERATOR is specified in a generic specification, all of the procedures specified in the generic interface shall
be functions that may be referenced as defined operations (10.1.6, 15.5). In the case of functions of two arguments,infix binary operator notation is implied. In the case of functions of one argument, prefix operator notation is
implied. OPERATOR shall not be specified for functions with no arguments or for functions with more than two
arguments. The dummy arguments shall be nonoptional dummy data objects and shall have the INTENT (IN)
or VALUE attribute. The function result shall not have assumed character length. If the operator is an intrinsic-operator
(R608), the number of dummy arguments shall be consistent with the intrinsic uses of that operator, and the
types, kind type parameters, or ranks of the dummy arguments shall differ from those required for the intrinsic
operation (10.1.5).
2 A defined operation is treated as a reference to the function. For a unary defined operation, the operand corresponds to the function’s dummy argument; for a binary operation, the left-hand operand corresponds to the3 A given defined operator may, as with generic names, apply to more than one function, in which case it is genericfirst dummy argument of the function and the right-hand operand corresponds to the second dummy argument.
All restrictions and constraints that apply to actual arguments in a reference to the function also apply to the
corresponding operands in the expression as if they were used as actual arguments.
in exact analogy to generic procedure names. For intrinsic operator symbols, the generic properties include theintrinsic operations they represent. Because both forms of each relational operator have the same interpretation
(<IP_ADDRESS>), extending one form (such as <=) has the effect of defining both forms (<= and .LE.).
NOTE 15.7
An example of the use of the OPERATOR generic specification is:
INTERFACE OPERATOR ( * )
FUNCTION BOOLEAN_AND (B1, B2)
LOGICAL, INTENT (IN) :: B1 (:), B2 (SIZE (B1))
⃝c ISO/IEC 2017 – All rights reserved 305
ISO/IEC DIS 1539-1:2017 (E)
NOTE 15.7 (cont.)
LOGICAL :: BOOLEAN_AND (SIZE (B1))
END FUNCTION BOOLEAN_AND
END INTERFACE OPERATOR ( * )
This allows, for example
SENSOR (1:N) * ACTION (1:N)as an alternative to the function reference
BOOLEAN_AND (SENSOR (1:N), ACTION (1:N)) ! SENSOR and ACTION are! of type LOGICAL
<IP_ADDRESS>.3 Defined assignments 1 If ASSIGNMENT ( = ) is specified in a generic specification, all the procedures in the generic interface shall
be subroutines that may be referenced as defined assignments (<IP_ADDRESS>, <IP_ADDRESS>). Defined assignment may, as2 Each of these subroutines shall have exactly two dummy arguments. The dummy arguments shall be nonoptionalwith generic names, apply to more than one subroutine, in which case it is generic in exact analogy to generic
procedure names.
dummy data objects. The first argument shall have INTENT (OUT) or INTENT (INOUT) and the secondargument shall have the INTENT (IN) or VALUE attribute. Either the second argument shall be an array whose
rank differs from that of the first argument, the declared types and kind type parameters of the arguments shall
not conform as specified in Table 10.8, or the first argument shall be of derived type. A defined assignment is
treated as a reference to the subroutine, with the left-hand side as the first argument and the right-hand side
enclosed in parentheses as the second argument. All restrictions and constraints that apply to actual arguments
in a reference to the subroutine also apply to the left-hand-side and to the right-hand-side enclosed in parentheses
as if they were used as actual arguments. The ASSIGNMENT generic specification specifies that assignment is
extended or redefined.
NOTE 15.8
An example of the use of the ASSIGNMENT generic specification is:
INTERFACE ASSIGNMENT ( = )
SUBROUTINE LOGICAL_TO_NUMERIC (N, B)
INTEGER, INTENT (OUT) :: N
LOGICAL, INTENT (IN) :: B
END SUBROUTINE LOGICAL_TO_NUMERIC
SUBROUTINE CHAR_TO_STRING (S, C)
USE STRING_MODULE ! Contains definition of type STRINGTYPE (STRING), INTENT (OUT) :: S ! A variable-length string
CHARACTER (*), INTENT (IN) :: C
END SUBROUTINE CHAR_TO_STRING
END INTERFACE ASSIGNMENT ( = )
Example assignments are:
KOUNT = SENSOR (J) ! CALL LOGICAL_TO_NUMERIC (KOUNT, (SENSOR (J)))NOTE 15.9NOTE = ’89AB’ ! CALL CHAR_TO_STRING (NOTE, (’89AB’))
A procedure which has a generic identifier of ASSIGNMENT ( = ) and whose second dummy argument
has the ALLOCATABLE or POINTER attribute cannot be directly invoked by defined assignment. This
is because the actual argument associated with that dummy argument is the right-hand side of the as-
306 ⃝c ISO/IEC 2017 – All rights reserved
ISO/IEC DIS 1539-1:2017 (E)NOTE 15.9 (cont.)
signment enclosed in parentheses, which makes the actual argument an expression that does not have the
ALLOCATABLE, POINTER, or TARGET attribute.
<IP_ADDRESS>.4 Defined input/output procedure interfaces 1 All of the procedures specified in an interface block for a defined input/output procedure shall be subroutines
that have interfaces as described in <IP_ADDRESS>.2.1 This subclause contains the rules that shall be satisfied by every pair of specific procedures that have the same<IP_ADDRESS>.5 Restrictions on generic declarations
generic identifier within the scope of the identifier. If a generic procedure is accessed from a module, the rules2 A dummy argument is type, kind, and rank compatible, or TKR compatible, with another dummy argument ifapply to all the specific versions even if some of them are inaccessible by their specific names.
NOTE 15.10
In most scoping units, the possible sources of procedures with a particular generic identifier are the accessible
generic identifiers specified by generic interface blocks or GENERIC statements and the generic bindings
other than names for the accessible objects in that scoping unit. In a type definition, they are the generic
bindings, including those from a parent type.
the first is type compatible with the second, the kind type parameters of the first have the same values as the3 Two dummy arguments are distinguishable ifcorresponding kind type parameters of the second, and both have the same rank or either is assumed-rank.
• one is a procedure and the other is a data object,C1511 Within the scope of a generic operator, if two procedures with that identifier have the same number of• they are both data objects or known to be functions, and neither is TKR compatible with the other,
• one has the ALLOCATABLE attribute and the other has the POINTER attribute and not the INTENT
(IN) attribute, or
• one is a function with nonzero rank and the other is not known to be a function.
arguments, one shall have a dummy argument that corresponds by position in the argument list to aC1512 Within the scope of the generic ASSIGNMENT (=) identifier, if two procedures have that identifier, onedummy argument of the other that is distinguishable from it.
shall have a dummy argument that corresponds by position in the argument list to a dummy argumentC1513 Within the scope of a defined-io-generic-spec, if two procedures have that generic identifier, their dtvof the other that is distinguishable from it.
arguments (<IP_ADDRESS>.2) shall be distinguishable.C1514 Within the scope of a generic name, each pair of procedures identified by that name shall both be
subroutines or both be functions, and(1) there is a non-passed-object dummy data object in one or the other of them such that
(a) the number of dummy data objects in one that are nonoptional, are not passed-object, and
with which that dummy data object is TKR compatible, possibly including that dummy
data object itself,
exceeds
(b) the number of non-passed-object dummy data objects, both optional and nonoptional, in
the other that are not distinguishable from that dummy data object,
⃝c ISO/IEC 2017 – All rights reserved 307
ISO/IEC DIS 1539-1:2017 (E)
(2) the number of nonoptional dummy procedures in one of them exceeds the number of dummy4 The effective position of a dummy argument is its position in the argument list after any passed-object dummyprocedures in the other,
(3) both have passed-object dummy arguments and the passed-object dummy arguments are distin-
guishable, or
(4) at least one of them shall have both
(a) a nonoptional non-passed-object dummy argument at an effective position such that either
the other procedure has no dummy argument at that effective position or the dummy argu-
ment at that position is distinguishable from it, and
(b) a nonoptional non-passed-object dummy argument whose name is such that either the other
procedure has no dummy argument with that name or the dummy argument with that name
is distinguishable from it,
and the dummy argument that disambiguates by position shall either be the same as or occur
earlier in the argument list than the one that disambiguates by name.
argument has been removed.5 Within the scope of a generic name that is the same as the generic name of an intrinsic procedure, the intrinsic
procedure is not accessible by its generic name if the procedures in the interface and the intrinsic procedure are1 An EXTERNAL statement specifies the EXTERNAL attribute (8.5.9) for a list of names.not all functions or not all subroutines. If a generic invocation is consistent with both a specific procedure from
an interface and an accessible intrinsic procedure, it is the specific procedure from the interface that is referenced.
NOTE 15.11
An extensive explanation of the application of these rules is in C.10.6.
<IP_ADDRESS> EXTERNAL statement
R1511 external-stmt is EXTERNAL [ :: ] external-name-list2 The appearance of the name of a block data program unit in an EXTERNAL statement confirms that the block
data program unit is a part of the program.NOTE 15.12
For explanatory information on potential portability problems with external procedures, see subclause
C.10.1.
NOTE 15.13
An example of an EXTERNAL statement is:
EXTERNAL FOCUS
<IP_ADDRESS> Procedure declaration statement 1 A procedure declaration statement declares procedure pointers, dummy procedures, and external procedures. It
specifies the EXTERNAL attribute (8.5.9) for all entities in the proc-decl-list.2 If proc-interface appears and consists of interface-name, it specifies an explicit specific interface (<IP_ADDRESS>) for theR1512 procedure-declaration-stmt is PROCEDURE ( [ proc-interface ] )
[ [ , proc-attr-spec ] ... :: ] proc-decl-list
R1513 proc-interface is interface-name
or declaration-type-spec
R1514 proc-attr-spec is access-spec
or proc-language-binding-spec
308 ⃝c ISO/IEC 2017 – All rights reserved
ISO/IEC DIS 1539-1:2017 (E)
or INTENT ( intent-spec )
or OPTIONAL
or POINTER
or PROTECTED
or SAVE
R1515 proc-decl is procedure-entity-name [ => proc-pointer-init ]
R1516 interface-name is name
R1517 proc-pointer-init is null-init
or initial-proc-target
R1518 initial-proc-target is procedure-name
C1515 (R1516) The name shall be the name of an abstract interface or of a procedure that has an explicit
interface. If name is declared by a procedure-declaration-stmt it shall be previously declared. If name
denotes an intrinsic procedure it shall be one that is listed in Table 16.2.
C1516 (R1516) The name shall not be the same as a keyword that specifies an intrinsic type.
C1517 (R1512) If a proc-interface describes an elemental procedure, each procedure-entity-name shall specify an
external procedure.
C1518 (R1515) If => appears in proc-decl, the procedure entity shall have the POINTER attribute.
C1519 (R1518) The procedure-name shall be the name of a nonelemental external or module procedure, or a
specific intrinsic function listed in Table 16.2.
C1520 (R1512) If proc-language-binding-spec with NAME= is specified, then proc-decl-list shall contain exactly
one proc-decl, which shall neither have the POINTER attribute nor be a dummy procedure.
C1521 (R1512) If proc-language-binding-spec is specified, the proc-interface shall appear, it shall be an interface-
name, and interface-name shall be declared with a proc-language-binding-spec.
declared procedure entities. The abstract interface (15.4) is that specified by the interface named by interface-3 If proc-interface appears and consists of declaration-type-spec, it specifies that the declared procedure entities arename. The interface specified by interface-name shall not depend on any characteristic of a procedure identified
by a procedure-entity-name in the proc-decl-list of the same procedure declaration statement.
functions having implicit interfaces and the specified result type. If a type is specified for an external function,4 If proc-interface does not appear, the procedure declaration statement does not specify whether the declaredits function definition (<IP_ADDRESS>) shall specify the same result type and type parameters.
procedure entities are subroutines or functions.5 If a proc-attr-spec other than a proc-language-binding-spec appears, it specifies that the declared procedure entities
have that attribute. These attributes are described in 8.5. If a proc-language-binding-spec with NAME= appears,6 If => appears in a proc-decl in a procedure-declaration-stmt it specifies the initial association status of theit specifies a binding label or its absence, as described in 18.10.2. A proc-language-binding-spec without NAME=
is allowed, but is redundant with the proc-interface required by C1521.
corresponding procedure entity, and implies the SAVE attribute, which may be confirmed by explicit specification.7 If procedure-entity-name has an explicit interface, its characteristics shall be the same as initial-proc-target exceptIf => null-init appears, the procedure entity is initially disassociated. If => initial-proc-target appears, the
procedure entity is initially associated with the target.
that initial-proc-target may be pure even if procedure-entity-name is not pure and initial-proc-target may be an elemental8 If the characteristics of procedure-entity-name or initial-proc-target are such that an explicit interface is required,intrinsic procedure.
⃝c ISO/IEC 2017 – All rights reserved 309
ISO/IEC DIS 1539-1:2017 (E)
both procedure-entity-name and initial-proc-target shall have an explicit interface.9 If procedure-entity-name has an implicit interface and is explicitly typed or referenced as a function, initial-proc-
target shall be a function. If procedure-entity-name has an implicit interface and is referenced as a subroutine,10 If initial-proc-target and procedure-entity-name are functions, their results shall have the same characteristics.initial-proc-target shall be a subroutine.
NOTE 15.14The following code illustrates procedure declaration statements. NOTE 10.47 illustrates the use of the P
and BESSEL defined by this code.
 Some external or dummy procedures with explicit interface.
PROCEDURE (REAL_FUNC) :: BESSEL, GFUN
PROCEDURE (SUB) :: PRINT_REAL
!-- Some procedure pointers with explicit interface,
!-- one initialized to NULL().
PROCEDURE (REAL_FUNC), POINTER :: P, R => NULL ()
PROCEDURE (REAL_FUNC), POINTER :: PTR_TO_GFUN
!-- A derived type with a procedure pointer component ...
TYPE STRUCT_TYPE
PROCEDURE (REAL_FUNC), POINTER, NOPASS :: COMPONENT
END TYPE STRUCT_TYPE
!-- ... and a variable of that type.
TYPE(STRUCT_TYPE) :: STRUCT
!-- An external or dummy function with implicit interface
PROCEDURE (REAL) :: PSI
<IP_ADDRESS> INTRINSIC statement 1 An INTRINSIC statement specifies the INTRINSIC attribute (8.5.11) for a list of names.
R1519 intrinsic-stmt is INTRINSIC [ :: ] intrinsic-procedure-name-list1 If the interface of a function is implicit, the type and type parameters of the function result are specified by anC1522 (R1519) Each intrinsic-procedure-name shall be the name of an intrinsic procedure.
<IP_ADDRESS> Implicit interface specification
implicit or explicit type specification of the function name. The type, type parameters, and shape of the dummyarguments of a procedure invoked from where the interface of the procedure is implicit shall be such that each
actual argument is consistent with the characteristics of the corresponding dummy argument.
310 ⃝
c ISO/IEC 2017 – All rights reserved
ISO/IEC DIS 1539-1:2017 (E)
15.5 Procedure reference 15.5.1 Syntax of a procedure reference 1 The form of a procedure reference is dependent on the interface of the procedure or procedure pointer, but is independent of the means by which the procedure is defined. The forms of procedure references are as follows.2 The data-ref in a procedure-designator shall not be an unallocated allocatable variable or a pointer that is notR1520 function-reference is procedure-designator ( [ actual-arg-spec-list ] )
C1523 (R1520) The procedure-designator shall designate a function.
C1524 (R1520) The actual-arg-spec-list shall not contain an alt-return-spec.
R1521 call-stmt is CALL procedure-designator [ ( [ actual-arg-spec-list ] ) ]
C1525 (R1521) The procedure-designator shall designate a subroutine.
R1522 procedure-designator is procedure-name
or proc-component-ref
or data-ref % binding-name
C1526 (R1522) A procedure-name shall be a generic name or the name of a procedure.
C1527 (R1522) A binding-name shall be a binding name (7.5.5) of the declared type of data-ref .
C1528 (R1522) A data-ref shall not be a polymorphic subobject of a coindexed object.
C1529 (R1522) If data-ref is an array, the referenced type-bound procedure shall have the PASS attribute.
associated.3 Resolving references to type-bound procedures is described in 15.5.6.
4 A function may also be referenced as a defined operation (10.1.6). A subroutine may also be referenced as a
defined assignment (<IP_ADDRESS>, <IP_ADDRESS>), by defined input/output (<IP_ADDRESS>), or by finalization (7.5.6).ISO/IEC DIS 1539-1:2017 (E)NOTE 15.15
When resolving type-bound procedure references, constraints on the use of coindexed objects ensure that
the coindexed object (on the remote image) has the same dynamic type as the corresponding object on the
local image. Thus a processor can resolve the type-bound procedure using the coarray variable on its own
image and pass the coindexed object as the actual argument.
R1523 actual-arg-spec is [ keyword = ] actual-arg
R1524 actual-arg is expr
or variable
or procedure-name
or proc-component-ref
or alt-return-spec
R1525 alt-return-spec is * label
C1530 (R1523) The keyword = shall not appear if the interface of the procedure is implicit.
C1531 (R1523) The keyword = shall not be omitted from an actual-arg-spec unless it has been omitted from
each preceding actual-arg-spec in the argument list.
C1532 (R1523) Each keyword shall be the name of a dummy argument in the explicit interface of the procedure.
⃝c ISO/IEC 2017 – All rights reserved 311
C1533 (R1524) A nonintrinsic elemental procedure shall not be used as an actual argument.
C1534 (R1524) A procedure-name shall be the name of an external, internal, module, or dummy procedure, a
specific intrinsic function listed in Table 16.2, or a procedure pointer.C1535 (R1524) expr shall not be a variable.
C1536 (R1525) The label shall be the statement label of a branch target statement that appears in the same inclusive scope as the
call-stmt.C1537 An actual argument that is a coindexed object shall not have a pointer ultimate component.
NOTE 15.16Examples of procedure reference using procedure pointers:
P => BESSEL
WRITE (*, *) P(2.5) !-- BESSEL(2.5)
S => PRINT_REAL
CALL S(3.14)
NOTE 15.17
An internal procedure cannot be invoked using a procedure pointer from either Fortran or C after the host
instance completes execution, because the pointer is then undefined. While the host instance is active,
however, if an internal procedure was passed as an actual argument or is the target of a procedure pointer,
it could be invoked from outside of the host subprogram.
Rb
Assume there is a procedure with the following interface that calculates a f (x) dx.
INTERFACE
FUNCTION INTEGRATE(F, A, B) RESULT(INTEGRAL) BIND(C)
USE ISO_C_BINDING
INTERFACE
FUNCTION F(X) BIND(C) !  Bounds
REAL(C_FLOAT) :: INTEGRAL
END FUNCTION INTEGRATE
END INTERFACE
This procedure can be called from Fortran or C, and could be written in either Fortran or C. The argument F
representing the mathematical function f (x) can be written as an internal procedure; this internal procedure
will have access to any host instance local variables necessary to actually calculate f (x). For example:
REAL FUNCTION MY_INTEGRATION(N, A, B) RESULT(INTEGRAL)! Integrate f(x)=x^n over [a,b]
USE ISO_C_BINDING
INTEGER, INTENT(IN) :: N
REAL, INTENT(IN) :: A, B
INTEGRAL = INTEGRATE(MY_F, REAL (A, C_FLOAT), REAL (B, C_FLOAT))
! This will call the internal function MY_F to calculate f(x).! The above interface of INTEGRATE needs to be explicit and available.
312 ⃝c ISO/IEC 2017 – All rights reserved
ISO/IEC DIS 1539-1:2017 (E)NOTE 15.17 (cont.)
CONTAINS
REAL(C_FLOAT) FUNCTION MY_F(X) BIND(C) ! Integrand
REAL(C_FLOAT), VALUE :: XMY_F = X**N ! N is taken from the host instance of MY_INTEGRATION.
END FUNCTION
END FUNCTION MY_INTEGRATION
The function INTEGRATE cannot retain a function pointer to MY_F and use it after INTEGRATE has
finished execution, because the host instance of MY_F might no longer exist, making the pointer undefined.
If such a pointer is retained, then it can only be used to invoke MY_F during the execution of the instance
of MY_INTEGRATION that called INTEGRATE.
1 In either a subroutine reference or a function reference, the actual argument list identifies the correspondence
15.5.2 Actual arguments, dummy arguments, and argument association
<IP_ADDRESS> Argument correspondence
between the actual arguments and the dummy arguments of the procedure. This correspondence may be estab-lished either by keyword or by position. If an argument keyword appears, the actual argument corresponds to
the dummy argument whose name is the same as the argument keyword (using the dummy argument names from
the interface accessible by the procedure reference). In the absence of an argument keyword, an actual argument
corresponds to the dummy argument occupying the corresponding position in the reduced dummy argument list;
that is, the first actual argument corresponds to the first dummy argument in the reduced list, the second actual
argument corresponds to the second dummy argument in the reduced list, etc. The reduced dummy argument
list is either the full dummy argument list or, if there is a passed-object dummy argument (<IP_ADDRESS>), the dummy
argument list with the passed-object dummy argument omitted. Exactly one actual argument shall correspond
to each nonoptional dummy argument. At most one actual argument shall correspond to each optional dummy
argument. Each actual argument shall correspond to a dummy argument.
NOTE 15.18
For example, the procedure defined by
SUBROUTINE SOLVE (FUNCT, SOLUTION, METHOD, STRATEGY, PRINT)
INTERFACE
FUNCTION FUNCT (X)
REAL FUNCT, X
END FUNCTION FUNCT
END INTERFACE
REAL SOLUTION
INTEGER, OPTIONAL :: METHOD, STRATEGY, PRINT
...
can be invoked with
CALL SOLVE (FUN, SOL, PRINT = 6)
provided its interface is explicit, and if the interface is specified by an interface body, the name of the last
argument is PRINT.
<IP_ADDRESS> The passed-object dummy argument and argument correspondence 1 In a reference to a type-bound procedure, or a procedure pointer component, that has a passed-object dummy
argument (<IP_ADDRESS>), the data-ref of the function-reference or call-stmt corresponds, as an actual argument, with1 Except in references to intrinsic inquiry functions, a pointer actual argument that corresponds to a nonoptionalthe passed-object dummy argument.
⃝c ISO/IEC 2017 – All rights reserved 313
ISO/IEC DIS 1539-1:2017 (E)
<IP_ADDRESS> Argument association
nonpointer dummy argument shall be pointer associated with a target.2 If a nonpointer dummy argument without the VALUE attribute corresponds to a pointer actual argument that
is pointer associated with a target,3 If a present nonpointer dummy argument without the VALUE attribute corresponds to a nonpointer actual• if the dummy argument is polymorphic, it becomes argument associated with that target;
• if the dummy argument is nonpolymorphic, it becomes argument associated with the declared type part of
that target.
argument,4 A present dummy argument with the VALUE attribute becomes argument associated with a definable anonymous• if the dummy argument is polymorphic, it becomes argument associated with that actual argument;
• if the dummy argument is nonpolymorphic, it becomes argument associated with the declared type part of
that actual argument.
data object whose initial value is the value of the actual argument.5 A present pointer dummy argument that corresponds to a pointer actual argument becomes argument associated
with that actual argument. A present pointer dummy argument that does not correspond to a pointer actual6 The entity that is argument associated with a dummy argument is called its effective argument.argument is not argument associated.
7 The ultimate argument is the effective argument if the effective argument is not a dummy argument or a subobject
of a dummy argument. If the effective argument is a dummy argument, the ultimate argument is the ultimate1 The requirements in this subclause apply to actual arguments that correspond to nonallocatable nonpointerargument of that dummy argument. If the effective argument is a subobject of a dummy argument, the ultimate
argument is the corresponding subobject of the ultimate argument of that dummy argument.
NOTE 15.19
For the sequence of subroutine calls
INTEGER :: X(100)
CALL SUBA (X)
...
SUBROUTINE SUBA(A)
INTEGER :: A(:)
CALL SUBB (A(1:5), A(5:1:-1))
...
SUBROUTINE SUBB(B, C)
INTEGER :: B(:), C(:)
the ultimate argument of B is X(1:5). The ultimate argument of C is X(5:1:-1) and this is not the same
object as the ultimate argument of B.
NOTE 15.20
Fortran argument association is usually similar to call by reference and call by value-result. If the VALUE
attribute is specified, the effect is as if the actual argument were assigned to a temporary variable, and
that variable were then argument associated with the dummy argument. Subsequent changes to the value
or definition status of the dummy argument do not affect the actual argument. The actual mechanism by
which this happens is determined by the processor.
314 ⃝
c ISO/IEC 2017 – All rights reserved
ISO/IEC DIS 1539-1:2017 (E)
<IP_ADDRESS> Ordinary dummy variables
dummy data objects.2 The dummy argument shall be type compatible with the actual argument. If the actual argument is a polymorphic
coindexed object, the dummy argument shall not be polymorphic. If the actual argument is a polymorphic3 The kind type parameter values of the actual argument shall agree with the corresponding ones of the dummyassumed-size array, the dummy argument shall be polymorphic. If the actual argument is of a derived type that
has type parameters, type-bound procedures, or final subroutines, the dummy argument shall not be assumed-
type.
argument. The length type parameter values of a present actual argument shall agree with the corresponding4 If a present scalar dummy argument is of type character with default kind or C character kind, the length len ofones of the dummy argument that are not assumed, except for the case of the character length parameter of
an actual argument of type character with default kind or C character kind (18.2.2) associated with a dummy
argument that is not assumed-shape or assumed-rank.
the dummy argument shall be less than or equal to the length of the actual argument. The dummy argument5 The values of assumed type parameters of a dummy argument are assumed from the corresponding type para-becomes associated with the leftmost len characters of the actual argument. If a present array dummy argument
is of type character with default kind or C character kind and is not assumed-shape or assumed-rank, it becomes
associated with the leftmost characters of the actual argument element sequence (<IP_ADDRESS>).
meters of its effective argument.6 If the actual argument is a coindexed object with an allocatable ultimate component, the dummy argument shall
have the INTENT (IN) or the VALUE attribute.7 Except in references to intrinsic inquiry functions, if the dummy argument is nonoptional and the actual argumentNOTE 15.21
If the actual argument is a coindexed object, a processor that uses distributed memory might create a copy
on the executing image of the actual argument, including copies of any allocated allocatable subobjects,
and associate the dummy argument with that copy. If necessary, on return from the procedure, the value
of the copy would be copied back to the actual argument.
is allocatable, the corresponding actual argument shall be allocated.8 If the dummy argument does not have the TARGET attribute, any pointers associated with the effective argument
do not become associated with the corresponding dummy argument on invocation of the procedure. If such a9 If the dummy argument has the TARGET attribute, does not have the VALUE attribute, and either the effectivedummy argument is used as an actual argument that corresponds to a dummy argument with the TARGET
attribute, whether any pointers associated with the original effective argument become associated with the dummy
argument with the TARGET attribute is processor dependent.
argument is simply contiguous or the dummy argument is scalar, assumed-rank, or assumed-shape, and does not10 If the dummy argument has the TARGET attribute and is an explicit-shape array, an assumed-shape array withhave the CONTIGUOUS attribute, and the effective argument has the TARGET attribute but is not a coindexed
object or an array section with a vector subscript then
• any pointers associated with the effective argument become associated with the corresponding dummy
argument on invocation of the procedure, and
• when execution of the procedure completes, any pointers that do not become undefined (<IP_ADDRESS>) and are
associated with the dummy argument remain associated with the effective argument.
the CONTIGUOUS attribute, an assumed-rank object with the CONTIGUOUS attribute, or an assumed-size11 If the dummy argument has the TARGET attribute and the effective argument does not have the TARGETarray, and the effective argument has the TARGET attribute but is not simply contiguous and is not an array
⃝c ISO/IEC 2017 – All rights reserved 315
ISO/IEC DIS 1539-1:2017 (E)
section with a vector subscript then
• on invocation of the procedure, whether any pointers associated with the effective argument become asso-
ciated with the corresponding dummy argument is processor dependent, and
• when execution of the procedure completes, the pointer association status of any pointer that is pointer
associated with the dummy argument is processor dependent.
attribute or is an array section with a vector subscript, any pointers associated with the dummy argument12 If the dummy argument has the TARGET attribute and the VALUE attribute, any pointers associated with thebecome undefined when execution of the procedure completes.
dummy argument become undefined when execution of the procedure completes.13 If the actual argument is a coindexed scalar, the corresponding dummy argument shall be scalar. If the actual
argument is a noncoindexed scalar, the corresponding dummy argument shall be scalar unless the actual argument14 If a dummy argument is an assumed-shape array, the rank of the actual argument shall be the same as the rankis default character, of type character with the C character kind (18.2.2), or is an element or substring of an element
of an array that is not an assumed-shape, pointer, or polymorphic array. If the procedure is nonelemental and is
referenced by a generic name or as a defined operator or defined assignment, the ranks of the actual arguments
and corresponding dummy arguments shall agree.
of the dummy argument, and the actual argument shall not be an assumed-size array.15 An actual argument of any rank may correspond to an assumed-rank dummy argument. The rank and extents of
the dummy argument are the rank and extents of the corresponding actual argument. The lower bound of each16 Except when a procedure reference is elemental (15.8), each element of an array actual argument or of a sequencedimension of the dummy argument is equal to one. The upper bound is equal to the extent, except for the last
dimension when the actual argument is assumed-size.
in a sequence association (<IP_ADDRESS>) is associated with the element of the dummy array that has the same position17 A scalar dummy argument of a nonelemental procedure shall correspond only to a scalar actual argument.in array element order (<IP_ADDRESS>).
NOTE 15.22
For default character sequence associations, the interpretation of element is provided in <IP_ADDRESS>.
18 If a dummy argument has INTENT (OUT) or INTENT (INOUT), the actual argument shall be definable. If a
dummy argument has INTENT (OUT), the effective argument becomes undefined at the time the association is19 If the procedure is nonelemental, the dummy argument does not have the VALUE attribute, and the actualestablished, except for direct components of an object of derived type for which default initialization has been
specified.
argument is an array section having a vector subscript, the dummy argument is not definable and shall not have20 If the dummy argument has a coarray ultimate component, the corresponding actual argument shall have thethe ASYNCHRONOUS, INTENT (OUT), INTENT (INOUT), or VOLATILE attributes.
VOLATILE attribute if and only if the dummy argument has the VOLATILE attribute.C1538 An actual argument that is a coindexed object with the ASYNCHRONOUS or VOLATILE attribute shallNOTE 15.23
Argument intent specifications serve several purposes. See NOTE 8.18.
NOTE 15.24
For more explanatory information on targets as dummy arguments, see subclause C.10.4.
316 ⃝
c ISO/IEC 2017 – All rights reserved
ISO/IEC DIS 1539-1:2017 (E)
not correspond to a dummy argument that has either the ASYNCHRONOUS or VOLATILE attribute,C1539 (R1524) If an actual argument is a nonpointer array that has the ASYNCHRONOUS or VOLATILEunless the dummy argument has the VALUE attribute.
attribute but is not simply contiguous (9.5.4), and the corresponding dummy argument has either theC1540 (R1524) If an actual argument is an array pointer that has the ASYNCHRONOUS or VOLATILEASYNCHRONOUS or VOLATILE attribute, but does not have the VALUE attribute, that dummy
argument shall be assumed-shape or assumed-rank and shall not have the CONTIGUOUS attribute.
attribute but does not have the CONTIGUOUS attribute, and the corresponding dummy argumentNOTE 15.25has either the ASYNCHRONOUS or VOLATILE attribute, but does not have the VALUE attribute,
that dummy argument shall be an array pointer, an assumed-shape array without the CONTIGUOUS
attribute, or an assumed-rank entity without the CONTIGUOUS attribute.
The constraints on an actual argument with the ASYNCHRONOUS or VOLATILE attribute that corres-
ponds to a dummy argument with either the ASYNCHRONOUS or VOLATILE attribute are designed to
avoid forcing a processor to use the so-called copy-in/copy-out argument passing mechanism. Making a
copy of an actual argument whose value is likely to change due to an asynchronous input/output operation
completing or in some unpredictable manner will cause the new value to be lost when a called procedure
returns and the copy-out overwrites the actual argument.
1 The requirements in this subclause apply to an actual argument with the ALLOCATABLE or POINTER attribute
<IP_ADDRESS> Allocatable and pointer dummy variables
that corresponds to a dummy argument with the same attribute.2 The actual argument shall be polymorphic if and only if the associated dummy argument is polymorphic, and
either both the actual and dummy arguments shall be unlimited polymorphic, or the declared type of the actual3 The rank of the actual argument shall be the same as that of the dummy argument, unless the dummy argumentargument shall be the same as the declared type of the dummy argument.
NOTE 15.26
The dynamic type of a polymorphic allocatable or pointer dummy argument can change as a result of
execution of an ALLOCATE statement or pointer assignment in the subprogram. Because of this the
corresponding actual argument needs to be polymorphic and have a declared type that is the same as the
declared type of the dummy argument or an extension of that type. However, type compatibility requires
that the declared type of the dummy argument be the same as, or an extension of, the type of the actual
argument. Therefore, the dummy and actual arguments need to have the same declared type.
Dynamic type information is not maintained for a nonpolymorphic allocatable or pointer dummy argument.
However, allocating or pointer-assigning such a dummy argument would require maintenance of this inform-
ation if the corresponding actual argument is polymorphic. Therefore, the corresponding actual argument
needs to be nonpolymorphic.
is assumed-rank. The type parameter values of the actual argument shall agree with the corresponding ones of4 The actual argument shall have deferred the same type parameters as the dummy argument.the dummy argument that are not assumed or deferred. The values of assumed type parameters of the dummy
argument are assumed from the corresponding type parameters of its effective argument.
<IP_ADDRESS> Allocatable dummy variables1 The requirements in this subclause apply to actual arguments that correspond to allocatable dummy data objects.
2 The actual argument shall be allocatable. It is permissible for the actual argument to have an allocation status
of unallocated.3 The corank of the actual argument shall be the same as that of the dummy argument.⃝c ISO/IEC 2017 – All rights reserved 317
ISO/IEC DIS 1539-1:2017 (E)
4 If the actual argument is a coindexed object, the dummy argument shall have the INTENT (IN) attribute.
5 If the dummy argument does not have the TARGET attribute, any pointers associated with the actual argument
do not become associated with the corresponding dummy argument on invocation of the procedure. If such a6 If the dummy argument has the TARGET attribute, does not have the INTENT (OUT) or VALUE attribute,dummy argument is used as an actual argument that is associated with a dummy argument with the TARGET
attribute, whether any pointers associated with the original actual argument become associated with the dummy
argument with the TARGET attribute is processor dependent.
and the corresponding actual argument has the TARGET attribute then7 If a dummy argument has INTENT (OUT) or INTENT (INOUT), the actual argument shall be definable. If a• any pointers associated with the actual argument become associated with the corresponding dummy argu-
ment on invocation of the procedure, and
• when execution of the procedure completes, any pointers that do not become undefined (<IP_ADDRESS>) and are
associated with the dummy argument remain associated with the actual argument.
dummy argument has INTENT (OUT) and its associated actual argument is allocated, the actual argument is1 The requirements in this subclause apply to actual arguments that correspond to dummy data pointers.deallocated on procedure invocation (<IP_ADDRESS>).
<IP_ADDRESS> Pointer dummy variables
C1541 The actual argument corresponding to a dummy pointer with the CONTIGUOUS attribute shall be2 If the dummy argument does not have INTENT (IN), the actual argument shall be a pointer. Otherwise, thesimply contiguous (9.5.4).
C1542 The actual argument corresponding to a dummy pointer shall not be a coindexed object.
NOTE 15.27
Constraint C1542 does not apply to any intrinsic procedure because an intrinsic procedure is defined in
terms of its actual arguments.
actual argument shall be a pointer or a valid target for the dummy pointer in a pointer assignment statement. If3 If the dummy argument has INTENT (OUT), the pointer association status of the actual argument becomesthe actual argument is not a pointer, the dummy pointer becomes pointer associated with the actual argument.
undefined on invocation of the procedure.1 If the dummy argument is a coarray, the corresponding actual argument shall be a coarray and shall have theNOTE 15.28
For more explanatory information on pointers as dummy arguments, see subclause C.10.4.
<IP_ADDRESS> Coarray dummy variables
VOLATILE attribute if and only if the dummy argument has the VOLATILE attribute.2 If the dummy argument is an array coarray that has the CONTIGUOUS attribute or is not of assumed shape,
the corresponding actual argument shall be simply contiguous or an element of a simply contiguous array.NOTE 15.29
Consider the invocation of a procedure on a particular image. Each dummy coarray is associated with its
ultimate argument on the image. In addition, during this execution of the procedure, this image can access
the coarray corresponding to the ultimate argument on any other image. For example, consider
318 ⃝c ISO/IEC 2017 – All rights reserved
ISO/IEC DIS 1539-1:2017 (E)
NOTE 15.29 (cont.)
INTERFACE
SUBROUTINE SUB(X)
REAL :: X[*]
END SUBROUTINE SUB
END INTERFACE
...
REAL :: A(1000)[*]
...
CALL SUB(A(10))
During execution of this invocation of SUB, the executing image has access through the syntax X[P] to
A(10) on image P.
NOTE 15.30
Each invocation of a procedure with a nonallocatable coarray dummy argument establishes a dummy coarray
for the image with its own bounds and cobounds. During this execution of the procedure, this image can
use its own bounds and cobounds to access the coarray corresponding to the ultimate argument on any
other image. For example, consider
INTERFACE
SUBROUTINE SUB(X,N)
INTEGER :: NREAL :: X(N,N)[N,*]
END SUBROUTINE SUB
END INTERFACE
...
REAL :: A(1000)[*]
...
CALL SUB(A,10)
During execution of this invocation of SUB, the executing image has access through the syntax X(1,2)[3,4]
to A(11) on the image with image index 33.
NOTE 15.31
The requirements on an actual argument that corresponds to a dummy coarray that is not of assumed-
shape or has the CONTIGUOUS attribute are designed to avoid forcing a processor to use the so-called
copy-in/copy-out argument passing mechanism.
<IP_ADDRESS> Actual arguments associated with dummy procedure entities 1 If the interface of a dummy procedure is explicit, its characteristics as a procedure (15.3.1) shall be the same as
those of its effective argument, except that a pure effective argument may be associated with a dummy argument2 If the interface of a dummy procedure is implicit and either the dummy argument is explicitly typed or referencedthat is not pure and an elemental intrinsic actual procedure may be associated with a dummy procedure (which cannot be
elemental).
as a function, it shall not be referenced as a subroutine and any corresponding actual argument shall be a function,3 If the interface of a dummy procedure is implicit and a reference to it appears as a subroutine reference, anyfunction procedure pointer, or dummy procedure. If both the actual argument and dummy argument are known
to be functions, they shall have the same type and type parameters. If only the dummy argument is known to
be a function, the function that would be invoked by a reference to the dummy argument shall have the same
type and type parameters, except that an external function with assumed character length may be associated with a dummy
argument with explicit character length.
corresponding actual argument shall be a subroutine, subroutine procedure pointer, or dummy procedure.4 If a dummy argument is a dummy procedure without the POINTER attribute, its effective argument shall be an⃝c ISO/IEC 2017 – All rights reserved 319
ISO/IEC DIS 1539-1:2017 (E)
external, internal, module, or dummy procedure, or a specific intrinsic procedure listed in Table 16.2. If the specific name5 If a dummy argument is a procedure pointer, the corresponding actual argument shall be a procedure pointer, ais also a generic name, only the specific procedure is associated with the dummy argument.
reference to a function that returns a procedure pointer, a reference to the intrinsic function NULL, or a valid6 When the actual argument is a procedure, the host instance of the dummy argument is the host instance of thetarget for the dummy pointer in a pointer assignment statement. If the actual argument is not a pointer, the
dummy argument shall have INTENT (IN) and becomes pointer associated with the actual argument.
actual argument (<IP_ADDRESS>).7 If an external procedure or a dummy procedure is used as an actual argument, its interface shall be explicit or it
shall be explicitly declared to have the EXTERNAL attribute.1 If a dummy argument is an asterisk (<IP_ADDRESS>), the corresponding actual argument shall be an alternate return specifier (R1525).<IP_ADDRESS> Actual arguments and alternate return indicators
<IP_ADDRESS> Sequence association1 An actual argument represents an element sequence if it is an array expression, an array element designator, a
default character scalar, or a scalar of type character with the C character kind (18.2.2). If the actual argument is2 If the actual argument is default character or of type character with the C character kind, and is an arrayan array expression, the element sequence consists of the elements in array element order. If the actual argument
is an array element designator, the element sequence consists of that array element and each element that follows
it in array element order.
expression, array element, or array element substring designator, the element sequence consists of the storage3 If the actual argument is default character or of type character with the C character kind, and is a scalar that isunits beginning with the first storage unit of the actual argument and continuing to the end of the array. The
storage units of an array element substring designator are viewed as array elements consisting of consecutive
groups of storage units having the character length of the dummy array.
not an array element or array element substring designator, the element sequence consists of the storage units of4 An actual argument that represents an element sequence and corresponds to a dummy argument that is an arraythe actual argument.
NOTE 15.32
Some of the elements in the element sequence might consist of storage units from different elements of the
original array.
is sequence associated with the dummy argument if the dummy argument is an explicit-shape or assumed-size1 A dummy argument or an entity that is host associated with a dummy argument is not present if the dummyarray. The rank and shape of the actual argument need not agree with the rank and shape of the dummy
argument, but the number of elements in the dummy argument shall not exceed the number of elements in the
element sequence of the actual argument. If the dummy argument is assumed-size, the number of elements in the
dummy argument is exactly the number of elements in the element sequence.
<IP_ADDRESS> Argument presence and restrictions on arguments not present
argument2 A nonoptional dummy argument shall be present. If an optional nonpointer dummy argument corresponds to a• does not correspond to an actual argument,
• corresponds to an actual argument that is not present, or
• does not have the ALLOCATABLE or POINTER attribute, and corresponds to an actual argument that
– has the ALLOCATABLE attribute and is not allocated, or
320 ⃝
c ISO/IEC 2017 – All rights reserved
ISO/IEC DIS 1539-1:2017 (E)
– has the POINTER attribute and is disassociated;
otherwise, it is present.
present pointer actual argument, the pointer association status of the actual argument shall not be undefined.3 An optional dummy argument that is not present is subject to the following restrictions.
(1) If it is a data object, it shall not be referenced or be defined. If it is of a type that has default4 Except as noted in the list above, it may be supplied as an actual argument corresponding to an optional dummyinitialization, the initialization has no effect.
(2) It shall not be used as the data-target or proc-target of a pointer assignment.
(3) If it is a procedure or procedure pointer, it shall not be invoked.
(4) It shall not be supplied as an actual argument corresponding to a nonoptional dummy argument
other than as the argument of the intrinsic function PRESENT or as an argument of a function
reference that is a constant expression.
(5) A designator with it as the base object and with one or more subobject selectors shall not be supplied
as an actual argument.
(6) If it is an array, it shall not be supplied as an actual argument to an elemental procedure unless an
array of the same rank is supplied as an actual argument corresponding to a nonoptional dummy
argument of that elemental procedure.
(7) If it is a pointer, it shall not be allocated, deallocated, nullified, pointer-assigned, or supplied as an
actual argument corresponding to an optional nonpointer dummy argument.
(8) If it is allocatable, it shall not be allocated, deallocated, or supplied as an actual argument corres-
ponding to an optional nonallocatable dummy argument.
(9) If it has length type parameters, they shall not be the subject of an inquiry.
(10) It shall not be used as the selector in an ASSOCIATE, SELECT RANK, or SELECT TYPE construct.
(11) It shall not be supplied as the data-ref in a procedure-designator.
(12) If shall not be supplied as the scalar-variable in a proc-component-ref .
argument, which is then also considered not to be present.1 While an entity is associated with a dummy argument, the following restrictions hold.<IP_ADDRESS> Restrictions on entities associated with dummy arguments
(1) Action that affects the allocation status of the entity or a subobject thereof shall be taken throughthe dummy argument.
(2) If the allocation status of the entity or a subobject thereof is affected through the dummy argument,
then at any time during the invocation and execution of the procedure, either before or after the
allocation or deallocation, it shall be referenced only through the dummy argument.
(3) Action that affects the value of the entity or any subobject of it shall be taken only through the
dummy argument unless
(a) the dummy argument has the POINTER attribute,
(b) the dummy argument is a scalar, assumed-shape, or assumed-rank object, and has the TAR-
GET attribute but not the INTENT (IN) or CONTIGUOUS attributes, and the actual argu-
ment is a target other than a coindexed object or an array section with a vector subscript,
(c) the dummy argument is an assumed-rank object with the TARGET attribute and not the
INTENT (IN) attribute, and the actual argument is a scalar target, or
(d) the dummy argument is a coarray and the action is a coindexed definition of the corresponding