J3/02-006C2.txt ISO/IEC JTC1/SC22/WG5-1473 Defect reports that led to corrigendum 2 and responses to them John Reid, 26 November 2001 ---------------------------------------------------------------------- NUMBER: 000002 TITLE: Free source form requirement for blank in PRINT statement KEYWORDS: Free source form, PRINT, blank DEFECT TYPE: Interpretation STATUS: Included in corrigendum/complete QUESTION: Consider the following PRINT statement form: PRINT"(I5)",5 Section 3.3.1 of the Fortran 95 standard states: A blank shall be used to separate names, constants, or labels from adjacent keywords, names, constants, or labels. NOTE 3.3 For example, the blank[s] after ... READ ... [is] required in the following: ... READ 10 ... Although the sentence preceding R420 is somewhat confusing in that it uses the phrase "a sequence of characters, DELIMITED by either apostrophes or quotation marks", the syntax rule itself is clear that the " or ' delimiting characters are part of the syntax. The first sentence on the top of page 36 then clarifies that although the delimiter characters are a part of the syntax, they are not a part of the value. Section 3.2 makes it clear that a character literal constant is a token. Section 3.2.5 describes delimiters but does not include either " or ' because it is describing delimiters for lists. Thus, it seems clear that in free source form a blank is required between the keyword PRINT and the character literal constant containing the format list but there is also some disagreement on this point among existing Fortran processors. (1) In free source form, is a blank required between the keyword PRINT and the character literal constant containing the format specification? (2) Also, for clarification, in free source form, is a blank required between the keyword PRINT and the asterisk that represents the list-directed output specifier? ANSWER: (1) Yes. The analysis in the QUESTION is correct. Since PRINT is a keyword, when the format specification is a character literal constant, the blank is required between the keyword PRINT and the format specifier. (2) No. Since PRINT is a keyword, according to the cited rule in 3.3.1, the asterisk would have to be a name, a constant, or a label in order for a blank to be required to separate PRINT from the asterisk. By 3.2.1, an asterisk is not a name. By 3.2.2, an asterisk is not a constant. And by 3.2.4, an asterisk is not a statement label. Yes, an asterisk may be used as a dummy argument alternate return specifier representing a statement label but that usage is irrelevant to the PRINT statement. Therefore, since an asterisk is none of the three items that must be separated from PRINT by a blank, the blank is not required. EDITS: None. SUBMITTED BY: Larry Rolison / Dick Hendrickson HISTORY: 97-238 m143 Submitted 01-151r1 m156 Passed unanimously by J3 meeting 01-224r1 m157 Passed by J3 letter ballot WG5/N1435 Passed by WG5 ballot 01-Nov wg5 no edits for corrigendum #2 => processing complete ---------------------------------------------------------------------- NUMBER: 000007 TITLE: Optional intrinsic function arguments KEYWORDS: intrinsic function, argument - optional DEFECT TYPE: Interpretation STATUS: Included in corrigendum/complete BACKGROUND: Interpretation request 000053 asked the following question: QUESTION: Should constraining text be added to the description of optional argument Y in CMPLX, and optional argument BACK in INDEX, and optional argument SIZE in ISHFTC, and optional argument A3,... in MAX, and optional argument A3,... in MIN, and optional argument BACK in SCAN, and optional argument BACK in VERIFY to state that the argument must not be an optional argument of an invoking procedure? and it was answered as follows: ANSWER: In principle yes; however it is more appropriate to add an additional restriction on dummy arguments not present in section 12.5.2.8. Discussion: The standard contains numerous restrictions intended to ensure that the rank of a given expression never changes. The case of elemental functions with optional arguments was inadvertently overlooked. Consider the following subprogram: SUBROUTINE SUB (A,B,C) INTEGER :: A ,B INTEGER, OPTIONAL :: C (:) PRINT *, MAX (A, B, C) END When C is present, the result of the elemental function MAX, is an array of the same shape as C. However, if SUB were to be called with the third argument omitted, the result would be a scalar. The supplied edit remedies this deficiency. Corrigendum 1 then edited the Fortran 90 standard as follows: EDITS: 1. Add the following point to the numbered list in section 12.5.2.8: [179:38] (5) If it is an array, it must 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. 2. In the paragraph following the numbered list, replace "It" with "Except as noted in (5) above, it" [179:39] Corrigendum 3 modified the above edit as follows as part of the response to Interpretation request 000193: EDITS: 1. In Section 12.5.2.8, add the following to the numbered list after the list item added by Corrigendum 1 [179:38+]: "(6) If it is a pointer, it must not be supplied as an actual argument corresponding to a nonpointer dummy argument other than as the argument of the PRESENT intrinsic function." 2. In Section 12.5.2.8, in the text added by Corrigendum 1 to the last sentence of the section [179:39]: change "in (5)" to "in the list" The text as modified appears at the end of 12.4.1.5 on page 203 of the Fortran 95 standard. QUESTION: While the response to interpretation request 000053 stated "in principle" that an optional dummy argument should not be passed to an optional argument of a called procedure, and it closed a "loophole" for optional array dummy arguments, it still did not address the simpler case of an optional scalar dummy argument being passed to the cited intrinsics. Consider the following example: SUBROUTINE sub(string, substring, direction) CHARACTER(*) :: string, substring LOGICAL, OPTIONAL :: direction k = INDEX(string, substring, direction) ... END SUBROUTINE The last paragraph of 12.4.1.5 states: Except as noted in the list above, it may be supplied as an actual argument corresponding to an optional dummy argument, which is then also considered not to be associated with an actual argument. The only case in "the list above" that is relevant is (1) because DIRECTION is a dummy data object and is not an array or pointer. But (1) does not apply because the appearance of DIRECTION as an actual argument is not a reference by the following from 2.5.5: The appearance of a data object name, data subobject designator, or procedure name in an actual argument list does not constitute a reference to that data object, data subobject, or procedure unless such a reference is necessary to complete the specification of the actual argument. The appearance of DIRECTION is not "necessary to complete the specification of" DIRECTION, so therefore it is not a reference so therefore (1) does not apply. Thus, the last paragraph of 12.4.1.5 does seem to apply which indicates that an optional dummy argument can be passed to an optional argument of an intrinsic procedure such as INDEX. However, this does not seem to agree with the "principle" espoused in the answer to interpretation request 000053, nor does the description of INDEX seem to indicate how the result is to be determined if the BACK argument is specified but is not present. (One could possibly construe the phrase "If BACK is absent" to mean "specified but not present" but that does not seem to be the intent of the existing wording or the "principle" espoused in interpretation request 000053.) For an intrinsic procedure that has an optional argument, may an optional dummy argument be passed to the optional argument of the intrinsic procedure? ANSWER: Yes. DISCUSSION: It is clear from the wording of the standard, as cited in the question, that this is allowed. Furthermore, it is clear from the wording in the CMPLX intrinsic that this was not unintentional. EDITS: None. SUBMITTED BY: Larry Rolison HISTORY: J3/97-243 m143 submitted WG5/N1452 Suggested revision 01-287 m158 Passed by J3 meeting 01-380 m158 Passed by J3 letter ballot WG5/N1470 Passed by WG5 ballot 01-Nov wg5 no edits for corrigendum #2 => processing complete ---------------------------------------------------------------------- NUMBER: 000009 TITLE: INTENT of MOLD argument to TRANSFER KEYWORDS: intrinsic function, TRANSFER, MOLD DEFECT TYPE: Interpretation STATUS: Included in corrigendum/complete QUESTION: In 13.3 [page 218:2], Fortran 95 states: The nonpointer dummy arguments of the generic intrinsic procedures in 13.14 have INTENT(IN) if the intent is not stated explicitly. In general, an actual argument that corresponds to a dummy argument that does not have the INTENT(IN) attribute does not need to be defined; you need to look at the particulars of the invoked procedure to decide if an actual argument needs to be defined before the invocation. It is likely that the only intrinsic procedure argument affected by this change in wording is the MOLD argument to the TRANSFER function. The value of the MOLD argument is never needed so there is no reason to define it before invoking TRANSFER in a Fortran 90 program. But, apparently it needs to be defined in a Fortran 95 program. This could break a program that uses a local name in a subroutine as the MOLD argument and doesn't always define the name with a value, or didn't save it. In this case, MOLD is like the arguments to the numeric inquiry functions, the "attribute" is a compile time characteristic, not a run-time "value" and should have the same exception as for the inquiry functions. (1) Was general statement about INTENT(IN) quoted above intentionally added to the Fortran 95 standard (how did it get into the standard)? (2) Is it the intent of the standard to apply this general statement to the MOLD argument of the TRANSFER intrinsic function? ANSWER: (1) Yes. (2) Yes, but this should not imply that the MOLD argument needs to be defined. An edit is supplied to clarify this situation. EDITS: [219:28+] Add new sentence to end of paragraph: "If the MOLD argument to this function is a variable, it need not be defined." SUBMITTED BY: Larry Rolison / Dick Hendrickson HISTORY: J3/97-246 m143 submitted WG5/N1452 Suggested revision 01-288 m158 Passed by J3 meeting 01-380 m158 Passed by J3 letter ballot WG5/N1470 Passed by WG5 ballot 01-Nov wg5 edits contained in corrigendum #2 {N1472} ---------------------------------------------------------------------- NUMBER: 000010 TITLE: Meaning of embedded blanks in namelist input name KEYWORDS: NAMELIST, optional qualification, name, input DEFECT TYPE: Erratum STATUS: Included in corrigendum/complete BACKGROUND: In running some older NAMELIST tests, a test case was encountered that has embedded blanks within the "optional qualification" following a namelist group object name: CHARACTER*10 string NAMELIST /junk/ string WRITE(9,*) ' $junk string( : ) = ''1234567890'' /' REWIND(9) READ(9,junk) ... END While studying the standard to determine if the above program was standard- conforming or not, some questions arose about the use of "name" and embedded blanks in the namelist section 10.9.1.1. Among them were: Since a blank is a delimiter, should it be allowed to be embedded in a variety of places in a namelist input record that are not currently described by the standard? Do we want to strain namelist input scanning more than a reasonable amount? In normal Fortran terminology, the term "name" does not include subobject qualification. In section 2.5.1 Name and designator, lines 2 through 5, the standard states: A name is used to identify a program constituent, such as a program unit, named variable, named constant, dummy argument, or derived type. The rules governing the construction of names are given in 3.2.1. A subobject designator is a name followed by one or more of the following: component selectors, array section, array element selectors, and substring selectors. In section 10.9.1 Namelist Input, lines 13 to 16, the standard states: In each name-value subsequence, the name shall be the name of a namelist group list item with an optional qualification and the name with the optional qualification shall not be a zero-sized array, a zero-sized array section, or a zero-length character string. The optional qualification, if any, shall not contain a vector subscript. In section 10.9.1.1 Namelist group object names, lines 32 and 33, the standard states: The name in the input record may be preceded and followed by one or more optional blanks but shall not contain embedded blanks. QUESTION: (1) Does Section 2.5.1 mean that the optional qualification described in the 10.9.1 is not part of the name for namelist input? If the optional qualification is not part of the name, there seem to be no rules for where blanks and end-of-record may occur within the optional qualification. Also note that size of the name and the optional qualification together may be longer than the size of an input record if there are multiple levels of structure component qualification in a structure component reference. (2) Are embedded blanks allowed within substring and subscript qualifications in the namelist input? May an END-OF-RECORD occur in these same places? (3) More specifically, are embedded blanks/END-OF-RECORD allowed in the following places in namelist input? a. Between the name and the left parenthesis of either a substring or subscript qualification? b. Between tokens within the parenthesized qualifier? c. Between the two sets of parentheses for array and substring notation? d. Within the two subscripts or start and end values themselves? (4) Are embedded blanks allowed within a reference to a structure? May an END-OF-RECORD occur within this reference? ANSWER: The answer to all of the questions above is no. In section 10.9.1, the standard says "In each name-value subsequence, the name shall be ...". This usage of "name" refers to the optionally qualified namelist group object list item; therefore, in this context, "name" refers to both the namelist group object name list item, and any following qualification. In section 10.9.1.1, the standard says "The name in the input record may be preceded and followed by one or more optional blanks but shall not contain embedded blanks." This usage of "name" also refers to optionally qualified namelist group object list item; therefore, no blanks are permitted anywhere within the "name" of a name-value subsequence. An edit clarifies this. Since the end of a record has the same effect as a blank in namelist input (10.9), an end of record may not appear anywhere within the "name" of a name-value subsequence. EDITS: Replace the last sentence of subclause 10.9.1.1 [179:32-33] by "In the input record, each object name or subobject designator may be preceded and followed by one or more optional blanks but shall not contain embedded blanks." SUBMITTED BY: Joanne Brixius / Larry Rolison HISTORY: 97-253 m143 submitted 01-152r1 m156 Passed unanimously at J3 meeting 01-224r1 m157 Passed by J3 letter ballot WG5/N1435 Passed by WG5 ballot 01-Nov wg5 edits contained in corrigendum #2 {N1472} ---------------------------------------------------------------------- NUMBER: 000011 TITLE: G editing typo KEYWORDS: G edit descriptor DEFECT TYPE: Erratum STATUS: Included in corrigendum/complete QUESTION: In F95 section 10.5.4.1.2, the last line of the table shows an equivalent conversion of F(w-n).1,n('b'). This is different from the corresponding table in F90, which shows this conversion as F(w-n).0,n('b'). There is no obvious reason for this change; it appears to be a typo in f95. Should this conversion be F(w-n).0,n('b') as in Fortran 90? ANSWER: Yes, this was a typographical error in f95. EDITS: [171:23] Last line of the table in 10.5.4.1.2. Change ".1" to ".0" SUBMITTED BY: Richard Maine HISTORY: 97-225 m143 Submitted Aug. 12, 1997 01-151r1 m156 Passed unanimously by J3 meeting 01-224r1 m157 Passed by J3 letter ballot WG5/N1435 Passed by WG5 ballot 01-Nov wg5 edits contained in corrigendum #2 {N1472} ---------------------------------------------------------------------- NUMBER: 000012 TITLE: Evaluation of Intrinsic Procedures KEYWORDS: Algorithm, Mathematical, Computational DEFECT TYPE: Erratum STATUS: Included in corrigendum/complete QUESTION: 1. When the standard specifies an algorithm for computing a mathematical procedure, must a processor use the specified algorithm? Example: ANINT is defined as INT (A + 0.5). On some processors ANINT (16 000 001.0) evaluates to 16 000 002.0 using this algorithm. 2. May a processor return a mathematically equivalent result in the evaluation of a numeric intrinsic procedure? Example: If ANINT (16 000 001.0) can be computed as the more expected 16 000 001.0, may a processor do so? ANSWER: 1. No, a processor is not required to use the algorithm from the standard. 2. Yes, a processor may return the mathematically equivalent result in the evaluation of any numeric intrinsic procedure. DISCUSSION: The use of an algorithm in the definitions for intrinsic procedures is intended to describe the end result. It is not intended to require that a processor use a particular method of achieving that result. Thus, an algorithm specifies the mathematical results, not the computational results, of the evaluation of intrinsic procedures. This standard does not require a processor to use a particular accuracy or precision. Section 1.4, "Exclusions", states in part: "This standard does not specify: . . . (6) The physical properties of the representation of quantities and the method of rounding, approximating, or computing numeric values on a particular processor." [1:26, 1:37-38] The edits correct the definitions of the results for the intrinsic functions ANINT and NINT to be expressed in mathematical terms. EDITS: On page 231, subclause 13.14.10, Result Value paragraph [231:16-17]. Replace by The result is the integer nearest A, or if there are two integers equally near A, the result is whichever such integer has the greater magnitude. On page 259, subclause 13.14.77, Result Value paragraph [259:9-10]. Replace by The result is the integer nearest A, or if there are two integers equally near A, the result is whichever such integer has the greater magnitude. SUBMITTED BY: Keith H. Bierman HISTORY: 95-247r1 m134 Submitted as F90 interp 000202 with proposed response, approved 9-4, subsumes F90 interp 000200. 95-256 m134 Ballot failed, 10-6 95-260 m135 Proposed response, no action 96-023 m136 Proposed response, no action 96-054 m137 Proposed response, no action 96-117 m138 Proposed response, no action 97-259r1 m143 Re-submitted as F95 interp 000012 with proposed response 00-214 m153 Passed unanimously 00-254 m154 Passed J3 letter ballot 00-268 m154 Failed WG5 ballot (N1403) 01-153 m155 Passed unanimously by J3 meeting 01-224r1 m157 Passed by J3 letter ballot WG5/N1435 Passed by WG5 ballot 01-Nov wg5 edits contained in corrigendum #2 {N1472} ---------------------------------------------------------------------- NUMBER: 000014 TITLE: Format of complex numbers in list-directed and namelist output KEYWORDS: DEFECT TYPE: STATUS: Included in corrigendum/complete QUESTION: 1. The seventh paragraph of Section 10.8.2 of the Fortran 95 standard states that complex numbers must be written with no embedded blanks unless the complex constant is broken across two records. Some of the implementations I tested put a blank after the comma even when the entire constant fit in a single record. Is an implementation permitted to include a blank after the comma in a complex constant produced by list-directed output when the constant fits in a single record? 2. Is a blank permitted after the comma in a complex constant produced by namelist output when the constant fits in a single record? ANSWER: 1. No. Section 10.8.2 [178:2-3] states: "The only embedded blanks permitted within a complex constant are between the comma and the end of a record and one blank at the beginning of the next record." 2. No. Section 10.9.2.1 [182:40-41] states: "The only embedded blanks permitted within a complex constant are between the comma and the end of a record and one blank at the beginning of the next record." SUBMITTED BY: HISTORY: 97-165 m143 Submitted WG5/N1410 Draft answer 00-260 m154 Passed by J3 meeting 00-328 m155 Passed J3 letter ballot, as amended WG5/N1428 Passed by WG5 ballot 01-Nov wg5 edits contained in corrigendum #2 {N1472} ---------------------------------------------------------------------- NUMBER: 000015 TITLE: Commas in list-directed output KEYWORDS: DEFECT TYPE: STATUS: Included in corrigendum/complete QUESTION: 5. The first paragraph of Section 10.8.2 of the Fortran 95 standard states: With the exception of adjacent nondelimited character constants, the values are separated by one or more blanks or by a comma optionally preceded by one or more blanks and optionally followed by one or more blanks. I have yet to find a Fortran implementation, other than my own, that satisfies this requirement. In particular, the statement PRINT *, 1, ',', 2 prints a comma immediately following the 1 on every implementation I tried. The comma was followed by zero, one, or two blanks in different implementations. 1. Is a separator required between a constant other than a nondelimited character constant and a following nondelimited character constant in list-directed output? 2. Is a separator required between a nondelimited character constant and a following constant that is not a nondelimited character constant? DISCUSSION: It is not clear in the question if the comma which is output is the optional separator or is the character constant from the list. ANSWER: 1. Yes. 2. Yes. A separator is required in both cases. The text quoted, which is at page 177:31-33, is quite explicit. The key word is "adjacent". SUBMITTED BY: HISTORY: 97-165 m143 Submitted WG5/N1410 Draft answer 00-260 m154 Passed by J3 meeting 00-329 m155 Passed by J3 letter ballot, as amended WG5/N1428 Passed by WG5 ballot 01-Nov wg5 edits contained in corrigendum #2 {N1472} --------------------------------------------------------------------- NUMBER: 000018 TITLE: ELEMENTAL procedures with no arguments KEYWORDS: Elemental, procedure DEFECT TYPE: Erratum STATUS: Included in corrigendum/complete Section 12.7.2 of ISO 1539-1:1997 seems to assume there is at least one argument to an elemental procedure. The semantics of the following examples do not seem to be clearly specified. Example 1: ELEMENTAL INTEGER FUNCTION f() f = 0 END Example 2: ELEMENTAL INTEGER FUNCTION g(i,j) INTEGER,INTENT(IN) :: i,j g = i + j END Example 3: ELEMENTAL INTEGER FUNCTION h(i) INTEGER,INTENT(IN),OPTIONAL :: i h = i END Example 4: ELEMENTAL SUBROUTINE s() REAL x,y,z x = 0 y = 0 z = x/y END QUESTION 1: What is the shape of a reference to function F in example 1? Is it scalar? QUESTION 2: If G() is referenced as G(iscalar,jarray(1:0)), the result is a zero-sized array. Is "iscalar" referenced (need it be defined)? Is the body of G() executed? QUESTION 3: What is the shape of a reference to H() if the argument is textually not present? QUESTION 4: When subroutine S is invoked, how many times is it executed? Is this example standard-conforming, or may a processor raise a divide-by-zero exception? ANSWER: (1) Yes, A reference to F() is intended to be scalar. A clarifying edit is supplied. (2) It is not possible to tell, in Fortran 95, whether the body of G() is executed, so that part of the question has no answer. [no edit required] Yes, ISCALAR must be defined; this is the same situation as writing ISCALAR + JARRAY(1:0) directly, with no user-defined ELEMENTAL procedure being used. [no edit required] (3) If the I argument to H is textually absent, a reference to H returns a scalar result (cf. answer to question 1). Note that execution of this procedure is not standard-conforming if the optional argument is not present. The "H = I" line should be replaced by IF (PRESENT(I)) THEN H = I ELSE H = 0 ! or some other desired scalar value END IF [no edit required] (4) The intention was that the subroutine is executed once per invocation. This is not clear from the standard; an edit is supplied to correct this oversight. However, the example is not standard-conforming on a processor whose arithmetic does not allow division by zero. [no edit required] EDITS: Replace the final sentence of subclause 12.4.3 [206:7-10] by: "A reference to an elemental subroutine (12.7) is an elemental reference if there is at least one actual argument corresponding to an INTENT(OUT) or INTENT(INOUT) dummy argument, all such actual arguments are arrays, and all actual arguments are conformable." [214:28] After "If" insert "there are no actual arguments or". SUBMITTED BY: Malcolm Cohen HISTORY: 98-117 m144 Submitted 00-123 m152 Revised by submitter (version above) but withdrawn for further study without vote 01-148r1 m156 Passed unanimously by J3 meeting 01-224r1 m157 Passed by J3 letter ballot WG5/N1435 Passed by WG5 ballot 01-Nov wg5 edits contained in corrigendum #2 {N1472} ---------------------------------------------------------------------- NUMBER: 000019 TITLE: Result of NULL intrinsic associated with CHARACTER(*) dummy argument KEYWORDS: NULL intrinsic, assumed character length parameter, argument association, pointer association DEFECT TYPE: Erratum STATUS: Included in corrigendum/complete QUESTION: Consider the following program. PROGRAM P CALL SUB(NULL()) CONTAINS SUBROUTINE SUB(C) CHARACTER(*), POINTER :: C PRINT *, LEN(C) END SUBROUTINE SUB END PROGRAM P According to 7.1.4.1 [91:27-30], "The data type, type parameters and rank of the result of the intrinsic function NULL when it appears without an argument are determined by the pointer that becomes associated with the result. See Table 7.2." In this case, the pointer that becomes associated with the result is the corresponding dummy argument when the result appears as an actual argument. However, according to 5.1.1.5 [51:14-18], a dummy argument of type character, with a character length parameter of *, "assumes the length of the associated actual argument when the procedure is invoked." Is this a standard conforming program? If so, how is the length of C determined, and what should be the output of this program? ANSWER: No, this program does not conform to the standard since the actual argument does not have a character length for the dummy argument to assume. The edit makes this clear. EDITS: Page 91, subclause 7.1.4.1, last line [91:41]. Add The optional argument shall also be present if the reference appears as an actual argument corresponding to a dummy argument with assumed character length. SUBMITTED BY: Henry Zongaro HISTORY: 98-148 m145 Submitted 01-154r1 m156 Passed unanimously by J3 meeting 01-224r1 m157 Passed by J3 letter ballot WG5/N1435 Passed by WG5 ballot 01-Nov wg5 edits contained in corrigendum #2 {N1472} ---------------------------------------------------------------------- NUMBER: 000020 TITLE: Execution of a WHERE statement within a WHERE construct KEYWORDS: WHERE statement, WHERE construct DEFECT TYPE: Erratum STATUS: Included in corrigendum/complete QUESTION: 7.5.3.2 [113:17-19] indicates that: Upon execution of a WHERE statement or a WHERE construct statement that is part of a , the pending control mask is established to have the value m .AND.(.NOT. mask-expr). c [112:41-45] indicates that: Upon execution of an ENDWHERE statement, the control mask and pending control mask are established to have the values they had prior to the execution of the corresponding WHERE construct statement. Following the execution of a WHERE statement that appears as a , the control mask is established to have the value it had prior to the execution of the WHERE statement. Notice that after execution of an ENDWHERE statement, the pending control mask is established to have the value it had prior to the execution of the corresponding WHERE construct statement, but the same is not the case for the pending control mask established by the execution of a WHERE statement that appears as a . According to this, the output of the following program PROGRAM P INTEGER :: A(2) = 0, B(2) = 0 WHERE((/.TRUE.,.TRUE./)) WHERE((/.TRUE.,.FALSE./)) A = 1 ELSEWHERE A = 2 END WHERE PRINT *, A WHERE((/.TRUE.,.TRUE./)) WHERE((/.TRUE.,.FALSE./)) B = 1 END WHERE ELSEWHERE B = 2 END WHERE PRINT *, B END PROGRAM P will be 1 2 1 0 Was this difference in behaviour intended by the committee? ANSWER: No. It was intended that WHERE() should have the same interpretation as WHERE() END WHERE The output from the above program should be 1 0 1 0 An edit is supplied to correct the text. EDITS: Page 113, subclause 7.5.3.2. In the first line of the paragraph following NOTE 7.48 [113:17] delete 'a WHERE statement or'; after the paragraph [113:20+] add the new paragraph: Upon execution of a WHERE statement that is part of a where-body-construct, the control mask is established to have the value .AND.. The pending mask is not altered. SUBMITTED BY: Henry Zongaro HISTORY: 98-149 m145 Submitted 01-155 m156 Passed unanimously by J3 meeting 01-224r1 m157 Passed by J3 letter ballot WG5/N1435 Passed by WG5 ballot 01-Nov wg5 edits contained in corrigendum #2 {N1472} ---------------------------------------------------------------------- NUMBER: 000021 TITLE: Restrictions on on END INTERFACE KEYWORDS: INTERFACE block, END INTERFACE, generic procedures DEFECT TYPE: Erratum STATUS: Included in corrigendum/complete QUESTION: According to section 12.3.2.1 [194:18-20] The may be included in the only if it was provided in the and, if included, shall be identical to the in the . It is not clear what the words "shall be identical" were intended to mean. In particular, were they intended to merely convey the idea that the two s shall specify the same entity, even though such an entity might be represented in more than one way, or were they intended to convey something more restrictive? Are either of the following examples standard conforming programs? Example 1: PROGRAM P INTERFACE OPERATOR(.NE.) LOGICAL FUNCTION F(I, C) INTEGER, INTENT(IN) :: I CHARACTER(*), INTENT(IN) :: C END FUNCTION F END INTERFACE OPERATOR(/=) END PROGRAM P Example 2: MODULE MOD INTERFACE GEN SUBROUTINE SUB1(I) INTEGER :: I END SUBROUTINE SUB1 END INTERFACE END MODULE MOD PROGRAM P USE MOD, G1=>GEN, G2=>GEN INTERFACE G1 SUBROUTINE SUB2(L) LOGICAL :: L END SUBROUTINE SUB2 END INTERFACE G2 END PROGRAM P ANSWER: The intention is that the in the END INTERFACE statement should be obviously the same as that in the INTERFACE statement, both to the human reader and to the compiler. The words "shall be identical" signify that they must be lexically identical, that is, identical apart from layout changes permitted by the source form and the interpretation of the operators .LT., .LE.,.GT., .GE., .EQ., and .NE. as always being identical to <, <=, >, >=, ==, and /=. Example 1 conforms to the standard, but example 2 does not. Edits are provided to make this clear. EDITS: On page 194, subclause 12.3.2.1, in the fourth constraint following R1207 [194:19-20] delete 'and, if included, ... ' and add: If the includes , the shall specify the same . If the includes ASSIGNMENT(=), the shall specify ASSIGNMENT(=). If the includes OPERATOR(), the shall specify the same . If one is .LT., .LE., .GT., .GE., .EQ., or .NE., the other is permitted to be the corresponding operator <, <=, >, >=, ==, or /=. SUBMITTED BY: Henry Zongaro HISTORY: 98-150 m145 Submitted 01-156 m156 1st answer passed unanimously at J3 meeting 01-224r1 m157 Passed by J3 letter ballot WG5/N1451 Passed by WG5 ballot 01-Nov wg5 edits contained in corrigendum #2 {N1472} ---------------------------------------------------------------------- NUMBER: 000022 TITLE: Use of NULL() as initialization KEYWORDS: NULL intrinsic, initialization, default initialization, DATA statement DEFECT TYPE: Erratum STATUS: Included in corrigendum/complete QUESTION: Rules R429, R505 and R540 respectively describe the syntax for default initialization of pointer components, pointer objects in type declaration statements and pointer objects in DATA statements. These rules seem to indicate that NULL is to be considered a keyword in those contexts. This has the surprising effect that the first example below is a standard conforming program, while the second is not. That is, in some contexts, something that looks very much like a reference to an intrinsic function, is in fact a keyword followed by parentheses. Example 1: MODULE MOD INTRINSIC NULL END MODULE MOD PROGRAM PROG USE MOD, DISASSOCIATE=>NULL INTEGER, PARAMETER :: NULL = 17 INTEGER :: J = NULL INTEGER :: I INTEGER, POINTER :: P => NULL(), P2 DATA P2, I/NULL(), NULL/ TYPE DT INTEGER, POINTER :: P => NULL() END TYPE DT TYPE DT2 INTEGER, POINTER :: I INTEGER :: J END TYPE DT2 TYPE(DT2) :: S = DT2(DISASSOCIATE(), NULL), S2 DATA S2/DT2(DISASSOCIATE(), NULL)/ END PROGRAM PROG Example 2: MODULE MOD INTRINSIC NULL END MODULE MOD PROGRAM PROG USE MOD, DISASSOCIATE=>NULL INTEGER, POINTER :: P => DISASSOCIATE(), P2 DATA P2/DISASSOCIATE()/ TYPE DT INTEGER, POINTER :: P => DISASSOCIATE() END TYPE DT END PROGRAM PROG In some places in the scoping unit of PROG example 1, NULL() is used to specify initialization or default initialization, while in others NULL is a named constant, and DISASSOCIATE() must be used to specify initialization. 1) Is example 1 a standard conforming program? 2) Is example 2 a standard conforming program? 3) Was it the intent of the committee that, within the contexts of R429, R505 and R540, NULL should be treated strictly as a keyword rather than as a reference to an intrinsic function? DISCUSSION: The intention is that the intrinsic function NULL be referenced with no arguments in initialization contexts. This is made clear in the middle of page 49 in the paragraph that begins 'If ' [49:20-21] and also in 7.1.4.1. If the intrinsic function has been renamed, the new name should be used. ANSWER: (1) No, the example is not conforming because it references two different entities with the same name (NULL the local variable, and NULL the intrinsic function). See 14.1.2. (2) No, the example does not conform to the standard as published. This is an error, corrected by the supplied edits which make this example conforming. (3) No, the intention was that "NULL()" should be a reference to the intrinsic function. Edits are supplied to remove the keyword status of this syntax. EDITS: Page 39, subclause 4.4.1, replace the second line of R429 [39:20] by <> => R429a <> Constraint: shall be a reference to the intrinsic function NULL with no arguments. Page 47, subclause 5.1, replace the second line of R505 [47:40] by <> => Page 49, subclause 5.1, in the paragraph that begins 'If ' [49:20-21], replace 'NULL()' by '' twice. Page 62, subclause 5.2.10, replace the fifth line of R540 [62:19] by <> Page 62, subclause 5.2.10, in the penultimate line of the page [62:48], replace 'NULL()' by 'pointer association status'. Page 63, subclause 5.2.10, in lines 1, 7 and 10 of the page [63:1,7,10], replace 'NULL()' by '' thrice. SUBMITTED BY: Henry Zongaro HISTORY: 98-151 m145 Submitted 01-157 m156 Passed unanimously by J3 meeting 01-224r1 m157 Passed by J3 letter ballot WG5/N1435 Passed by WG5 ballot 01-Nov wg5 edits contained in corrigendum #2 {N1472} ---------------------------------------------------------------------- NUMBER: 000024 TITLE: Termination of a partial record by a CLOSE, BACKSPACE, ENDFILE, or REWIND statement KEYWORDS: Record termination, CLOSE, BACKSPACE, ENDFILE, REWIND DEFECT TYPE: Erratum STATUS: Included in corrigendum/complete QUESTION: Suppose a partial record has been written as a result of a nonadvancing WRITE. If the file is closed, or a BACKSPACE, ENDFILE, or REWIND statement is performed on the file, must the partial record be terminated? ANSWER: After a nonadvancing WRITE there is always a current record in a file. Existing descriptions of file closure and of the BACKSPACE, ENDFILE and REWIND statements define subsequent operations on the file. Further clarification in the BACKSPACE, ENDFILE and REWIND cases is provided in C.6.1.5 [321:7-11]. An edit is provided to make the intention clear. EDITS: Page 136. At the end of the last paragraph of subclause 9.2.1.3.1 [136:33] add If a nonadvancing output statement leaves a file positioned within the current record and no further output statement is executed for the file before it is closed or a BACKSPACE, ENDFILE, or REWIND statement is executed for it, the file is positioned after the current record before the specified action is performed. SUBMITTED BY: Robert Corbett HISTORY: 98-155 m145 Submitted (part 2) WG5/N1410 Draft answer 00-260 m154 Passed by J3 meeting 00-329 m155 Failed J3 letter ballot 01-158r1 m156 Passed unanimously by J3 meeting 01-224r1 m157 Passed by J3 letter ballot WG5/N1435 Passed by WG5 ballot 01-Nov wg5 edits contained in corrigendum #2 {N1472} ---------------------------------------------------------------------- NUMBER: 000025 TITLE: List-directed input: types of variables corresponding to repeated values KEYWORDS: List-directed input, repeated values DEFECT TYPE: Erratum STATUS: Included in corrigendum/complete QUESTION: When a repeat count is used in list-directed input, must all the variables into which the repeated value is read have the same type? I see no reason in the standard to assume that restriction, but at least one Fortran 90 implementation assumes it. ANSWER: No, the variables are not required to be of the same type, but the type of the repeated constant is either a literal constant, or a nondelimited character constant, but not both (10.8, "where is a literal constant or a nondelimited character constant"). Whether certain forms of a repeated constant are treated as a literal constant or a nondelimited character constant is determined by the type of the first variable which consumes this value. Indeed, how many characters from the input record are part of is dependent on the type of the first variable which consumes a value from that . For example, the input 2*(1.0, 0.0) conforms to the standard when consumed by three list items of type character or by two list items of type complex. If there are three character variables, the first two get the value "(1.0", while the third gets the value "0.0)". If there are two complex variables, they both are assigned the value (1.0,0.0). Similarly, the input 2*.TRUE. can be consumed by two logical variables, or two character variables, but not by one character and one logical variable. An edit is provided to clarify the situation. EDITS: In section 10.8.1, add the following as a new paragraph, just before Note 10.26 [175:33+]. "For the form of an input value, the constant is interpreted as a nondelimited character constant if the first list item corresponding to this value is of type default character, there is a nonblank character immediately after , and that character is not an apostrophe or a quotation mark; otherwise, is interpreted as a literal constant." SUBMITTED BY: Robert Corbett HISTORY: 98-155 m145 Submitted (part 3) WG5/N1410 Draft answer 01-159r1 m156 Passed unanimously by J3 meeting 01-224r1 m157 Passed by J3 letter ballot WG5/N1435 Passed by WG5 ballot 01-Nov wg5 edits contained in corrigendum #2 {N1472} ---------------------------------------------------------------------- NUMBER: 000026 TITLE: List-directed input: types of variables corresponding to repeated values KEYWORDS: list-directed, repeat DEFECT TYPE: Interpretation STATUS: Included in corrigendum/complete QUESTION: Consider the example CHARACTER*80 STRING COMPLEX Z READ (*, *) Z, STRING Suppose the input consists of 2*(1.0, 0.0) After the READ, should Z contain (1.0,0.0) and should STRING contain '(1.0,'? ANSWER: No. This is not standard conforming. See the answer to interpretation number 000025. EDITS: None. SUBMITTED BY: Robert Corbett HISTORY: 98-155 m145 Submitted (part 4) WG5-N1456 Draft answer 01-306r1 m158 Passed by J3 meeting 01-380 m158 Passed by J3 letter ballot WG5/N1470 Passed by WG5 ballot 01-Nov wg5 no edits for corrigendum #2 => processing complete ---------------------------------------------------------------------- NUMBER: 000027 TITLE: Sequential formatted I/O: position of the left tab KEYWORDS: format, tab DEFECT TYPE: Clarification STATUS: Included in corrigendum/complete QUESTION: When a file is positioned within a record at the start of sequential formatted I/O, where is the left tab limit (see Section 10.6.1.1)? Is it at the start of the record or at the point where the file was positioned at the start of execution of the statement? ANSWER: The left tab limit is the point where the file was positioned at the start of execution of the statement. DISCUSSION: This follows from the second sentence of 10.6.1.1, which states "Immediately prior to data transfer, the left tab limit becomes defined as the character position of the current record." EDITS: None. SUBMITTED BY: Robert Corbett HISTORY: 98-155 m145 Submitted (part 5) WG5/N1452 Suggested answer 01-289 m158 Passed by J3 meeting 01-380 m158 Passed by J3 letter ballot WG5/N1470 Passed by WG5 ballot 01-Nov wg5 no edits for corrigendum #2 => processing complete ---------------------------------------------------------------------- NUMBER: 000028 TITLE: Implicitly Typed Statement Function Character Dummy KEYWORDS: statement function, constant expression, implicit typing DEFECT TYPE: Clarification STATUS: Included in corrigendum/complete QUESTION: Is the following program-unit standard-conforming? SUBROUTINE sub(n) IMPLICIT CHARACTER*(n) (c) stmtfn(ch) = LEN(ch) END A quick survey of 6 compilers showed no consensus on whether this was legal, with 3 accepting it (as standard-conforming), 2 rejecting it, and 1 crashing with an internal error. The standard seems to say (middle of section 5.1.1.5, [51:32-33]) that if you explicitly specify the length then it must be a constant specification expression, but does not appear to constrain implicit lengths. ANSWER: No, the example is not standard-conforming. DISCUSSION: The quoted section of the standard says: "The length specified for a ... statement function dummy argument of type character shall be a constant specification expression." The first paragraph of 5.3 says "In a scoping unit, an IMPLICIT statement specifies a type, and possibly type parameters, for all implicitly typed data entities ..." Therefore the requirement that the character length of a statement function or statement function dummy argument be constant applies to implicitly typed entities as well as explicitly typed entities. EDITS: None SUBMITTED BY: Malcolm Cohen HISTORY: 98-164 m145 Submitted 01-149 m156 Passed unanimously by J3 meeting 01-224r1 m157 Passed by J3 letter ballot WG5/N1435 Passed by WG5 ballot 01-Nov wg5 no edits for corrigendum #2 => processing complete ---------------------------------------------------------------------- NUMBER: 000029 TITLE: Nested Derived Types and Defined Assignment KEYWORDS: derived type, defined assignment DEFECT TYPE: Clarification STATUS: Included in corrigendum/complete QUESTION: According to Fortran 90, intrinsic assignment of derived type entities does not invoke defined assignment for components of these entities, even if it exists. Should this situation have been corrected in Fortran 95 to avoid breaking encapsulation of derived types? That is, in the example program below, is the final assignment statement intended to invoke the user-defined assignment routine for the "name" components of "a" and "b", or should it do pointer assignment on the (PRIVATE) "value" components of the "name" components? MODULE lib_varying_string TYPE varying_string PRIVATE CHARACTER,POINTER :: value(:) END TYPE INTERFACE ASSIGNMENT(=) MODULE PROCEDURE assign_vs_to_vs END INTERFACE CONTAINS SUBROUTINE assign_vs_to_vs(var,expr) TYPE(varying_string),INTENT(OUT) :: var TYPE(varying_string),INTENT(IN) :: expr ALLOCATE(var%value(SIZE(expr%value,1))) var%value = expr%value END SUBROUTINE END PROGRAM programme USE lib_varying_string TYPE mytype TYPE(varying_string) name END TYPE TYPE(varying_string) x,y TYPE(mytype) a,b x = y ! invokes "assign_vs_to_vs(x,(y))". a%name = b%name ! invokes "assign_vs_to_vs(a%name,(b%name))" a = b ! in F90, pointer assigns the "value" components END ANSWER: No, there is no ambiguity or error in the standard. DISCUSSION: Intrinsic assignment is not intended to invoke user-written procedures. This would introduce anomalies with initialization by DATA statements. Library writers cannot in any case depend on defined assignment to enforce encapsulation automatically, because the user can deliberately (or accidentally) omit to import the defined assignment from the module. (Also, other facilities such as TRANSFER may break encapsulation). In the example given, a defined assignment should be provided for TYPE(mytype) by the programmer. EDITS: None. NOTE: This is MTE work item M16 for Fortran 2000. SUBMITTED BY: Malcolm Cohen HISTORY: 97-197 m142 Submitted 97-197 m145 Passed unanimously as amended {see 98-167 minutes} Failed WG5 letter ballot. 00-330 m155 Option 0 answer passed unanimously by J3 meeting 01-224r1 m157 Passed by J3 letter ballot WG5/N1435 Passed by WG5 ballot 01-Nov wg5 no edits for corrigendum #2 => processing complete ---------------------------------------------------------------------- NUMBER: 000032 TITLE: Is the TRANSFER function result undefined? KEYWORDS: transfer function, undefined, processor dependent DEFECT TYPE: STATUS: Included in corrigendum/complete The result value section of the TRANSFER function says "...If the physical representation of the result is longer than that of SOURCE, the physical representation of the leading part is that of SOURCE and the remainder is undefined." ^^^^^^^^^^^^^^^^^^^^^^^^^^ and case (ii) gives an example of a transfer of 3 reals to 2 complexes with the imaginary part of the second complex being undefined. Where can you use this form of TRANSFER? There's a general prohibition about referencing undefined things. Doesn't that apply to expressions containing TRANSFER as well? Something like X = transfer (four_bytes,eight_bytes) or X = transfer(transfer(four_bytes,eight_bytes), four_bytes) reference the undefined part. Maybe in the latter case we could say that the "reference" in the outer transfer doesn't "require the value" of all of its argument. But that seems like an odd reading to me. We can't use it for functions like SIZE, because they only allow their argument to be undefined if it is a single variable name (13.8.5). The only thing I can think of is passing to a procedure argument that has no INTENT specified but that uses the defined part of the argument as if it were INTENT(IN). The intent can't be specified because INTENT(IN) arguments must be defined on entry. Question: Should the phrase be changed from "the remainder is undefined" to "the remainder is processor dependent"? DISCUSSSION: This is made more confusing by: "Any variable or function reference used as an operand shall be defined at the time the reference is executed." [97:1] The mention of function reference is confusing, because a function is not allowed to return without fully defining its result, viz "If the result variable is not a pointer, its value shall be defined by the function." [207:28] ANSWER: Yes, for the reasons given. Edits are provided. EDITS: Clause 13.14.110 Page 272, line 4. Change 'undefined' to 'processor dependent'. Page 272, line 17. Change 'undefined' to 'processor dependent'. SUBMITTED BY: Dick Hendrickson HISTORY: 98-183 Submitted WG5/N1414 Draft answer 00-260 m154 Passed by J3 meeting 00-329 m155 Passed by J3 letter ballot, as amended WG5/N1428 Passed by WG5 ballot 01-Nov wg5 edits contained in corrigendum #2 {N1472} ---------------------------------------------------------------------- NUMBER: 000066 TITLE: Errors in processing data transfer statements KEYWORDS: ERR=; IOSTAT=; Data transfer statements DEFECT TYPE: Erratum STATUS: Included in corrigendum/complete Consider the following program. INTEGER :: A(10), IDX, J OPEN(10, FORM='UNFORMATTED', ACCESS='SEQUENTIAL', STATUS='OLD', & ACTION='READ') READ(10, IOSTAT=IOS) IDX, J, A(IDX) END If an error occurs while processing the variable J in the data transfer statement, does this program become non-standard conforming? According to 9.4.3: "If an error condition or an end-of-file condition occurs during execution of an input/output statement, execution of the input/output statement terminates and if the input/output statement contains any implied-DOs, all of the implied-DO variables in the statement become undefined. If an error condition occurs during execution of an input/output statement, the position of the file becomes indeterminate. If an error or end-of-file condition occurs on input, all input list items become undefined." According to 9.4.4: "The effect of executing a data transfer input/output statement shall be as if the following operations were performed in the order specified: (1) Determine the direction of data transfer (2) Identify the unit (3) Establish the format if one is specified (4) Position the file prior to data transfer (9.2.1.3.2) (5) Transfer data between the file and the entities specified by the input/output list (if any) or namelist (6) Determine whether an error condition, an end-of-file condition, or an end-of-record condition has occurred (7) Position the file after data transfer (9.2.1.3.3) (8) Cause any variables specified in the IOSTAT= and SIZE= specifiers to become defined." A simple reading of this seems to indicate that the point at which the error occurs and is detected by a standard-conforming processor is unspecified. Because IDX becomes undefined, the reference to IDX in the variable A(IDX) is incorrect. However, this is a very common style of coding I/O operations in Fortran. QUESTION 1: Was it the committee's intent that such a program should not be standard-conforming in the presence of an error condition? QUESTION 2: Does the fact that the error occurred before the item A(IDX) was processed mean that there was no reference to IDX, and hence, that the program is standard-conforming? ANSWER 1: No. ANSWER 2: Yes. DISCUSSION: The referenced paragraph (9.4.4) is misleading. The entire I/O list is not necessarily expected to be processed in the presence of an error. EDITS: Section 9.4.4, list item 6 [150:33], delete "an error condition,", and change ", or" to "or" Section 9.4.4, add the following after list item (8): "If an error condition occurs during any of the above operations, execution of the data transfer statement terminates, any variable specified in an IOSTAT= specifier becomes defined, and the error condition is processed as described in 9.4.3." SUBMITTED BY: Henry Zongaro HISTORY: 99-177 m150 submitted 99-212 m150 approved uc 00-May failed J3 letter ballot 00-213 m153 passed unanimously 00-254 m154 Failed J3 letter ballot 01-295r1 m158 Passed by J3 meeting 01-380 m158 Passed by J3 letter ballot WG5/N1470 Passed by WG5 ballot 01-Nov wg5 edits contained in corrigendum #2 {N1472} ---------------------------------------------------------------------- NUMBER: 000067 TITLE: Writing zeros KEYWORDS: list-directed output, namelist output DEFECT TYPE: Erratum STATUS: Included in corrigendum/complete The standard currently requires a real zero to be written in exponential form when using list-directed or namelist output. QUESTION: Is this requirement intentional or an oversight? ANSWER: The requirement is an oversight, but is not an appropriate problem to fix in Fortran 95 via an interpretation. EDITS: None. SUBMITTED BY: Robert Corbett HISTORY: 99-193 m150 Submitted 99-213r1 m150 approved uc 00-210 m153 Passed by J3 letter ballot 00-268 m154 Failed WG5 letter ballot (N1395 & N1403) WG5/N1452 Suggested revision 01-290r1 m158 Passed by J3 meeting 01-380 m158 Passed by J3 letter ballot WG5/N1470 Passed by WG5 ballot 01-Nov wg5 no edits for corrigendum #2 => processing complete ---------------------------------------------------------------------- NUMBER: 000071 TITLE: Character array constructors KEYWORDS: Character, array constructor, zero-size DEFECT TYPE: Erratum STATUS: Included in corrigendum/complete QUESTION: The f95 standard appears to leave the length of zero-sized character array constructors undefined. The penultimate paragraph of clause 4.5 says "The type and parameters of an array constructor are those of the expressions." If there are no elements, then the values of the type parameters might not be defined. The type and kind are always well defined at compile time. However, the length parameter for zero-sized character array constructors is not obviously well-defined, even at run-time. Zero-sized constructors are certainly allowed, as mentioned in the antepenultimate paragraph of clause 4.5: "An empty sequence forms a zero-sized rank-one array." Experimentation with different f90 compilers yields varying results. QUESTION 1: Is the following a valid program and, if so, what len value does it print? program zero write (*,*) len( (/ ('abc', i = 1 , 0) /) ) end QUESTION 2: Is the following a valid program and, if so, what value does it print? program zero_size integer :: n = 0 call sub('abcdefghij', n) contains subroutine sub(string, n) character*(*) :: string integer :: n integer :: i write (*,*) len( (/ (string(:i+2), i = 1 , n) /) ) end subroutine end program zero_size QUESTION 3: Is the following a valid program and, if so, what values does it print for the lengths and for n_calls? program zero_size integer :: n = 0 integer :: n_calls = 0 call sub('abcdefghij', n) write (*,*) 'n_calls = ', n_calls contains subroutine sub(string, n) character*(*) :: string integer :: n integer :: i write (*,*) len( (/ (string(:f(i)), i = 1 , n), 'abcde' /) ) end subroutine sub integer function f(i) f = 2*i + 5 n_calls = n_calls + 1 end function f end program zero_size QUESTION 4: Is this character array constructor valid? (/ ('ABC'(:J/2), J=4,2) /) ANSWER: (1) Yes. The length is 3. Clause 4.5 says that "The type and type parameters of an array constructor are those of the expressions." There is no exclusion for s that contribute no elements to the value of the array constructor: thus s that are inside zero-trip implied DO loops still contribute their "type" information. The example array constructor has an that is the character literal 'abc'; this clearly has the character length of 3 and therefore the array constructor has a character length of 3. The description of how an that is an implied DO is handled confuses syntax and semantics: an edit is supplied to clarify this. (2) No, the has an indeterminate character length and so cannot satisfy the requirement for the lengths to be the same. The edits below clarify this situation. (3) No, one has an indeterminate character length and so cannot satisfy the requirement for the lengths to be the same. (4) No, the has an indeterminate character length. EDITS: In clause 4.5, in the paragraph beginning "If an is a scalar expression" [46:1] replace: "an sequence" with "a sequence of elements". [45:38+] Add to end of paragraph: "The character length of an ac-value in an whose iteration count is zero shall not depend on the value of the implied DO variable and shall not depend on the value of an expression that is not an initialization expression." SUBMITTED BY: Richard Maine HISTORY: 98-101 m144 submitted 20 Nov 1997 99-207 m150 additional input 99-217r3 m150 approved uc 00-209 m153 passed by J3 letter ballot m153 duplicated in interp 000071; processing 000016 complete 00-268 m154 Failed WG5 letter ballot (N1395 & N1403) WG5/N1452 Suggested revision 01-291r1 m158 Passed by J3 meeting 01-380 m158 Passed by J3 letter ballot, as amended WG5/N1451 Passed by WG5 ballot 01-Nov wg5 edits contained in corrigendum #2 {N1472} ---------------------------------------------------------------------- NUMBER: 000073 TITLE: Is padding allowed in storage sequences? KEYWORDS: alignment, padding, storage sequence DEFECT TYPE: STATUS: Included in corrigendum/complete QUESTION: 1. Is padding allowed in storage sequences? Consider the common block CHARACTER C INTEGER I COMMON /CBLK/ C, I 2. Is padding allowed between the variables C and I? Consider the sequence type TYPE T SEQUENCE CHARACTER C INTEGER I END TYPE 3. Is padding allowed between component C and component I? Discussion: A user recently complained that Sun f90 adds pad for alignment to sequence types and common blocks. He asserted that the Fortran standard forbids padding storage sequences. I have tested seven different implementations, and I found that all but one use padding in the examples given. The user based his assertion on the text of Section 14.6.3.1 of the Fortran 95 standard. He claimed the statements (7) A nonpointer scalar object of sequence type occupies a sequence of storage sequences corresponding to the sequence of its ultimate components and The order of the storage units in such a composite storage sequence is that of the individual storage units in each of the constituent storage sequences taken in succession, ignoring any zero-sized constituent sequences. made his case. I pointed out that where the standard intends to require storage units to be contiguous, it uses the word "contiguous". He was not satisfied by that answer. The user pointed out that the definition of the size of a storage sequence supports his assertion. He claimed that the size of the common block given above is one character storage unit plus one numeric storage unit, and that that is the size of the common block INTEGER J CHARACTER D COMMON /CBLK/ J,D which Sun f90 does not pad. While that arithmetic of sizes makes sense, I have been told informally by a committee member that that was not the intent of the committee. Note 5.33 lends support to his statement. I have been unable to find any for the first paragraph of Note 5.33 in the normative part of the standard. I suggest moving the first paragraph of Note 5.33 to the normative part of the standard. I tried to provide a definition of addition of sizes of different storage units that would imply the effect stated in Note 5.33, but I failed. ANSWER: 1. Yes. Padding between storage units is allowed unless those storage units are explicitly required to be contiguous in Section 14.6.3.1 or they are required to be contiguous in order to satisfy the storage association rules given in Sections 14.6.3.2 and 14.6.3.3. Note 5.33 (page 70) states: 'A common block is permitted to contain sequences of different storage units'. This is a consequence of the absence of any requirement on the types of the variables in a common block. It further states 'provided each scoping unit that accesses the common block specifies an identical sequence of storage units for the common block'. This is an informal rewording of the rules on common association which are found in sections 5.5.2.1 and 5.5.2.3, and the rules on storage association which are in 14.6.3. 5.5.2.1 and 5.5.2.3 do not prohibit padding between sequences of storage units, but any such padding is required to be consistent between scoping units. 2. Yes. 3. Yes. REFERENCES: ISO/IEC 1539-1:1997(E), Note 5.33 and Section 14.6.3. EDITS: None. SUBMITTED BY: Robert Corbett HISTORY: 99-190 m150 submitted (straw vote to allow padding 11-0-0) WG5/N1414 Draft answer 00-260 m154 Passed by J3 meeting 00-329 m155 Passed by J3 letter ballot, as amended WG5/N1428 Passed by WG5 ballot 01-Nov wg5 no edits for corrigendum #2 => processing complete ---------------------------------------------------------------------- NUMBER: 000075 TITLE: Defined assignment and INTENT(IN) dummy arguments in PURE procedures KEYWORDS: INTENT(IN), PURE, defined assignment, dummy arguments DEFECT TYPE: STATUS: Included in corrigendum/complete QUESTION: Consider the following module: MODULE m TYPE t REAL,POINTER :: value END TYPE INTERFACE ASSIGNMENT(=) MODULE PROCEDURE t_asgn_t END INTERFACE CONTAINS PURE SUBROUTINE t_asgn_t(lhs,rhs) TYPE(t),INTENT(OUT) :: lhs TYPE(t),INTENT(IN) :: rhs ALLOCATE(lhs%value) lhs%value = rhs%value END SUBROUTINE PURE FUNCTION t_plus_t(a,b) TYPE(t) t_plus_t,a,b INTENT(IN) a,b t_plus_t = a !defined assignment !Alternative: CALL t_asgn_t(t_plus_t,a) t_plus_t%value = t_plus_t%value + b%value END FUNCTION END According to F95 [212:33-45] "Constraint: In a pure subprogram any variable which ... is a dummy argument to a pure function ... shall not be used in the following contexts: ... (8) As the of an in which the is of a derived type if the derived type has a pointer component at any level of component selection; ..." Therefore it appears that the statement labelled "defined assignment" is not allowed. However, it is semantically equivalent to the commented-out statement in the following line, which would have been allowed. Clearly intrinsic assignment in that context must be disallowed as it implicitly does a pointer assignment which could be used to produce a side-effect, but the standard appears to rule out defined assignment as well (which if pure cannot cause any side-effect). Is this intentional? ANSWER: No. (8) should apply only to intrinsic assignment so the example is correct. EDIT: Clause 12.6. Penultimate line of page 212 [212:44]. Change to 'intrinsic assignment statement'. SUBMITTED BY: Malcolm Cohen HISTORY: 99-201 m150 submitted WG5/N1414 Draft answer 00-260 m154 Passed by J3 meeting 00-329 m155 Passed by J3 letter ballot WG5/N1428 Passed by WG5 ballot, as amended 01-Nov wg5 edits contained in corrigendum #2 {N1472} ---------------------------------------------------------------------- NUMBER: 000081 TITLE: Definition status of derived-type objects with pointer components KEYWORDS: Definition status, Derived type, Pointer component DEFECT TYPE: Erratum STATUS: Included in corrigendum/complete QUESTION: Consider: TYPE t REAL,POINTER :: x END TYPE TYPE(t) var1,var2 NULLIFY(var1%x) var2 = var1 ! Unfortunate. According to 14.7.1, "An object is defined if and only if all of its subobjects are defined." from which I conclude that the program fragment above is not conforming. Should the definition status of an object containing pointer components depend on the pointer association status of its pointer components and not their definition status? ANSWER: No, pointer components shall not affect the definition status of an object. The above program fragment was intended to be standard- conforming. Edits are supplied to clarify this situation. EDITS: [288:17] Replace with "(1) An array is defined if and only if all of its elements are defined. (2) A derived-type scalar object is defined if and only if all of its nonpointer components are defined. (3) A complex or character scalar object is defined if and only if all of its subobjects are defined." [288:18-19] Replace "(2)" with "(4)". SUBMITTED BY: Malcolm Cohen HISTORY: 99-266 m151 submitted 99-266r1 m151 approved uc 00-135 m152 revised but withdrawn (no vote) 01-165r1 m156 Passed unanimously by J3 meeting 01-224r1 m157 Passed by J3 letter ballot WG5/N1451 Passed by WG5 ballot 01-Nov wg5 edits contained in corrigendum #2 {N1472} ---------------------------------------------------------------------- NUMBER: 000085 TITLE: Public components of inaccessible types KEYWORDS: Accessibility, Derived Types, Components DEFECT TYPE: Erratum STATUS: Included in corrigendum/complete QUESTION: F90 interpretation 32 indicated that components of a derived type may be accessible even in scopes where the derived type name is inaccessible. It added an edit to 12.1.2.2.1 of f90 (14.6.1.3 of f95) saying "If a derived type name of a host is inaccessible, data entities of that type or subobjects of such data entities can still be accessible." The discussions in the last 2 paragraphs of 4.4.1 of f95 appear to treat the accessibility of the derived type and its components as independent issues. Drafts of f2k added a note to make the independence clear. However, 14.1.2.5 of f95 says "If the type is accessible...and the definition of the type does not contain the PRIVATE statement (4.4.1), the component name is accessible...." This statement appears to make accessibility of the type a condition for accessibility of the component names, in contradiction with the above cited edit from f90 interpretation 32. The following code sample illustrates the issue. This sample works on several f90 compilers. module m type t integer :: i end type t type (t) :: a end module m program p use m, only: a a%i = 2 write (*,*) a%i end program p Question 1. Is it allowed to access public components of a derived type object when the type name is inaccessible as illustrated in the above sample code? Question 2. Should there be an edit in 14.1.2.5 of f95 to clarify this? ANSWER: (1) Yes. (2) Yes. DISCUSSION: The quoted text from 14.1.2.5 does not specify the accessibility of components when a type is not accessible. EDITS: [280:25-26] Replace "the type is accessible ... 14.6.1.3)" by "an entity of the type is accessible in another scoping unit" {Whether by use or host association, or - if the type is accessible - by declaring a local variable of the type.} SUBMITTED BY: Richard Maine HISTORY: 99-101 m148 Submitted WG5/N1404 Draft answer 00-260 m154 Passed by J3 meeting 00-329 m155 Failed J3 letter ballot 01-160 m156 Passed unanimously at J3 meeting 01-224r1 m157 Passed by J3 letter ballot WG5/N1435 Passed by WG5 ballot 01-Nov wg5 edits contained in corrigendum #2 {N1472} ---------------------------------------------------------------------- NUMBER: 000086 TITLE: Definition status requirements for defined operations KEYWORDS: Defined operations DEFECT TYPE: Erratum STATUS: Included in corrigendum/complete QUESTION: 7.1.7 "Evaluation of operations" states "This section applies to both intrinsic and defined operations. Any variable ... used as an operand in an expression shall be defined at the time the reference is executed." (1) Was this particular requirement intended to apply to defined operations? I.e., is the following example program invalid: MODULE m INTERFACE OPERATOR (.cand.) MODULE PROCEDURE default_cand END INTERFACE CONTAINS LOGICAL FUNCTION default_cand(a,b) RESULT(r) LOGICAL,INTENT(IN) :: a,b IF (a) THEN r = b ELSE r = .FALSE. END IF END FUNCTION END PROGRAM example1 USE m LOGICAL :: false = .FALSE. LOGICAL :: undefined PRINT *, false .cand. undefined END (2) If the answer to the question is Yes (and the program is therefore invalid), would the program be standard-conforming if the penultimate line were changed to PRINT *, default_cand(false,undefined) ? (3) 7.1.7 goes on to state "When a structure is referenced, all of the components shall be defined." Does this mean that pointer components must be associated with a defined target? I.e. is the following program non-conforming? MODULE m2 TYPE my_iptr PRIVATE INTEGER,POINTER :: ptr => NULL() END TYPE INTERFACE OPERATOR(.isnull.) MODULE PROCEDURE isnull_myip END INTERFACE CONTAINS LOGICAL FUNCTION isnull_myip(x) TYPE(my_iptr),INTENT(IN) :: x isnull_myip = ASSOCIATED(x%ptr) END FUNCTION END PROGRAM example2 TYPE(my_iptr) a PRINT *,.isnull.a END (4) If the program is not standard-conforming, would changing the penultimate line to "PRINT *,isnull_myip(a)" make it standard-conforming. ANSWER: (1) No, the requirement was not intentional. (2) Not applicable. (3) No, this was a mistake. (4) Not applicable. DISCUSSION: Usage of defined operations is intended to be equivalent to ordinary function references. All of the examples given above are standard-conforming. EDITS: [97:1] Replace "in an expression" with "of an intrinsic operation". {Only require operands to be defined for intrinsic operations.} [97:5] Replace "all of its components" with "it". {A structure may be referenced whenever it is defined.} HISTORY: 00-292 m154 Submitted; Passed by J3 meeting 00-329 m155 Failed J3 letter ballot WG5/N1452 Added answer to questions 2 and 4. 01-297 m158 Passed by J3 meeting 01-380 m158 Passed by J3 letter ballot, as amended WG5/N1451 Passed by WG5 ballot 01-Nov wg5 edits contained in corrigendum #2 {N1472} ---------------------------------------------------------------------- NUMBER: 000087 TITLE: MOD and MODULO intrinsic functions with zero divisor KEYWORDS: Intrinsic functions, MOD, MODULO DEFECT TYPE: Erratum STATUS: Included in corrigendum/complete QUESTION: Consider the programs: PROGRAM example1 PRINT *,MODULO(3,0) PRINT *,'Test succeeded' END PROGRAM example2 PRINT *,MOD(3,0) PRINT *,'Test succeeded' END Are these programs standard-conforming, and should "Test succeeded" be printed in each case? DISCUSSION: 13.14.74 says of MODULO: "If P=0, the result is processor dependent." 13.14.73 says of MOD: "If P=0, the result is processor dependent." It appears that example1 and example2 are equally conforming. INFORMATION: Out of 7 Fortran 90/95 compilers, with example1: 5 compiled it ok, 3 of these crashed it at runtime example2: 2 compiled it ok, both of these crashed it at runtime Out of 1 FORTRAN 77 compiler, example2 did not compile (error message). Note that section 7.1.7 [97:6-7] states "The execution of any numeric operation whose result is not defined by the arithmetic used by the processor is prohibited." This would seem to be contradictory, at least in spirit, to the definitions of MOD and MODULO. ANSWER: No, these programs were not intended to be standard-conforming. The processor should be allowed to optimise assuming that P is not zero. Edits are supplied to correct this mistake in the standard. EDITS: [3:32+] "(3) Earlier standards specified that if the second argument to MOD or MODULO was zero, the result was processor dependent. This standard specifies that the second argument shall not be zero." [257:30] Append "P shall not be zero." [257:32] Change "If P .ne. 0, the" to "The" [257:32-33] Delete "If P = 0, the result is processor dependent." [257:41] Append "P shall not be zero." [258:2] Delete "If P .ne 0," [258:4] Delete "If P = 0, the result is processor dependent." [258:5] Change "If P .ne. 0, the" to "The" [258:5-6] Delete "If P = 0, the result is processor dependent." SUBMITTED BY: Malcolm Cohen HISTORY: 00-325 m155 Passed unanimously as amended by J3 meeting 01-224r1 m157 Passed by J3 letter ballot WG5/N1451 Passed by WG5 ballot 01-Nov wg5 edits contained in corrigendum #2 {N1472} ---------------------------------------------------------------------- NUMBER: 000088 TITLE: INTRINSIC statement and attribute KEYWORDS: intrinsic DEFECT TYPE: Erratum STATUS: Included in corrigendum/complete QUESTION: Is it possible for a variable or external procedure that has the same name as the specific name of an intrinsic function listed in section 13.13 of the Fortran 95 standard and not marked with a bullet to be used as an actual argument? For example, consider the following program: module SCREEN type :: COLOR integer :: RED, GREEN, BLUE end type COLOR contains subroutine SET_BACKGROUND ( WHAT ) type(color), intent(in) :: WHAT ! Call to set the background color end subroutine SET_BACKGROUND end module SCREEN program TEST_SCREEN use SCREEN real, external :: DIM character(len=15) :: SIGN real :: SIN type(color) :: TAN = color(210,180,140) call color_intensity ( dim ) call biblical ( sign ) call cardinal ( sin ) call set_background ( tan ) end program TEST_SCREEN Notice that the actual arguments have the names of specific intrinsic functions listed in section 13.13 of the Fortran 95 standard, but they do not appear in an INTRINSIC statement, nor are they given the INTRINSIC attribute in a type declaration statement, as required by the penultimate normative paragraph of 12.3.2.3 of the Fortran 95 standard [198:7-9]. ANSWER: The answer to the question in the first paragraph is yes. Fortran has no reserved words. In the scope of the above main program, none of the names DIM, SIGN, SIN and TAN are names of intrinsic procedures. The paragraph referenced reads: If the specific name of an intrinsic function (13.13) is used as an actual argument, the name shall either appear in an INTRINSIC statement or be given the INTRINSIC attribute in a type declaration statement in the scoping unit. and tells us that SIN does not refer to the intrinsic procedure. The names DIM, SIGN, and TAN can be identified from their declarations not to be intrinsic procedures. Since none of the names are those of intrinsic procedures, the paragraph does not affect their use as the names of actual arguments. The edit makes the meaning clearer. EDITS: Page 198, Subclause 12.3.2.3, replace lines 7-9 of page 198 [198:7-9] by 'If a specific intrinsic function (13.13) is used as an actual argument, it shall have been explicitly declared to have the INTRINSIC attribute.' SUBMITTED BY: Van Snyder HISTORY: 00-249 m154 Submitted 01-136r1 m156 Passed unanimously by J3 meeting 01-224r1 m157 Passed by J3 letter ballot WG5/N1435 Passed by WG5 ballot 01-Nov wg5 edits contained in corrigendum #2 {N1472} ---------------------------------------------------------------------- NUMBER: 000089 TITLE: Rules allowing duplicate names KEYWORDS: generic, duplicate names DEFECT TYPE: Clarification STATUS: Included in corrigendum/complete QUESTION: Under what conditions can a name in class (1) as described in 14.1.2 be used in more than one declaration? The second complete paragraph after the list in 14.1.2, immediately before note 14.2 [276:5-7 in 97-007r2] begins: ``Within a scoping unit, a name that identifies a local entity of one class shall not be used to identify another local entity of the same class, except in the case of generic names (12.3.2.1).'' Is the intent here that a generic name may be used only to identify another generic interface, or that a generic name may be used to identify any other entity in class (1)? ANSWER: The rules are laid out in 12.3.2.1, which is referenced. The exceptional case is that a procedure is permitted to have the same specific and generic name. EDITS: None SUBMITTED BY: Van Snyder HISTORY: 00-246 m154 Submitted 01-137r1 m156 Passed unanimously by J3 meeting 01-224r1 m157 Passed by J3 letter ballot WG5/N1435 Passed by WG5 ballot 01-Nov wg5 no edits for corrigendum #2 => processing complete ---------------------------------------------------------------------- NUMBER: 000090 TITLE: What do ``Prior Specification'' and ``defined previously'' mean? KEYWORDS: initialization, prior specification, defined previously DEFECT TYPE: Erratum STATUS: Included in corrigendum/complete QUESTION 1 What is a ``prior specification?'' The last normative paragraph of section 7.1.6.1 of the Fortran 95 standard, immediately before note 7.14 [94:38-41 in 97-007r2] states: ``If an initialization expression includes a reference to an inquiry function for a type parameter or an array bound of an object specified in the same , the type parameter or array bound shall be specified in a prior specification of the . The prior specification may be to the left of the inquiry function in the same statement.'' The first two sentences of the last normative paragraph of section 7.1.6.2 of the Fortran 95 standard, immediately before note 7.16 [96:32-35 in 97-007r2] are similar, but refer to specification expressions. Unfortunately, there is no definition of ``prior specification.'' Consider: 1. INTEGER :: P(complicated_expression_for_lower_bound_1: & & complicated_expression_for_upper_bound_1, & & complicated_expression_for_lower_bound_2: & & complicated_expression_for_upper_bound_2) = & & RESHAPE( (/ 11, 21, 12, 22 /), SHAPE(P) ) (Notice the reference to P in the .) Some processors reason ``the `specification' of P is only the specification of its name, kind, rank and array bounds, and therefore is `prior' by the time the is encountered,'' and accept this. Others reason ``the `specification' of P is the syntax term defined by syntax rule R504 on page 47, which includes the , and it is therefore not `prior' until the is completely specified,'' and do not accept this. By way of further examples, which of the following are standard conforming? 2. INTEGER(selected_int_kind(4)) :: A(KIND(A)) 3. INTEGER :: A(2,2*SIZE(A,1)+1) 4. CHARACTER :: C(10)*(SIZE(C,1)) 5. INTEGER :: P(10) = LBOUND(P,1) The paragraphs cited above are silent concerning inquiry functions that are not for type parameters or array bounds. These include BIT_SIZE, DIGITS, EPSILON, MAXEXPONENT, MINEXPONENT, PRECISION, RADIX, RANGE and TINY. The results of all of these are derived, however, from the types and kind type parameters of their arguments. Are the objects about which these functions inquire required to be specified in a prior specification of the , and is that specification allowed to be in the same statement so long as it is to the left of the inquiry function of which it is an argument? Which of the following are standard conforming? 6. INTEGER :: B = BIT_SIZE(B) 7. INTEGER :: B(BIT_SIZE(B)) 8. INTEGER :: D = DIGITS(D) 9. INTEGER :: D(DIGITS(D)) 10. REAL :: X = EPSILON(X) One could construct obvious similar examples for the remainder of inquiry functions that do not inquire about type parameters or array bounds. QUESTION 2 The second normative paragraph in subclause 5.1.2.1 [52:27-28 in 97-007r2] states "Any named constant that appears in the initialization expression shall have been defined previously in the same type declaration statement...." The third normative paragraph after syntax rule R531 in subclause 5.2.9 [61:4-7 in 97-007r2] is similar. Does "defined previously" mean that all of the properties of the named constant shall have been defined previously, or that a referenced property of it shall have been defined previously? E.g. if the KIND is needed, is it necessary for the value to have been defined? ANSWER 1 A prior specification refers to a specification in a previous or in a previous statement. None of the examples are legal. Edits are included to clarify this. ANSWER 2 In the referenced text (5.1.2.1), "Any named constant that appears ... shall have been defined previously" mean that all of the properties of the named constant shall have been defined previously; therefore, if the KIND of a named constant is needed, is it necessary for the value of that named constant to have been defined previously also. EDITS: Page 94, Subclause 7.1.6.1. In the first line of the last paragraph of page 94 [94:38], replace 'for a type parameter' by 'that depends on a type parameter'. Page 94, Subclause 7.1.6.1, replace the last sentence of page 94 [94:40-41] by 'The prior specification may be to the left of the inquiry function in the same statement, but shall not be within the same .' Page 96, Subclause 7.1.6.2. In the first line of the last paragraph of the subclause [96:32], replace 'for a type parameter' by 'that depends on a type parameter'. Page 96, Subclause 7.1.6.2, replace the second sentence of the last paragraph of the subclause [96:34-35] by 'The prior specification may be to the left of the inquiry function in the same statement, but shall not be within the same .' SUBMITTED BY: Van Snyder HISTORY: 00-229 m154 Submitted 00-324 m155 Amended 01-138r1 m156 Passed by J3 meeting 01-224r1 m157 Passed by J3 letter ballot WG5/N1451 Passed by WG5 ballot 01-Nov wg5 edits contained in corrigendum #2 {N1472} ---------------------------------------------------------------------- NUMBER: 000091 TITLE: Definition of "present" is defective KEYWORDS: present, dummy argument DEFECT TYPE: Erratum STATUS: Included in corrigendum/complete QUESTION: Subclause 12.4.1.5 begins with a definition of the term "present": "A dummy argument is present in an instance of a subprogram if it is associated with an actual argument and the actual argument either is a dummy argument that is present in the invoking subprogram or is not a dummy argument of the invoking subprogram." This seems to be defective in that if the actual argument is a dummy argument that is accessed by host association, it is not a dummy argument OF the invoking subprogram, and therefore although it may be "not present" in the procedure of which it is a dummy argument, it is nonetheless "present" in an internal procedure of that procedure. Consider: module M contains subroutine S1 ( A ) integer, optional :: A call S11 contains subroutine S11 call S12 ( A ) end subroutine S11 subroutine S12 ( B ) integer, optional :: B if ( present(B) ) print *, 'B is present' end subroutine S12 end subroutine S1 end module M program P use M, only: S1 call S1 end program P Should this print "B is present" as implied by the above analysis? ANSWER: No, the program should not print anything. DISCUSSION: The lack of consideration of host association in the cited text is accidental; an edit is supplied to correct this oversight. EDITS: [202:43-45] Replace the first sentence of 12.4.1.5 by "A dummy argument or an entity that is host associated with a dummy argument is not <> if the dummy argument (1) is not associated with an actual argument, or (2) is associated with an actual argument that is not present. Otherwise, it is present." [299:4-6] Delete the glossary entry for <> SUBMITTED BY: Van Snyder HISTORY: 01-134 m156 Submitted 01-134r1 m156 Passed unanimously by J3 meeting 01-224r1 m157 Passed by J3 letter ballot WG5-N1395 Failed WG5 letter ballot WG5-N1463 Accept Kurt Hirchert's suggestion with minor edits 01-302 m158 Passed by J3 meeting 01-380 m158 Passed by J3 letter ballot WG5/N1470 Passed by WG5 ballot 01-Nov wg5 edits contained in corrigendum #2 {N1472} ---------------------------------------------------------------------- NUMBER: 000092 TITLE: Values of the PAD= Specifier in the INQUIRE Statement KEYWORDS: PAD=, INQUIRE DEFECT TYPE: Erratum STATUS: Included in corrigendum/complete QUESTION: The normative text of the Fortran 90 and Fortran 95 standards (9.6.1.22) specifies that the PAD= specifier in the INQUIRE statement returns the value YES if there is no connection or if the connection is for unformatted input/output. This behavior is different from the results of almost every other specifier for the INQUIRE statement if the property being inquired about is unknown or undefined. For those specifiers, the value returned in the specifier's variable is either UNKNOWN or UNDEFINED. Is the specified behavior of the PAD= specifier for an unformatted file or an unconnected unit intentional? ANSWER: No, this specification is in error. Edits are supplied to correct this defect. DISCUSSION: The concept of padding input records does not make any sense if the unit is connected for unformatted input/output or if the unit is not connected. A return value of YES does not reflect what is really going on. A return value of UNDEFINED is more appropriate in these situations. The normative text for this section in Fortran 95 is unchanged from Fortran 90, so correcting this defect is an incompatibility with Fortran 90. EDITS: [3:32+] Add the following list item to the list in section 1.5.1, "Fortran 90 compatibility". (3) The PAD= specifier in the INQUIRE statement in this standard returns the value 'UNDEFINED' if there is no connection or the connection is for unformatted input/output. The previous standard specified 'YES'. [159:40-41] Replace the second sentence of the paragraph in section 9.6.1.22 with the following. The in the PAD= specifier is assigned the value YES if the connection of the file to the unit included the PAD= specifier and its value was YES or if there was no PAD= specifier. If there is no connection or if the connection is not for formatted input/output, the is assigned the value UNDEFINED. [325:30] Change the entry in the table to: +--------+-----------+------------------------+-----------+ | PAD= | UNDEFINED | YES, NO, or UNDEFINED | UNDEFINED | +--------+-----------+------------------------+-----------+ SUBMITTED BY: Craig T. Dedo HISTORY: 01-172 m156 Passed unanimously by J3 meeting 01-224r1 m157 Passed by J3 letter ballot WG5/N1451 Passed by WG5 ballot 01-Nov wg5 edits contained in corrigendum #2 {N1472} ---------------------------------------------------------------------- NUMBER: 000093 TITLE: Allocatable arrays as actual arguments KEYWORDS: Allocatable array, actual argument DEFECT TYPE: Erratum STATUS: Included in corrigendum/complete QUESTION: There does not seem to be any requirement that an allocatable array be allocated for it to be used as an actual argument. Consider PROGRAM P ALLOCATABLE A(:,:) CALL S(A) CONTAINS SUBROUTINE S(X) DIMENSION X(:,:) PRINT *,SHAPE(X) END SUBROUTINE END Is this a standard-conforming program? If so, what does it print? ANSWER: No, this is not intended to be a standard-conforming program. An allocatable array must be allocated for it to be used as an actual argument, except where otherwise specified in the standard (e.g. for the ALLOCATED intrinsic function. An edit is supplied to clarify this intent. EDITS: [80:34] In item (1) in the list in clause 6.3.1.2, change "; it" to ". It shall not be supplied as an actual argument except to certain intrinsic inquiry functions. It" SUBMITTED BY: Malcolm Cohen HISTORY: 01-184 m156 Passed unanimously at J3 meeting 01-224r1 m157 Passed by J3 letter ballot WG5/N1435 Passed by WG5 ballot 01-Nov wg5 edits contained in corrigendum #2 {N1472} ---------------------------------------------------------------------- NUMBER: 000094 TITLE: NULL intrinsic in initialization expressions KEYWORDS: NULL intrinsic, initialization expressions DEFECT TYPE: Erratum STATUS: Included in corrigendum/complete QUESTION: Section 7.1.6.1 says that an initialization expression may contain "(6) A reference to the transformational intrinsic function NULL," with no constraints on its argument. Therefore PROGRAM EXAMPLE CALL SUB(42) CONTAINS SUBROUTINE SUB(N) CHARACTER(N),POINTER :: CP INTEGER,PARAMETER :: M = LEN(NULL(CP)) REAL,SAVE :: X(M) END SUBROUTINE END is apparently standard-conforming, but it is difficult to see how this can work in practice, particularly if SUB were called with different values for N. Should there not be some constraint on the argument of NULL in an initialization expression? ANSWER: Yes, a constraint is needed to force initialization expressions always to be constant. An edit is supplied to correct this oversight. EDITS: [94:12+] add to end of list item "where the argument is not of type character with a length that is assumed or defined by an expression that is not an initialization expression." SUBMITTED BY: Malcolm Cohen HISTORY: 01-211 m157 Submitted 01-211r1 m157 Passed by J3 meeting 01-275 m158 Passed by J3 letter ballot WG5/N1457 Passed by WG5 ballot 01-Nov wg5 edits contained in corrigendum #2 {N1472} ---------------------------------------------------------------------- NUMBER: 000095 TITLE: Names of functions, results and entry points KEYWORDS: function result, ENTRY DEFECT TYPE: Erratum STATUS: Included in corrigendum/complete QUESTIONS: Consider some examples of FUNCTION/RESULT/ENTRY combinations: (1) FUNCTION F() RESULT(F) This is not allowed ([207:8]). (2) ENTRY E() RESULT(E) This is also not allowed ([209:35]). (3) FUNCTION F() RESULT(R) ENTRY E() RESULT(R) This is allowed (implied by the sentence at [209:41-43]). (4) FUNCTION F() ENTRY E() RESULT(F) Does not appear to be disallowed, though why RESULT(F) should be prohibited on the FUNCTION statement but allowed on the ENTRY statement bemuses me. (5) FUNCTION F() RESULT(E) ENTRY E() Does not appear to be disallowed, though why RESULT(E) should be prohibited on the ENTRY statement but allowed on the FUNCTION statement bemuses me. (6) FUNCTION F() ENTRY E() RESULT(R) ENTRY G() RESULT(R) Appears to be (explicitly?) allowed. (7) FUNCTION F() ENTRY E() ENTRY G() RESULT(E) Does not appear to be disallowed, though why RESULT(E) should be prohibited on an ENTRY statement but allowed on another ENTRY statement bemuses me. (8) FUNCTION F() RESULT(R) ENTRY(R) RESULT(F) Does not appear to be disallowed, even though swapping the RESULT clauses would not be allowed. Q1. Is my analysis correct? If not, why? Q2. Does making the function RECURSIVE alter anything? Further, consider the following examples: (9) RECURSIVE FUNCTION F() RESULT(E) ENTRY E() RESULT(R) This appears to be allowed by the usual rules, but I find it hard to interpret "If RESULT is specified in the ENTRY statement and RECURSIVE is specified in the FUNCTION statement, the interface of the function defined by the ENTRY statement is explicit within the function subprogram." ([210:3-5]) (10) FUNCTION F() RESULT(R) ENTRY E() RESULT(F) This appears to be allowed by the usual rules, but I find it hard to interpret "If RESULT is specified, ... all occurrences of the function name in statements in the scoping unit are recursive function references." ([207:30-32]) Q3. Are these allowed? Come to think of it, in what way is passing the function name as an actual argument a "recursive function reference"? The text seems obviously broken whether these are allowed or not. Q4. Should the text be clarified? ANSWER: A1-A3. Only examples (3) and (6) were intended to be valid. A RESULT clause should only name an existing entity when that entity is also an explicitly specified RESULT variable. Edits are supplied to clarify this. A4. Yes, the text should be clarified. Edits are supplied to clarify and correct the text. EDITS: [207:8] Before "." insert "and shall not be the same as the in any ENTRY statement in the subprogram". [207:32] Change "are recursive function references" to "refer to the function itself". [209:35] Change "" to "the in the FUNCTION statement and shall not be the same as the in any ENTRY statement in the subprogram." SUBMITTED BY: Malcolm Cohen HISTORY: 01-285 m158 Submitted 01-285r1 m158 Passed by J3 meeting 01-380 m158 Passed by J3 letter ballot WG5/N1470 Passed by WG5 ballot 01-Nov wg5 edits contained in corrigendum #2 {N1472} ---------------------------------------------------------------------- NUMBER: 000097 TITLE: Open Scratch File Example KEYWORDS: Open statement, SCRATCH DEFECT TYPE: Erratum STATUS: Included in corrigendum/complete QUESTION: The first example in C.6.2 has the statement OPEN(UNIT=10, STATUS="SCRATCH", PAD="YES") to change the padding for a unit that is currently open. The 6th paragraph of 9.3.4 discusses the use of an OPEN statement where "the file to be connected to the unit is the same as the file to which the unit is connected". It says "If the STATUS= specifier is included in such an OPEN statement, it shall be specified with a value of OLD." Note this wording was introduced in f90 interp 186, which discusses it. The above-cited OPEN statement from C.6.2 appears to violate this requirement. Is the example in error? ANSWER: Yes, this is an error in the example. EDITS: [322:38] "SCRATCH" -> "OLD" HISTORY: 01-345 m158 Passed by J3 meeting 8-1 01-380 m158 Passed by J3 letter ballot WG5/N1470 Passed by WG5 ballot 01-Nov wg5 edits contained in corrigendum #2 {N1472} ---------------------------------------------------------------------- NUMBER: F90/000164 TITLE: Use of ONLY with multipart definitions KEYWORDS: ONLY, module, derived type DEFECT TYPE: Clarification STATUS: Included in corrigendum/complete QUESTION: Sections 11.3.1 and 11.3.2, among others, describe how accessibility of data objects, derived type definitions, etc. can be controlled via the ONLY clause of the USE statement and via the PUBLIC and PRIVATE accessibility attributes/statements. But these sections do not describe what happens when a definition consists of multiple parts and only some of the parts have their accessibility controlled. Examples include, but are not limited, to the following: Example 1: MODULE MOD INTEGER, PARAMETER :: MAX_SIZE = 100 INTEGER, DIMENSION(MAX_SIZE) :: ARRAY END MODULE PROGRAM MAIN USE MOD, ONLY: ARRAY ... END PROGRAM QUESTION 1a) Since the declaration of ARRAY depends on the value of MAX_SIZE, is it valid to only allow access to ARRAY? QUESTION 1b) Is the array constructor for ARRAY, for example, accessible to the main program? Example 2: MODULE MOD TYPE INNER INTEGER I END TYPE TYPE OUTER INTEGER K TYPE(INNER) COMP END TYPE END MODULE PROGRAM MAIN USE MOD, ONLY: OUTER ... END PROGRAM The derived type OUTER in module MOD has a component of derived type INNER. However, when the main program accesses the module, it restricts access to only derived type OUTER. QUESTION 2a) Since OUTER depends on the definition of INNER, is it valid to only allow access to OUTER? QUESTION 2b) If it is not valid, is it only an error if something in the main program actually tries to use OUTER? QUESTION 2c) Can you write a structure constructor for OUTER in the main program? QUESTION 2d) If it is valid, can component I of substructure COMP be referenced? Example 3: MODULE MOD TYPE DEF INTEGER K REAL R END TYPE TYPE(DEF) VAR END MODULE PROGRAM MAIN USE MOD, ONLY: VAR ... END PROGRAM In this example, only the variable VAR from the module is accessible; its type is not. QUESTION 3a) Is this (example 3) valid? QUESTION 3b) If it is valid, can only the structure name VAR be referenced or can its components also be referenced? QUESTION 3c) If only the structure name VAR can be referenced, what is the meaning when the structure name is included in a namelist object list for input and/or output? Example 4: MODULE MOD INTEGER, PARAMETER :: MAX_SIZE = 100 INTEGER, DIMENSION(MAX_SIZE) :: ARRAY PRIVATE MAX_SIZE END MODULE PROGRAM MAIN USE MOD ... END PROGRAM Another way to limit access to items in modules is via the PRIVATE attribute/statement. QUESTION 4a) Since the declaration of ARRAY depends on the value of MAX_SIZE, is it valid to only allow access to ARRAY? QUESTION 4b) Is the array constructor for ARRAY, for example, accessible to the main program? ANSWER: 1a) Yes, ARRAY is accessible, including its size (via the SIZE intrinsic), even though MAX_SIZE is not accessible. 1b) An array constructor of size 100 may be used in an assignment statement for ARRAY. 2a) Yes, it is valid to access only OUTER and declare objects of type OUTER. 2b) Not applicable. 2c) Yes, the structure constructor may be used in the main program. For example, TYPE(OUTER) X,Y X%COMP%I = 65 Y = OUTER(13,X%COMP) 2d) Yes, component I of component COMP may be referenced. 3a) Yes, there is no requirement that a type name be accessible for an entity of that type to be accessible. 3b) Both VAR and its components may be referenced. 3c) Not applicable. These questions were resolved by interpretation 85, which made a clarifying edit to 14.1.2.5. 4a) Yes, it is valid to allow access only to ARRAY. 4b) ARRAY is accessible, including its size (via the SIZE intrinsic), so an array constructor of size 100 may be used in an assignment statement for ARRAY. EDITS: None. SUBMITTED BY: Larry Rolison HISTORY: 94-038 m128 submitted 01-312r2 m158 Passed by J3 meeting 01-380 m158 Passed by J3 letter ballot WG5/N1470 Passed by WG5 ballot 01-Nov wg5 no edits for corrigendum #2 => processing complete ---------------------------------------------------------------------- NUMBER: F90/000190 TITLE: Subobjects of constants in a DATA statement KEYWORDS: DATA stmt, constant DEFECT TYPE: Interpretation STATUS: Included in corrigendum/complete QUESTION: Consider the following syntax rules from Section 5.2.9 of the Fortran 90 standard: R532 is [*] R533 is ... R534 is and the following constraint Constraint: A of a must involve as primaries only constants or DO variables of the containing s, and each operation must be intrinsic. In all cases, the rules reduce to "constant". The definition of "constant" is provided by R305: R305 is or R307 is The above two rules seem to indicate that if an identifier appears where "constant" is allowed in the DATA statement rules cited above, the identifier must be a name; that is, it can not be the subobject of a named constant. Is this analysis correct? ANSWER: Your analysis is correct for the Fortran 90 standard, but it is not correct for the Fortran 95 standard, which permits subobjects of named constants in these situations. The corresponding rules (page 62) are Constraint: A of a shall involve as primaries only constants, subobjects of constants, or DO variables of the containing s, and each operation shall be intrinsic. R539 is or R540 is or ... EDITS: None SUBMITTED BY: Larry Rolison HISTORY: 94-302 m131 submitted, with proposed response 94-360 m131 alternate answer proposed, failed 7-7 94-302 m131 original answer, approved 14-2 95-034 m132 X3J3 ballot failed 15-5 01-201 m157 Passed by J3 meeting 01-275 m158 Passed by J3 letter ballot WG5/N1457 Passed by WG5 ballot 01-Nov wg5 no edits for corrigendum #2 => processing complete ---------------------------------------------------------------------- NUMBER: F90/000191 TITLE: Interaction of SEQUENCE derived types and rename KEYWORDS: SEQUENCE, derived type, use association DEFECT TYPE: Interpretation STATUS: Included in corrigendum/complete QUESTION: Consider the following: MODULE M TYPE T SEQUENCE TYPE (T), POINTER :: P END TYPE END MODULE USE M, T2=>T TYPE T SEQUENCE TYPE (T2), POINTER :: P END TYPE TYPE (T) X TYPE (T2) Y X = Y END Section 4.4.2, 'Determination of derived types', seems to indicate that types T and T2 in the main program refer to the same type. Note that both types have structure components that agree in order, name, and attributes. However, considering type T in the context of module M only, type T is a derived type that contains one component that is a pointer to itself. In the context of the main program, type T is a derived type that contains one component that is a pointer to a different derived type. Are types T and T2 considered to be the same type? ANSWER: Yes, T and T2 are the same type. DISCUSSION: By the use of rename, it is possible for a scoping unit to have access by different local names to two separate derived-type definitions that have the same original name. Section 4.4.2 says: 'Data entities in different scoping units also have the same type if they are declared with reference to different derived-type definitions that have the same name,... '. This wording makes clear that it is the name of the derived-type definition (the original name) that is crucial when deciding whether two types are the same, rather than the local name of the type. This is confirmed in NOTE 4.32. EDITS: None. SUBMITTED BY: Janice C. Shepherd HISTORY: 94-273 m130 submitted 94-377 m131 Response submitted, approved u.c. 95-034r1 m132 X3J3 ballot failed 15-5 01-219 m157 Passed by J3 meeting 01-275 m158 Passed by J3 letter ballot WG5/N1457 Passed by WG5 ballot 01-Nov wg5 no edits for corrigendum #2 => processing complete ---------------------------------------------------------------------- NUMBER: F90/000196 TITLE: Inaccessibility of intrinsic procedures KEYWORDS: intrinsic procedure, INTRINSIC attribute, generic identifier, names class DEFECT TYPE: Clarification STATUS: Included in corrigendum/complete QUESTION: Note 14.2 states: "An intrinsic procedure is inaccessible in a scoping unit containing another local entity of the same class and having the same name. For example, in the program fragment SUBROUTINE SUB ... A = SIN (K) ... CONTAINS FUNCTION SIN(X) ... END FUNCTION SIN END SUBROUTINE SUB any reference to function SIN in subroutine SUB refers to the internal function SIN, not to the intrinsic function of the same name." Are the following two comments about this text correct? (1) The example is not strictly correct because the resolution of the procedure reference "SIN" depends on the contents of the first "...": (1a) If "..." does not contain an "INTRINSIC SIN" statement, the behavior is as specified: In SUB, the name SIN is established specific due to condition 14.1.2.4 part (2b), it is not established generic, and the internal function SIN is referenced due to 14.1.2.4.2 part (3). (1b) If "..." does contain an "INTRINSIC SIN" statement, SIN is established specific as above, but also established generic due to condition 14.1.2.4 (1b). So the reference is resolved according to 14.1.2.4.1 part (2): the intrinsic function SIN is called. ( At least if there is a suitable specific function for data ) ( object K. If not, the reference is resolved according to ) ( 14.1.2.4.1 (4) which also requires a consistent reference. ) (2) The first sentence of the cited text is wrong (incomplete), because it does not consider the case of generic identifiers: * Intrinsic procedures are local entities of class (1). * Generic identifiers are local entities of class (1). * Various instances in the standard indicate that it is possible to extend the generic interface of intrinsic procedures. Consequently, in the example MODULE my_sin CONTAINS LOGICAL FUNCTION lsin (x) LOGICAL, INTENT(IN) :: x ... END FUNCTION lsin END MODULE my_sin SUBROUTINE sub USE my_sin INTERFACE SIN MODULE PROCEDURE lsin END INTERFACE SIN ... END SUBROUTINE sub the intrinsic procedure SIN remains accessible in SUB although that scoping unit contains another local entity of class (1) named SIN. ANSWER: Comment 1a is correct. Comment 1b is incorrect. SIN is a local name for the internal procedure, which is a specific procedure, and adding an "INTRINSIC SIN" statement is prohibited by 14.1.2, 3rd paragraph. Comment 2 is correct. It should be remembered that notes are not normative (see 1.6.1) and are written in a less formal way than the text of the standard. DISCUSSION: Ordinarily, uses of intrinsic procedures are recognized automatically and require no explicit declaration, even if IMPLICIT NONE is in effect. However, if a scoping unit contains another local entity of the same class and having the same name as an intrinsic procedure, the automatic recognition of the intrinsic procedure is prevented, except in the case that the local entity and intrinsic procedure are both generic procedures. EDITS: None. SUBMITTED BY: Michael Hennecke HISTORY: 95-252 m135 submitted 95-281 m135 response WG5 approved (N1161) 96- m136 X3J3 ballot failed 16-0, possible error in 2nd edit, WG5 approval removed. Barber edit applied 01-221r1 m157 Passed by J3 meeting 01-275 m158 Passed by J3 letter ballot WG5/N1457 Passed by WG5 ballot 01-Nov wg5 no edits for corrigendum #2 => processing complete ---------------------------------------------------------------------- NUMBER: F90/000197 TITLE: Relationship of NEAREST and SPACING KEYWORDS: NEAREST, SPACING, "machine representable" DEFECT TYPE: STATUS: Included in corrigendum/complete QUESTION: The example in the SPACING intrinsic function description states: SPACING(3.0) has the value 2**(-22) for reals whose model is as at the end of 13.7.1. The example in the NEAREST intrinsic function description states: NEAREST(3.0, 2.0) has the value 3 + 2**(-22) on a machine whose representation is that of the model at the end of 13.7.1. Must the delta computed by NEAREST (the 2**(-22) shown in the example) be the value SPACING would return if given the same (first) argument as passed to NEAREST? ANSWER: No. DISCUSSION: The result of NEAREST depends on the characteristics of machine numbers, whereas the result of SPACING depends on the characteristics of model numbers. If there are one or more machine numbers in between two adjacent model numbers, the results of SPACING and NEAREST will not be consistent with each other. EDIT(S): None. SUBMITTED BY: Larry Rolison HISTORY: 95-030 m132 submitted WG5/N1404 Draft answer 00-260 m154 Passed by J3 meeting 00-329 m155 Passed by J3 letter ballot WG5/N1428 Passed by WG5 ballot 01-Nov wg5 no edits for corrigendum #2 => processing complete ---------------------------------------------------------------------- NUMBER: F90/000204 TITLE: Meaning of "same variable" description of MVBITS KEYWORDS: MVBITS DEFECT TYPE: Erratum STATUS: Included in corrigendum/complete QUESTION: Section 13.14.75 states "TO ... may be the same variable as FROM". Given the following statements, which pairs of variables are the same? INTEGER :: I(10), J(10) EQUIVALENCE (I,J) INTEGER, TARGET :: T(2:11) INTEGER, POINTER :: P1(:), P2(:) P1 => T P2 => T(2:11) I and I P1 and T I(1) and I(1) P1 and T(2:11) I(1:10) and I(1:10) P2 and T I(1:1) and I(1:1:-1) P2 and T(2:11) I and I(1:10) P1 and P2 I and J I(1) and J(1) I(1:10) and J(1:10) I(1:1) and J(1:1:-1) I and J(1:10) ANSWER: The quoted wording makes it clear that calls with the same name for FROM and TO, such as CALL MVBITS(DATA,2,2,DATA,0) ! Overwrite bits 0,1 by bits 2,3 are permitted. It was also intended that associated variables be permitted. The edits correct this. EDITS: In the second line of the final paragraph of subclause 12.7.3 [215:4], after 'may be the same variables', add 'and may be associated scalar variables or associated array variables all of whose corresponding elements are associated'. In subclause 13.14.75, in the second line of the paragraph that defines the effect of TO [258:21] change 'and may be the same variable as FROM' to 'and may be associated with FROM (12.7.3)'. SUBMITTED BY: /jor in response to IBM public comments HISTORY: 95-299 m135 submitted 01-220r1 m157 Passed by J3 meeting 01-275 m158 Passed by J3 letter ballot WG5/N1457 Passed by WG5 ballot 01-Nov wg5 edits contained in corrigendum #2 {N1472} ---------------------------------------------------------------------- NUMBER: F90/000205 TITLE: Restrictions on EXTERNAL KEYWORDS: EXTERNAL attribute, external subprogram DEFECT TYPE: Erratum STATUS: Included in corrigendum/complete QUESTION: Let the following two procedures not be contained within a main program, a module, or another subprogram. In this case they are <>s by the definitions of Fortran 95, section 2.2: SUBROUTINE subroutine_subprogram ( ) ! ... END SUBROUTINE subroutine_subprogram FUNCTION function_subprogram ( ) INTEGER :: function_subprogram ! ... END FUNCTION function_subprogram They are also external procedures, since F95 section 2.2.3.1 (and 12.1.2.2) states that "An <> is a procedure that is defined by an external subprogram or by means other than Fortran." External functions may be given the EXTERNAL attribute in form of an (R503), external procedures may be given the EXTERNAL attribute by an (R1208). QUESTION 1: Is it correct that the current definitions in F95 do allow the EXTERNAL attribute to be specified for the name of the external subprogram in which such a declaration is contained? In other words, is the following code standard-conforming? SUBROUTINE subroutine_subprogram ( ) EXTERNAL subroutine_subprogram ! ... END SUBROUTINE subroutine_subprogram FUNCTION function_subprogram ( ) INTEGER, EXTERNAL :: function_subprogram ! ... END FUNCTION function_subprogram QUESTION 2: If the answer to question 1 is YES: was this the intention, or should it be prohibited that an EXTERNAL attribute is given to the name of an external subprogram by declarations within that subprogram? ANSWER: 1. No, the EXTERNAL attribute may not be specified for the name of an external procedure defined by the subprogram, but this is not said explicitly. An edit is supplied to correct this. 2. Not applicable. DISCUSSION: The final paragraph of subclause 12.3.2.2 states [197:30-32] 'A name that appears in an EXTERNAL statement in a given scoping unit ... shall not also appear as a specific procedure name in an interface block in the scoping unit nor in an interface block that is accessible to the scoping unit.' The intention was to disallow the EXTERNAL attribute for a procedure with an explicit interface. Subclause 12.3.1 states [193:1-2]; 'The interface of a recursive subroutine or a recursive function with a separate result name is explicit within the subprogram that defines it.'. It was intended that the EXTERNAL attribute should not be permitted for these cases since the interface is explicit. Only in the cases mentioned in the previous paragraph may an external procedure name be used as a procedure name in the interior of the subprogram that defines it. In other cases, there would be no value in specifying the EXTERNAL attribute. EDITS: In subclause 12.3.2.2, add at the end of the first paragraph after R1208 [197:17] 'In an external subprogram, an EXTERNAL statement shall not specify the name of a procedure defined by the subprogram'. SUBMITTED BY: Michael Hennecke HISTORY: 96- m136 submitted WG5/N1404 Draft answer 00-260 m154 Passed by J3 meeting 00-329 m155 Failed J3 letter ballot 01-202 m157 Passed by J3 meeting 01-275 m158 Passed by J3 letter ballot WG5/N1457 Passed by WG5 ballot 01-Nov wg5 edits contained in corrigendum #2 {N1472} ---------------------------------------------------------------------- NUMBER: F90/000209 TITLE: STOP|PAUSE in I/O statement KEYWORDS: STOP, PAUSE DEFECT TYPE: Erratum STATUS: Included in corrigendum/complete QUESTION: Section 9.7. May a function referenced in an I/O statement execute a STOP or PAUSE statement? If STOP statements are permitted, what is the state of the file at the end of execution? ANSWER: (a) The PAUSE statement has been deleted from Fortran 95, so a standard-conforming program shall not contain such a statement. (b) No, a STOP statement may not be executed in this situation. Executing a STOP statement causes normal termination of execution, which closes all files (9.3.5), and this is equivalent to executing a CLOSE statement, which is prohibited by 9.7. A clarifying edit is supplied. EDITS: [160:20] after "statement" insert "or a STOP statement". SUBMITTED BY: Robert Paul Corbett HISTORY: submitted Mar. 13, 1996 (first appeared in 96-006r2) WG5/N1452 Suggested answers (two alternatives) 01-2931r1 m158 Passed by J3 meeting 01-380 m158 Passed by J3 letter ballot WG5/N1470 Passed by WG5 ballot, as amended 01-Nov wg5 edits contained in corrigendum #2 {N1472} ---------------------------------------------------------------------- NUMBER: F90/000211 TITLE: Multiple MODULE PROCEDURE specs KEYWORDS: MODULE PROCEDURE, generic interface, USE association DEFECT TYPE: Erratum STATUS: Included in corrigendum/complete WG5/N1176 (X3J3/96-007) says [194:21-23]: "Constraint: A in a shall not be one which previously had been specified in any with the same generic identifier in the same specification part." QUESTION: 1. Is it correct that this constraint does not preclude the following? MODULE foo1 INTERFACE generic_spec MODULE PROCEDURE proc1 END INTERFACE CONTAINS SUBROUTINE proc1 END SUBROUTINE proc1 END MODULE foo1 MODULE foo2 USE foo1 INTERFACE generic_spec MODULE PROCEDURE proc1 END INTERFACE END MODULE foo2 Although foo2 clearly violates the uniqueness conditions in 14.1.2.3, it seems that it does not violate a Constraint. (Actual compilers do not seem to detect this form of violation of 14.1.2.3 at compile-time.) 2. If the answer to (1) is YES, wouldn't it be sensible to extend that constraint to cases where a "previous" specification of in a with the same generic identifier in the specification part of an accessible module had occurred, _and_ that and generic-spec have PUBLIC accessibility? Probably the wording might be quite complicated because of the possibility of s if FOO1 and s in FOO2, but the essence should be straightforward... The situation in (1) is very similar to the following example, which _is_ detected as erroneous by the compilers I tried: MODULE foo1 CONTAINS SUBROUTINE proc1 END SUBROUTINE proc1 END MODULE foo1 MODULE foo2 USE foo1, ONLY: proc1 USE foo1, ONLY: proc2 => proc1 INTERFACE generic_spec MODULE PROCEDURE proc1 MODULE PROCEDURE proc2 END INTERFACE END MODULE foo2 In both cases, the specific s (and the ) are accessible in MODULE foo2, and the interfaces are explicit anyway. ANSWER: (1) Yes, this constraint does not apply to the example. Nor does 14.1.2.3, which only applies between pairs of specific procedures - there is only one specific procedure in this example. Note: However, processors are required to diagnose violations of the requirements of 14.1.2.3 - see 1.5 item 6. (2) Yes, the constraint should be fixed to prohibit the examples. Note: As it stands, the second example is not prohibited either by the constraint or by 14.1.2.3. EDITS: [194:21-23] Replace with "Constraint: A in a shall not specify a procedure that is specified previously in any in any accessible interface block with the same generic identifier." SUBMITTED BY: Michael Hennecke HISTORY: submitted Apr. 12, 1996 (first appeared in 96-006r2) WG5/N1452 Suggested answer (two alternatives) 01-294r1 m158 Passed by J3 meeting 01-380 m158 Passed by J3 letter ballot WG5/N1470 Passed by WG5 ballot 01-Nov wg5 edits contained in corrigendum #2 {N1472} ---------------------------------------------------------------------- NUMBER: F90/000212 TITLE: EQUIVALENCE of Data Objects of Different Types or Kinds KEYWORDS: EQUIVALENCE limitations DEFECT TYPE: Clarification STATUS: Included in corrigendum/complete Section 5.5.1 acknowledges that it is possible to construct equivalences between data objects of different types or kinds: "If equivalenced objects have differing type or type parameters, the EQUIVALENCE statement does not cause type conversion or imply mathematical equivalence." However, section 5.5.1 also has severe restrictions on equivalences between data objects of differing types and kinds. Following rule R547, there are a series of constraints. Constraints 3 through 6 read: Constraint: If an is of type default integer, default real, double precision real, default complex, default logical, or numeric sequence type, all of the objects in the equivalence set must be these types. Constraint: If an is of type default character or character sequence type, all of the objects in the equivalence set must be of these types. Constraint: If an is of a derived type that is not a numeric sequence or character sequence type, all of the objects in the equivalence set must be of the same type. Constraint: If an is of an intrinsic type other than default integer, default real, double precision real, default complex, default logical, or default character, all of the objects in the equivalence set must be of the same type with the same kind type parameter value. Question 1) Why are these constraints in the standard? What useful purpose do they serve? What problems do they prevent or solve? Question 2) Could a standard-conforming processor relax or eliminate one or more of these constraints, as an extension, without sacrificing full conformance to the standard? Question 3) Can a data object of sequence derived type be equivalenced to another data object of a different sequence derived type? Question 4) Assume that a processor has among its intrinsic types INTEGER (1) (8 bits), INTEGER (2) (16 bits), and INTEGER (4) (32 bits). Given the following definitions, is the EQUIVALENCE statement standard-conforming? TYPE T1 SEQUENCE INTEGER (1) I1_ARRAY (36) END TYPE TYPE T4 SEQUENCE INTEGER (4) I4_ARRAY (9) END TYPE TYPE (T1) OBJECT_1 TYPE (T4) OBJECT_4 EQUIVALENCE (OBJECT_1, OBJECT_4) Question 5) Can an object of sequence derived type be equivalenced to an array of intrinsic type? Question 5a) Assume the definitions of question 4. Is the following EQUIVALENCE statement standard conforming? INTEGER (4) :: I4_ARRAY_9 (9) EQUIVALENCE (OBJECT_1, I4_ARRAY_9) Question 6) Can an object of sequence derived type be equivalenced to a scalar of intrinsic type? ANSWER: Question 1: The constraints are there for portability (section 1.1) since different implementations may use different amounts of storage for these objects. Question 2: Such an extension is permitted, but the processor must provide the capability to detect this (see section 1.5). Question 3: Yes, a numeric sequence structure may be equivalenced to another numeric sequence structure and a character sequence structure may be equivalenced to another character sequence structure (see note 5.28). Question 4: No, this is not standard-conforming, because either INTEGER(1) or INTEGER(4) or both are non-default integers (see fourth constraint above). Question 5: Yes, a numeric sequence structure may be equivalenced to an array of default integer type, default real type, double precision real type, default complex type, or default logical type, and a character sequence structure may be equivalenced to an array of default character type (see note 5.28). Question 5a: No, this is not standard-conforming, because either INTEGER(1) or INTEGER(4) or both are non-default integers (see fourth constraint above). Question 6: Yes, a numeric sequence structure may be equivalenced to a scalar of default integer type, default real type, double precision real type, default complex type, or default logical type, and a character sequence structure may be equivalenced to a scalar of default character type (see note 5.28). EDITS: None SUBMITTED BY: Craig Dedo HISTORY: submitted Jan. 23, 1996 (first appeared in 96-006r2) WG5-N1456 draft answer 01-307 m158 Passed by J3 meeting 10-2 01-380 m158 Passed by J3 letter ballot WG5/N1470 Passed by WG5 ballot 01-Nov wg5 no edits for corrigendum #2 => processing complete ---------------------------------------------------------------------- NUMBER: JP-04 TITLE: Construction of derived-type values KEYWORDS: component, pointer, constructor DEFECT TYPE: Erratum STATUS: Included in corrigendum/complete QUESTION: JP-4) 4.4.4 Construction of derived-type values Before NOTE 4.34: "Where a component in the derived type is a pointer, the corresponding constructor expression shall evaluate to an object that would be an allowable target for such a pointer in a pointer assignment statement (7.5.2)." Change `an object' to `a result value'. A value of an expression can not be an object, by definition. ANSWER: An edit is required but the proposed edit is not quite correct, because the expression might yield a null pointer. EDITS: Replace [45:7-9] by "Where a component in the derived type is a pointer, the corresponding constructor expression shall be an allowable for such a pointer in a pointer assignment statement (7.5.2)." SUBMITTED BY: Japan HISTORY: 99-208 Submitted 99-221 Classed as Fortran 95 Interpretation. WG5-N1411 Draft answer 00-260 m154 Passed by J3 meeting 00-329 m155 Failed J3 letter ballot WG5-N1456 Accept Steidel's comment 01-308 m158 Passed by J3 meeting 01-380 m158 Passed by J3 letter ballot WG5/N1470 Passed by WG5 ballot 01-Nov wg5 edits contained in corrigendum #2 {N1472} ---------------------------------------------------------------------- NUMBER: JP-05 TITLE: Construction of array values KEYWORDS: constructor DEFECT TYPE: Interpretation STATUS: Included in corrigendum/complete QUESTION: JP-5) 4.5 Construction of array values, "The ac-do-variable of an ac-implied-do that is in another ac-implied-do shall not appear as the ac-do-variable of the containing ac-implied-do." This sentence should be a Constraint. ANSWER: No. The requirement should be made a constraint in the next standard. It should remain a simple requirement in Fortran 95 to avoid invalidating existing implementations. EDITS: None SUBMITTED BY: Japan HISTORY: 99-208 Submitted 99-221 Classed as Fortran 95 Interpretation. WG5-N1411 Draft answer 00-260 m154 Passed by J3 meeting 00-329 m155 Failed J3 letter ballot WG5-N1463 Accept Henry's and Jon's comments 01-303r1 m158 Passed by J3 meeting 01-380 m158 Passed by J3 letter ballot WG5/N1470 Passed by WG5 ballot 01-Nov wg5 no edits for corrigendum #2 => processing complete ---------------------------------------------------------------------- NUMBER: JP-06 TITLE: Type declaration statements KEYWORDS: Object name, Type declaration DEFECT TYPE: Erratum STATUS: Included in corrigendum/complete QUESTION: JP-6) 5.1 Type declaration statements As for the 16th and 19th constraint after R506: the 16th [48:25]: "Constraint: The function-name shall be the name of an external function, an intrinsic function, a function dummy procedure, or a statement function." Because the syntactic class `object-name' is only defined as a `name' in the standard, the following constraint should be added here: Constraint: The object-name shall be the name of a data object. [48:26+] After that, in the 19th [48:31]: "Constraint: initialization shall not appear if object-name is dummy argument, a dummy argument, a function result, an object in a named common block unless the type declaration is in a block data program unit, an object in blank common, an allocatable array, an external name, an intrinsic name, or an automatic object." In the above, `a function result,' should be removed. If we can not add the constraint above, `a statement function' should be added in the 19th constraint. DISCUSSION: There is a typographical error in the quoted 19th constraint in the question in that "dummy argument" appears twice. ANSWER: Yes, we agree that the constraint above should be added. However, the 19th constraint should not be modified since a function result is a data object that cannot be initialized. EDITS: [48:26+] Add: "Constraint: The object-name shall be the name of a data object." SUBMITTED BY: Japan HISTORY: 99-208 Submitted 99-221 Classed as Fortran 95 Interpretation. WG5-N1411 draft answer 01-151r1 m156 Passed unanimously by J3 meeting 01-224r1 m157 Passed by J3 letter ballot WG5/N1435 Passed by WG5 ballot 01-Nov wg5 edits contained in corrigendum #2 {N1472} ---------------------------------------------------------------------- NUMBER: JP-08 TITLE: Type declaration statements KEYWORDS: character length DEFECT TYPE: Erratum STATUS: Included in corrigendum/complete QUESTION: JP-8) 5.1 Type declaration statements After NOTE 5.3 [49:8]: "If a length-selector (5.1.1.5) is a nonconstant expression, ..." Change `length-selector' to `char-selector', `char-len-selector' or `character-length'. ANSWER: Agreed, but we think that "char-len-param-value" would be a better replacement text. EDITS: [49:9] Replace "" by "". SUBMITTED BY: Japan HISTORY: 99-208 Submitted 99-221 Classed as Fortran 95 Interpretation. WG5-N1411 Draft answer 00-260 m154 Passed by J3 meeting 00-329 m155 Failed J3 letter ballot WG5-N1456 Accept Zongaro's comment 01-309r1 m158 Passed by J3 meeting 01-380 m158 Passed by J3 letter ballot WG5/N1470 Passed by WG5 ballot 01-Nov wg5 edits contained in corrigendum #2 {N1472} ---------------------------------------------------------------------- NUMBER: JP-12 TITLE: Bounds of each dimension of an array pointer KEYWORDS: DEFECT TYPE: STATUS: Included in corrigendum/complete QUESTION: JP-12) 5.1.2.4.3 (2) after R518 (Page 55 Line 41) states that: "(2) They are specified in a pointer assignment statement. ..." In this description, the term "pointer assignment statement" should be changed to "pointer assignment". Reason : The bounds of each dimension of an array pointer may be specified not only in a pointer assignment statement but also in a derived-type intrinsic assignment statement with a component of an array pointer. ANSWER: Agreed EDIT: [55:41] Delete "statement" and replace "in a" with "by". SUBMITTED BY: Japan HISTORY: 99-208 Submitted 99-221 Classed as Fortran 95 Interpretation. WG5-N1411 Draft answer 00-260 m154 Passed by J3 meeting 00-329 m155 Passed by J3 letter ballot WG5/N1428 Passed by WG5 ballot 01-Nov wg5 edits contained in corrigendum #2 {N1472} ---------------------------------------------------------------------- NUMBER: JP-16 TITLE: Multiple occurrence of namelist-group-name in NAMELIST statement KEYWORDS: namelist DEFECT TYPE: Erratum STATUS: Included in corrigendum/complete QUESTION: JP-16) 5.4 2nd paragraph after R545 and constraints (Page 66 Line 11) states that: "Any namelist-group-name may occur in more than one NAMELIST statement in a scoping unit." Can a namelist-group-name occur more than once in one NAMELIST statement ? Is the following NAMELIST statement standard conforming ? NAMELIST /NLIST/ A, B /NLIST/ C, D If this is standard conforming, is it the same as the following ? NAMELIST /NLIST/ A, B, C, D ANSWER: Yes, the rules should be analogous to those for named common blocks at [69:16-19]. EDITS: [66:11] Replace "in more than one NAMELIST statement" by "more than once in the NAMELIST statements" SUBMITTED BY: Japan HISTORY: 99-208 Submitted 99-221 Classed as Fortran 95 Interpretation WG5-N1411 Draft answer 00-260 m154 Passed by J3 meeting 00-329 m155 Failed J3 letter ballot WG5-N1456 Accept Hirchert's comment 01-310r1 m158 Passed by J3 meeting 01-380 m158 Passed by J3 letter ballot WG5/N1470 Passed by WG5 ballot 01-Nov wg5 edits contained in corrigendum #2 {N1472} ---------------------------------------------------------------------- NUMBER: JP-31 TITLE: Signs of literal constants KEYWORDS: sign, literal DEFECT TYPE: Erratum STATUS: Included in corrigendum/complete QUESTION: JP-31) The fourth sentence of 10.8 and sixth sentence of 10.9: "Each value is either a null value or one of the forms: c r*c r* where c is a literal constant or a nondelimited character constant and r is an unsigned, nonzero, integer literal constant." "a literal constant" should be "an optionally signed literal constant" ANSWER: Add the phrase, "if integer or real" to that last phrase above. EDITS: [175:5] Replace "constant or" by "constant, optionally signed if integer or real, or" [178:40] Replace "constant and" by "constant, optionally signed if integer or real, and" Note for F2000: The phrase "literal constant" [73:34] in F95 is not the BNF term but F95 doesn't say if "literal constant" is signed. SUBMITTED BY: Japan HISTORY: 99-208 Submitted 99-221 Classed as Fortran 95 Interpretation. WG5-N1411 Draft answer 00-260 m154 Passed by J3 meeting 00-329 m155 Failed J3 letter ballot WG5-N1463 Update the edit 01-304 m158 Passed by J3 meeting 01-380 m158 Passed by J3 letter ballot WG5/N1470 Passed by WG5 ballot 01-Nov wg5 edits contained in corrigendum #2 {N1472}