ISO/IEC JTC1/SC22/WG5 N2004 Interps from F2008 Corrigendum 3 Stan Whitlock, 5-Jan-2014 Number Title F03/0030 IEEE divide by zero F03/0047 Polymorphic arguments to intrinsic procedures No edits F03/0053 The BIND attribute for C_PTR and C_FUNPTR F03/0064 Recursive declaration of procedure interfaces F03/0100 Error in field width for special cases of signed INFINITY output F03/0139 Functions returning procedure pointers F08/0071 Vector subscript target F08/0075 Pointer function reference as variable in assignment F08/0076 Pointer function reference in READ Subsumed by F07/0075 No edits F08/0083 Type parameter default expressions allow circular dependence F08/0084 Pointer arguments to PURE functions F08/0085 Problems with PARAMETERs F08/0086 Implied-shape and separate PARAMETER statement F08/0087 Mixed-kind character assignment F08/0088 Can ALLOCATE with SOURCE= have side-effects in a PURE proc? F08/0090 What restrictions apply to initialization and PARAMETER? F08/0091 Derived type with no components F08/0092 Derived type parameter requirements F08/0093 Process exit status and error termination F08/0094 Procedure statement and double colon F08/0095 Is PRESENT allowed in specification and constant expressions F08/0096 Is VALUE permitted for an array in a BIND(C) procedure? F08/0097 Is the optional comma allowed in TYPE(CHARACTER*...)? F08/0098 How many ACQUIRED_LOCK= specifiers are allowed in a LOCK stmt? ---------------------------------------------------------------------- NUMBER: F03/0030 TITLE: IEEE divide by zero KEYWORDS: IEEE-754, divide-by-zero DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 3 QUESTION: Is infinity / 0.0 a divide by zero exception? Is NaN / 0.0 a divide by zero exception? Fortran 2003 defines (in 14.2) infinity / zero and NaN / zero cases as IEEE_DIVIDE_BY_ZERO. IEEE-754 defines (in 6.1 and 6.2) those two as unexceptional. ANSWER: On an IEEE-conformant processor, these cases do not raise exceptions (see clauses 6.1 and 6.2 of IEC 60559:1989). The definitions in 14.2 were intended to describe IEC 60559:1989 exceptions with sufficient latitude to allow use on machines that do not conform to IEC 60559:1989. However, the definition of IEEE_DIVIDE_BY_ZERO is not consistent with IEC 60559:1989. Furthermore, the definition of the IEEE_OVERFLOW flag is also not consistent with IEC 60559:1989, because this exception is not raised for operations on infinite operands. Additionally, if the data type is not an IEEE data type, but the exception is supported, the circumstances under which the exception is raised are processor dependent. Edits are provided. EDITS to 10-007r1: [403:7-9] Clause 14.3, first paragraph, first bullet (IEEE_OVERFLOW), Replace with "IEEE_OVERFLOW occurs in an intrinsic real addition, subtraction, multiplication, division, or conversion by the intrinsic function REAL, as specified by IEC 60559:1989 if IEEE_SUPPORT_DATATYPE is true for the operands of the operation or conversion, and as determined by the processor otherwise. It occurs in an intrinsic real exponentiation as determined by the processor. It occurs in a complex operation, or conversion by the intrinsic function CMPLX, if it is caused by the calculation of the real or imaginary part of the result." [403:10-11] Clause 14.3, first paragraph, second bullet (IEEE_DIVIDE_BY_ZERO), Replace with "IEEE_DIVIDE_BY_ZERO occurs in a real division as specified by IEC 60559:1989 if IEEE_SUPPORT_DATATYPE is true for the operands of the division, and as determined by the processor otherwise. It is processor-dependent whether it occurs in a real exponentiation with a negative exponent. It occurs in a complex division if it is caused by the calculation of the real or imaginary part of the result." [462:24+] Clause A.2, after the fifth bullet from the end of the clause "the extent to which a processor supports IEEE arithmetic (14)", Insert new bullet points "- the conditions under which IEEE_OVERFLOW is raised in a calculation involving non-IEC 60559:1989 floating-point data; - the conditions under which IEEE_OVERFLOW and IEEE_DIVIDE_BY_ZERO are raised in a floating-point exponentiation operation; - the conditions under which IEEE_DIVIDE_BY_ZERO is raised in a calculation involving non-IEC 60559:1989 floating-point data;" SUBMITTED BY: Fred Tydeman HISTORY: 05-109 m171 F03/0030 submitted 05-109r1 m171 Revised to include IEEE_OVERFLOW, Passed by J3 meeting 05-170 m172 Passed J3 letter ballot #11 N1622 m172 Failed WG5 ballot N1629 10-238r1 m193 Revised answer - Passed J3 meeting 11-129 m194 Passed as amended by J3 letter ballot #22 10-254 11-006Ar1 m196 Adjust edits to reference 10-007r1 N1878 m196 Failed WG5 ballot 1 N1876 13-246 m200 Revised - passed by J3 meeting 13-262 m201 Passed J3 letter ballot #28 13-255r1 N1990 m202 Passed by WG5 ballot 6, N1988 N200x m203 In F2008 Corrigendum 3 ---------------------------------------------------------------------- NUMBER: F03/0047 TITLE: Polymorphic arguments to intrinsic procedures KEYWORDS: polymorphism, intrinsic procedures DEFECT TYPE: Interpretation STATUS: No edits in F2008 Corrigendum 3 QUESTION: The descriptions of the intrinsic procedures often use the term "type" without qualification. It is unclear whether they mean "declared type" or "dynamic type". If they mean "dynamic type", then this would appear to allow unlimited polymorphic arguments to intrinsic procedures like ABS and SIN. Resolution of generic intrinsic procedures in this case would create an undue (and likely unintended) burden on the processor, and the declared type of the result of such a function call would be unclear as well. Question 1: Are the arguments of the intrinsic functions ALLOCATED, ASSOCIATED, LBOUND, SHAPE, SIZE, and UBOUND permitted to be polymorphic? Question 2: (a) Is the ARRAY argument of the intrinsic function CSHIFT permitted to be polymorphic? If so: (b) If the argument is polymorphic, is the result polymorphic? What are the declared and dynamic types of the result? Question 3: (a) Are the ARRAY and BOUNDARY arguments of the intrinsic function EOSHIFT permitted to be polymorphic? If so: (b) If one of these arguments is polymorphic, then must the other be polymorphic? (c) Do the requirements on their types refer to their declared types or dynamic types? (d) If either argument is polymorphic, is the result polymorphic? What are the declared and dynamic types of the result? Question 4: (a) Are the A and MOLD arguments of the intrinsic function EXTENDS_TYPE_OF permitted to be polymorphic? If so: (b) If one of these arguments is polymorphic, must the other be polymorphic? (c) Do the requirements on their types refer to their declared types or dynamic types? Question 5: This question is deferred to interp F08/0102. (a) Are the TSOURCE and FSOURCE arguments of the intrinsic function MERGE permitted to be polymorphic? If so: (b) If one of these arguments is polymorphic, must the other be polymorphic? (c) Do the requirements on the types of the arguments refer to their declared types or dynamic types? (d) If either argument is polymorphic, is the result polymorphic? What are the declared and dynamic types of the result? Question 6: Are the FROM and TO arguments of the intrinsic function MOVE_ALLOC permitted to be polymorphic? Question 7: (a) Are the ARRAY and VECTOR arguments of the intrinsic function PACK permitted to be polymorphic? If so: (b) If one of these arguments is polymorphic, must the other be polymorphic? (c) Do the requirements on the types of the arguments refer to their declared types or dynamic types? (d) If either argument is polymorphic, is the result polymorphic? What are the declared and dynamic types of the result? Question 8: (a) Are the SOURCE and PAD arguments of the intrinsic function RESHAPE permitted to be polymorphic? If so: (b) If one of these arguments is polymorphic, must the other be polymorphic? (c) Do the requirements on the types of the arguments refer to their declared types or dynamic types? (d) If either argument is polymorphic, is the result polymorphic? What are the declared and dynamic types of the result? Question 9: (a) Are the A and B arguments of the intrinsic function SAME_TYPE_AS permitted to be polymorphic? If so: (b) If one of these arguments is polymorphic, must the other be polymorphic? (c) Do the requirements on their types refer to their declared types or dynamic types? Question 10: (a) Is the SOURCE argument of the intrinsic function SPREAD permitted to be polymorphic? If so: (b) If the argument is polymorphic, is the result polymorphic? What are the declared and dynamic types of the result? Question 11: (a) Is the SOURCE argument of the intrinsic function TRANSFER permitted to be polymorphic? (b) Is the MOLD argument of the intrinsic function TRANSFER permitted to be polymorphic? If the answer to (b) is yes: (c) If the MOLD argument is polymorphic, is the result polymorphic? What are the declared and dynamic types of the result? Question 12: (a) Is the MATRIX argument of the intrinsic function TRANSPOSE permitted to be polymorphic? If so: (b) If the argument is polymorphic, is the result polymorphic? What are the declared and dynamic types of the result? Question 13: (a) Are the VECTOR and FIELD arguments of the intrinsic function UNPACK permitted to be polymorphic? If so: (b) If one of these arguments is polymorphic, must the other be polymorphic? (c) Do the requirements on the types of the arguments refer to their declared types or dynamic types? (d) If either argument is polymorphic, is the result polymorphic? What are the declared and dynamic types of the result? Question 14: Are any of the other arguments of any intrinsic procedure permitted to be polymorphic? ANSWER: The assertion that it is unclear whether "type" means declared, dynamic, or both, is misguided. The general rule is that wherever it makes sense, it means both. Where only one meaning makes sense, it means that one. Where only one meaning is intended but it would otherwise not be clear from context, it is qualified as "declared type" or "dynamic type". Answer 1: Yes. Answer 2: (a) Yes. (b) Yes. "The result is of the type ... of ARRAY". Answer 3: (a) Yes. (b) No. (c) The requirements apply to both the declared type and the dynamic type. (d) "The type has ... the type ... of ARRAY". Therefore it is polymorphic if ARRAY is polymorphic. Answer 4: (a) Yes. (b) No. (c) The requirements refer to the declared type; this is explicitly stated. Answer 5: This question has been deferred to interp F08/0102 TSOURCE and FSOURCE are required have the same declared type, but may be polymorphic. The questions of what the requirements are on the dynamic type, and whether the result is polymorphic, are deferred to interp F08/0102. Answer 6: Yes. Answer 7: (a) Yes. (b) No. (c) The requirements refer to both the declared type and the dynamic type. Note that this means that if either ARRAY or VECTOR is not polymorphic, the requirement for type matching means that the dynamic type of the polymorphic argument is known. (d) The result "has the same type" as ARRAY, and therefore is polymorphic if ARRAY is polymorphic. Answer 8: (a) Yes. (b) No. (c) The requirements refer to both the declared type and the dynamic type. (d) The result "has the same type" as SOURCE, and therefore is polymorphic if and only if SOURCE is polymorphic. Answer 9: (a) Yes. (b) No. (c) The requirements are explicitly stated to refer to the declared type. Answer 10: (a) Yes. (b) Yes. "The result is ... of the same type ... as ARRAY.". Answer 11: (a) Yes. (b) Yes. (c) "The result is of the same type ... as MOLD.". Answer 12: (a) Yes. (b) Yes. The declared and dynamic types of the result are those of the argument. Answer 13: (a) Yes. (b) Yes. (c) The requirements refer to both the declared type and the dynamic type. (d) Yes. The result has the same declared and dynamic types as VECTOR, and is polymorphic if and only if VECTOR is polymorphic. Answer 14: Yes. For example, IMAGE_INDEX, LCOBOUND, PRESENT, STORAGE_SIZE, and UCOBOUND. EDITS: None. SUBMITTED BY: Rob James HISTORY: 05-138 m171 F03/0047 submitted - contained the questions/answers 05-138r1 m171 Contained the edits, passed by J3 meeting 05-170 m172 Passed J3 letter ballot #11 N1622 m172 Failed WG5 ballot N1629 13-242 m200 Revised - passed by J3 meeting 13-262 m201 Passed J3 letter ballot #28 13-255r1 N1990 m202 Passed as amended by WG5 ballot 6, N1988 ** Q5 was deferred to F08/0102; A2(b) and A13(d) were modified N200x m203 No edits in F2008 Corrigendum 3 ---------------------------------------------------------------------- NUMBER: F03/0053 TITLE: The BIND attribute for C_PTR and C_FUNPTR KEYWORDS: BIND attribute, C_PTR, C_FUNPTR, private components DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 3 QUESTION: 1. Do the derived types C_PTR and C_FUNPTR have the BIND attribute? This affects whether an object of one of these types is permitted directly in COMMON. C5101 in the Fortran 2008 standard states "If a common-block-object is of a derived type, it shall be a sequence type or a type with the BIND attribute and it shall have no default initialization." 2. Whether the derived types C_PTR and C_FUNPTR have the BIND attribute affects whether they are extensible. Subclause 4.5.7.1 of the Fortran 2008 standard states "A nonsequence derived type that does not have the BIND attribute is an extensible type." Are these types extensible? 3. Subclause 15.3.3 of the Fortran 2008 standard states that C_PTR and C_FUNPTR are derived types with private components. Are user-defined derived types with the BIND attribute permitted to have private components? ANSWER: 1. No, these types do not have the BIND attribute. 15.3.3 does not specify that they have the BIND attribute. 15.3.4 does not require them to have the BIND attribute in order to make them interoperable. 15.3.5 would require them to interoperate with a C struct if they had the BIND attribute; this is absurd, since C object pointers and C function pointers are clearly not structs. Note that whether these types have default initialization is not specified by the standard, so possession of BIND would not necessarily have allowed them in COMMON anyway. Edits are provided to correct incomplete, and thus misleading, statements about derived types and the BIND attribute. 2. No, these types were not intended to be extensible. It was an oversight that these types were not explicitly excluded from being extensible by subclause 4.5.7.1 paragraph 1 of the Fortran 2008 standard. An edit is provided to correct this. 3. Yes, a user-defined derived type with the BIND attribute is permitted to have private components. This situation is the same as for SEQUENCE types, which are similar (but not interoperable). As with SEQUENCE types, making a component PRIVATE does prevent access, in a conforming program, to the component by a programmer who is sufficiently determined; however, it continues to fulfill the software engineering role for which it was intended. Note further that there are many other situations where two different Fortran derived types will interoperate with the same C derived type; this is not a defect in either standard, but simply a consequence of the two languages having different approaches to type compatibility. EDITS to 10-007r1: [19:15-16] In 1.3.147.6, replace the definition of "extensible type" with "type that may be extended using the EXTENDS clause (4.5.7.1)". {Repair definition of extensible type.} [77:3] In 4.5.7.1p1, After "A derived type" insert ", other than the type C_PTR or C_FUNPTR from the intrinsic module ISO_C_BINDING," {Prohibit these types from subsequent extension.} [431:6] In 15.3.4p1, replace the first sentence with "Interoperability between derived types in Fortran and struct types in C is provided by the BIND attribute on the Fortran type." {Reduce misleading opening blather - this is just here so we didn't start the subclause with a bunch of constraints. Alternatively we could move paragraph 2 (and note 15.12) to replace paragraph 1.} [431:12+2] In 15.3.4, Note 15.11, After "is interoperable" insert "with a C struct type". {Correct another misleading sentence.} [431:13-18] In 15.3.4p2, Change all four occurrences of "Fortran derived type" to "derived type"; change the single occurrence of "Fortran type" to "derived type". {Remove unnecessary and confusing qualification of "derived type" with "Fortran".} SUBMITTED BY: John Reid HISTORY: 05-151 m171 F03/0053 submitted - Passed by J3 meeting 05-170 m172 Passed J3 letter ballot #11 N1622 m172 Failed WG5 ballot N1629 11-217r1 m195 Revised answer for Fortran 2008 - Passed by J3 meeting 11-241 m196 Passed as amended by J3 letter ballot #24 11-229 12-165r2 m198 Passed by J3 letter ballot #25 12-147 12-193 m199 Failed WG5 ballot #3 N1932/N1933/N1939 12-190 m199 Revised answer/edits - passed by J3 meeting 13-237 m200 Passed as amended by J3 letter ballot #27 13-203 N1990 m202 Passed by WG5 ballot 6, N1988 N200x m203 In F2008 Corrigendum 3 ---------------------------------------------------------------------- NUMBER: F03/0064 TITLE: Recursive declaration of procedure interfaces KEYWORDS: procedure, interface DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 3 QUESTION: Q1. Consider the following program: PROGRAM foo PROCEDURE(sub) :: p INTERFACE SUBROUTINE sub(p2) IMPORT p PROCEDURE(p) :: p2 END SUBROUTINE END INTERFACE END PROGRAM C1216 appears to prohibit the case of an interface name in a procedure declaration statement being the name of something declared in a later procedure declaration statement. But it does not appear to prohibit the case of an interface name being the name of something declared in a later interface body. In the above program, the characteristics of p rely on the characteristics of sub. The characteristics of sub, in turn, rely on the characteristics of p. Is this program standard-conforming? Q2. Consider the module MODULE m1 CONTAINS SUBROUTINE s(p) PROCEDURE(s) :: p END SUBROUTINE END MODULE Constraint C1216 does not apply here since "s" is not declared by a procedure declaration statement; unlike Q1, it is also not declared by an interface body. However, the characteristics of S have not been determined before the procedure declaration statement has been processed, and that cannot be processed until we know what the interface of S is. Is this program unit standard-conforming? Q3. Consider the module MODULE m2 CONTAINS SUBROUTINE s1(a) PROCEDURE(s2) :: a END SUBROUTINE SUBROUTINE s2(b) PROCEDURE(s1) :: b END SUBROUTINE END MODULE The interface of A depends on the interface of S2, which depends on the characteristics of B, which depends on the characteristics of S1, which depends on the characteristics of A; a circular dependency. Is this program unit standard-conforming? Q4. Consider MODULE m3 PROCEDURE(s),POINTER :: sptr CONTAINS SUBROUTINE s(p) PROCEDURE(sptr) :: p END SUBROUTINE END MODULE In the normal course of events there is no problem declaring a procedure pointer to have the interface of a module procedure that is defined later, and this is desirable, but in this case there seems to be a circular dependency between the characteristics of sptr, s, and p. Is this program unit standard-conforming? ANSWER: None of the examples are standard-conforming, as the standard does not establish an interpretation for them. An edit is provided to clarify this. EDIT to 10-007r1: [288:3] 12.4.3.6p2, append new sentence "The interface specified by shall not depend on any characteristic of a procedure identified by a in the of the same procedure declaration statement." SUBMITTED BY: Rob James HISTORY: 05-179 m172 F03/0064 submitted 05-226 m173 Passed by J3 meeting 06-133 m175 Failed J3 letter ballot #12 09-149 m187 Passed by J3 meeting 09-187r2 m188 Failed J3 letter ballot #18 09-155 13-245 m200 Revised - passed by J3 meeting 13-262 m201 Passed J3 letter ballot #28 13-255r1 N1990 m202 Passed by WG5 ballot 6, N1988 N200x m203 In F2008 Corrigendum 3 ---------------------------------------------------------------------- NUMBER: F03/0100 TITLE: Error in field width for special cases of signed INFINITY output KEYWORDS: formatted output, signed infinity DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 3 QUESTION: Is there an error in the description for the output of a IEEE infinity with a sign and a field width of 3 or 8? Fortran 2008, 10.7.2.3.2 paragraph 7, [252:33-34], describes the output of IEEE infinities; this specifies asterisks (field overflow) if the field width is less than 3, and omission of "inity" if the field width is less than 8. However, this does not take into account the fact that there might be a plus or minus sign in the field. The current text also fails to take into account the case of = 0, for both Infinity and NaN values. ANSWER: Yes, there is an error in the special cases. Edits are provided to correctly describe the required field widths for signed infinities. An edit is also provided to repair the description of the output of NaN values. EDITS to 10-007r1: [252:33-34] 10.7.2.3.2p7, Replace "If is ... produced." with "The minimum field width required for output of the form 'Inf' is 3 if no sign is produced, and 4 otherwise. If is greater than zero but less than the minimum required, the field is filled with asterisks. The minimum field width for output of the form 'Infinity' is 8 if no sign is produced and 9 otherwise. If is greater than or equal to the minimum required for the form 'Infinity', the form 'Infinity' is output. If is zero or is less than the minimum required for the form 'Infinity' and greater than or equal to the minimum required for the form 'Inf', the form 'Inf' is output. Otherwise, the field is filled with asterisks." [252:37] Same subclause, p8, Replace "If ... askerisks." with "If is greater than zero and less than 3, the field is filled with asterisks. If is zero, the output field is 'NaN'.". SUBMITTED BY: Dick Hendrickson HISTORY: 07-271 m181 F03/0100 submitted 07-271r2 m181 Passed by J3 meeting 07-321 m182 Failed J3 letter ballot #14 07-279 07-340r1 m182 Passed by J3 meeting 08-133r2 m183 Passed by letter ballot #15 08-101 08-164 m184 Failed WG5 ballot #5 N1722-N1726 13-247 m200 Revised - passed by J3 meeting 13-262 m201 Passed as amended by J3 letter ballot #28 13-255r1 N1990 m202 Passed by WG5 ballot 6, N1988 N200x m203 In F2008 Corrigendum 3 ---------------------------------------------------------------------- NUMBER: F03/0139 TITLE: Functions returning procedure pointers KEYWORDS: procedure pointer DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 3 QUESTION: (1) Is a function permitted to return a procedure pointer? Much of the language talks about the function result variable, but a procedure pointer is not a variable. For example, 2.2.3 says [12:16] "The VARIABLE that returns the value of a function is called the RESULT VARIABLE." (emphasis mine); which indicates that the value of a function is returned in a variable. (2) Where may a function reference that returns a procedure pointer appear? In particular, (a) as a in a SELECT TYPE or an ASSOCIATE statement; (b) within parentheses as a primary; (c) as the argument to an intrinsic inquiry function such as KIND or LEN. (3) [12:18-19] says "a subroutine may be used to change the program state by changing the values of any of the data objects accessible to the subroutine". A procedure pointer is not a data object, so is this meant to imply that a subroutine is not permitted to change the state of a procedure pointer? Similar text for functions appears in the same paragraph. ANSWER: (1) Yes, a function is permitted to return a procedure pointer; the text calling this a variable is in error. Edits are supplied to correct these mistakes. (2) It was intended that a function reference that returns a procedure pointer only be permitted as an argument to the ASSOCIATED and NULL intrinsic functions and in places where an ordinary procedure name would be acceptable. Parentheses around a pointer act to dereference the pointer and return a copy of the value: this action is inapplicable to procedures. Thus the answers to the specific sub-questions are No, No, and No again. Clarifying edits are provided. (3) No, this implication is not intended. A clarifying edit is provided. EDITS for (1b): [10:33+] Insert new term after "1.3.77 <>" "1.3.77a <> entity that returns the value of a function". [15:31-33] Delete term 1.3.121 <>. [52:2] 4.3.1.2p2, after "function result" delete "variable". [58:23] 4.4.3.2p5, "result variable in the function" -> "function result". [87:9] 5.1p2 "its result variable" -> "the function result". [109:24] 5.5p4, "name of the result variable of that function subprogram" -> "result of that function". {Function *subprogram*s do not have results, the function specified by the FUNCTION statement does, as do the ones defined by the ENTRY statements, but the subprogram is just syntax.} [112:15] 5.7.1.1 C587, "result variable" -> "function result". [114:22] 5.7.2.1 C5100, "result variable" -> "function result". [130:26] 6.7.3.2p2, after "function result" delete "variable". [278:11] 12.3.1 "result value"->"function result". {Reads a bit awkwardly, but it is important to use the correct terms and to be consistent with 12.3.3 (which does) otherwise this is undefined meaningless blather.} [307:5,9] 12.6.2.2p3, "result variable" -> "function result", twice. [307:12,14,15] p4, "result variable" -> "function result", thrice. [307:15-16] Delete "The characteristics ... variable.". [307:16-17] "its result variable." -> "its function result." [307:17] "is a pointer" -> "is a data pointer". [307:18,18,20] "result variable" -> "function result", thrice. [307:20+2] NOTE 12.41, "The ... subprogram." -> "The function result is similar to any other entity (variable or procedure pointer) local to the function subprogram.". [307:20+4] "this variable" -> "this entity". [307:20+5] "that variable" -> "that entity". [309:23,24] 12.6.2.5p3, "result variable name" -> "name of the function result", twice. [310:2] 12.6.2.6p3, after "name of its result" delete "variable". [310:2-3] Delete "The characteristics ... the result variable.". [310:5-6] "result variables identify the same variable" -> "result names identify the same entity" and delete ", although their names need not be the same". [310:6] "scalars" -> "scalar variables". [314:3] After "The result" delete "variable". [433:7] "result variable is a scalar"->"result is a scalar variable". [441:7,10] 16.3.1p4, "result variable" -> "function result", twice. [441:18-20] 16.3.3p1, "result variable" -> "function result", thrice. [449:3-4] 16.5.3.1p1 "result variables" -> "function results that are variables". [450:20] 16.5.3.4p6, "result variables" -> "function results that are variables". [456:11] 16.6.6p1, item (15)(e), "the result variable of a function" -> "a variable that is the function result of that procedure" {Also fixes all function results becoming undefined when a single procedure is invoked!} EDITS for (2b). [133:26+] Insert new constraint "C702a (R701) The shall not be a function reference that returns a procedure pointer." [170:23+] Insert new constraint "C804a (R805) The shall not be a function reference that returns a procedure pointer." [316:12+] 13.2.1 after p6, insert new paragraph "An argument to an intrinsic procedure other than ASSOCIATED, NULL, or PRESENT shall be a data object." EDITS for (3). [30:28] After "data objects" insert "or procedure pointers". SUBMITTED BY: Malcolm Cohen HISTORY: 09-295 m190 F03/0139 submitted - Passed by J3 meeting: B answers passed 10-105 m191 Passed as amended by J3 letter ballot #20 09-307 N1816 m191 Failed WG5 ballot #7 {N1805/6} - interp updated - see 10-135r1 13-249 m200 Revised - passed by J3 meeting 13-262 m201 Passed as amended by J3 letter ballot #28 13-255r1 N1990 m202 Passed as amended by WG5 ballot 6, N1988 ** Add extra edit to [307:16-17]; change the edit for [433:7] N200x m203 In F2008 Corrigendum 3 ---------------------------------------------------------------------- NUMBER: F08/0071 TITLE: Vector subscript target KEYWORDS: Pointer assignment, Vector subscript DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 3 QUESTION: Consider PROGRAM m197006 REAL,TARGET :: x(100) = [ (i,i=1,100) ] REAL,POINTER :: p(:) TYPE t REAL,POINTER :: q(:) END TYPE TYPE(t) y p => x ! (1) y = t(x) ! (2) p => x( [ 1,4,9,25 ] ) ! (3) y = t(x( [ 1,4,9,25 ] )) ! (4) PRINT *,y%q END PROGRAM The pointer assignment statement at (1) associates P with X. The intrinsic assignment statement at (2) includes the effect of pointer assignment of X to Y%Q, but is not a pointer assignment statement. The pointer assignment statement at (3) is not standard-conforming according to 6.5.3.3.2 paragraph 2: "An array section with a vector subscript shall not be ... the in a pointer assignment statement" However, the intrinsic assignment statement at (4) is not subject to this requirement as it is not a pointer assignment statement. Note that the quoted paragraph is entirely duplicative, as in: - the first bullet item is covered by 12.5.2.4p18, - the second bullet item is covered by C724 in 7.2.2.2 (but C724 does not cover this case either), - the third bullet item is covered by C901 in 9.5.1. Editorial improvements have been made in corrigendum 1. The entire paragraph has been rewritten. Q1. Was the statement marked (4) intended to be allowed? Q2. If not, was it intended to be prohibited by a constraint like C724, or was it intended to be a simple requirement? (Editorial note: in any case surely the requirement should appear in the pointer assignment subclause.) ANSWER: A1. No, this was not intended. An edit is supplied to correct this. A2. Constraint C724 was intended to cover this case. An edit is supplied to correct this. EDIT: [158:19-20] In 7.2.2.2 Syntax of the pointer assignment statement, C724, change ""(R737) A " to "A variable that is a pointer target", making the whole constraint read: "A variable that is a pointer target shall have either the TARGET or POINTER attribute, and shall not be an array section with a vector subscript." {Make the constraint apply to all forms of pointer assignment.} {Notice that this edit incorporates the list item concerning vector subscripts from 6.5.3.3.2p2 status quo ante corrigendum 1.} SUBMITTED BY: Malcolm Cohen HISTORY: 12-121 m197 F08/0071 submitted 12-121r1 m197 Revised wording with same edits - passed by J3 meeting 12-165r2 m198 Failed J3 letter ballot #25 12-147 13-250 m200 Revised - passed by J3 meeting 13-262 m201 Passed J3 letter ballot #28 13-255r1 N1990 m202 Passed by WG5 ballot 6, N1988 N200x m203 In F2008 Corrigendum 3 ---------------------------------------------------------------------- NUMBER: F08/0075 TITLE: Pointer function reference as variable in assignment KEYWORDS: Pointer function, assignment, defined operator DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 3 QUESTION: (1) Consider the following module Funcs interface operator ( .op. ) module procedure Unary, Binary end interface contains function Unary ( Arg ) integer, intent(in) :: Arg integer, pointer :: Unary ... end function Unary function Binary ( Arg1, Arg2 ) integer, intent(in) :: Arg1, Arg2 integer, pointer :: Binary ... end function Binary end module Funcs program What use Funcs integer :: X, Y = 42 10 .op. x = y end program What Is the "10" in "10 .op. x = y" an operand, and therefore an argument of a reference to Binary, or is .op. a reference to Unary and "10" a statement label? (2) Consider the following module Funcs interface operator ( .op. ) module procedure Unary, Binary end interface contains function Unary ( Arg ) integer, intent(in) :: Arg character(len=...), pointer :: Unary ... end function Unary function Binary ( Arg1, Arg2 ) integer, intent(in) :: Arg1, Arg2 character(len=...), pointer :: Binary ... end function Binary end module Funcs program What use Funcs integer :: X = 42, Y read (10) .op. x, y end program What Is "10" an , or is "(10) .op. x" a ? Note that this program is valid Fortran 90, and "(10) .op. x" is a according to the Fortran 90 standard. ANSWER: It was an oversight that the programs in (1) and (2) conform to the syntax and constraints in two different ways. The problem stems from the over-ambitious extension of allowing pointer function references to denote variables; this was unambiguous for syntax, but is not for operator syntax. Also, operator syntax has other restrictions on it that are intended to prevent modification of an operand, and these are subverted if the result is treated as a variable. Edits are supplied to remove the treatment of pointer-valued operators as variables. EDITS: [117:13] In 6.2, R602, change "" to "". [117:15] In 6.2, C602, change " ... has" to " shall have". [158:18+] In 7.2.2.2, R737, add new production "<> ". {Restore description of to F2003 version.} [158:20+] In 7.2.2.2, After C724, add new constraint "C724a (R737) An shall be a reference to a function that has a data pointer result." {Restore F2003 constraint (more or less).} SUBMITTED BY: Van Snyder HISTORY: 12-149 m198 F08/0075 submitted 12-149r1 m198 Revised edit 12-149r2 m198 Clarified answer, passed J3 meeting 12-196 m199 Subsumed F08/0076 and Failed J3 letter ballot #26, 12-184 12-197 m199 Revised answer/edits - passed by J3 meeting 13-237 m200 Passed by J3 letter ballot #27 13-203 N1990 m202 Passed by WG5 ballot 6, N1988 N200x m203 In F2008 Corrigendum 3 ---------------------------------------------------------------------- NUMBER: F08/0076 TITLE: Pointer function reference in READ KEYWORDS: Pointer function reference, READ, defined operator DEFECT TYPE: Erratum STATUS: Subsumed by F08/0075 - No edits in F2008 Corrigendum 3 QUESTION: Consider the following module Funcs interface operator ( .op. ) module procedure Unary, Binary end interface contains function Unary ( Arg ) integer, intent(in) :: Arg character(len=...), pointer :: Unary ... end function Unary function Binary ( Arg1, Arg2 ) integer, intent(in) :: Arg1, Arg2 character(len=...), pointer :: Binary ... end function Binary end module Funcs program What use Funcs integer :: X = 42, Y read (10) .op. x, y end program What Is "10" an , or is "(10) .op. x" a ? Note that this program is valid Fortran 90, and "(10) .op. x" is a according to the Fortran 90 standard. An edit is supplied to remove the ambiguity in the current standard. ANSWER: This is another example of the same problem as F08/0075, viz syntactic ambiguity caused by the F2008 feature "operator syntax for variable denotation". Therefore this interpretation request is subsumed by F08/0075. EDITS: See F08/0075. SUBMITTED BY: Van Snyder HISTORY: 12-150 m198 F08/0076 submitted 12-150r1 m198 Revised answer and edits, passed J3 meeting 12-196 m199 Subsumed by F08/0075, J3 letter ballot #26, 12-184 Result: This is another instance of the same problem (syntactic ambiguity) caused by the same feature (operator syntax for variable denotation) as F08/0075, so needs to be answered together with F08/0075 => example will be added to F08/0075, and F08/0076 is therefore subsumed by F08/0075. 12-197 m199 F08/0075 passed by J3 meeting N1990 m202 Passed by WG5 ballot 6, N1988 - subsumed by F08/0075 N200x m203 Subsumed by F08/0075 - no edits in F2008 Corrigendum 3 ---------------------------------------------------------------------- NUMBER: F08/0083 TITLE: Type parameter default expressions allow circular dependence KEYWORDS: type parameter expressions, circular dependence DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 3 QUESTION: Consider type :: T ( I, J ) integer, kind :: I = J + 1 integer, kind :: J = I + 1 end type T type(t) :: X(1,2) print *, x%i, x%j end 1. Is the program standard conforming? 2. What does it print? ANSWER: 1. The program is not conformant because the standard does not establish an interpretation. An edit is supplied to make it clear that the program is not comformant. 2. The standard does not establish an interpretation. EDITS for 10-007r1: [152:9] Replace item (9) in the list in 7.1.12p1: (9) "a previously declared kind type parameter of the type being defined," SUBMITTED BY: Van Snyder HISTORY: 12-172 m199 F08/0083 submitted - passed by J3 meeting 13-237 m200 Passed by J3 letter ballot #27 13-203 N1990 m202 Passed by WG5 ballot 6, N1988 N200x m203 In F2008 Corrigendum 3 ---------------------------------------------------------------------- NUMBER: F08/0084 TITLE: Pointer arguments to PURE functions KEYWORDS: PURE function, POINTER, INTENT(IN) DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 3 QUESTION: Consider the following subprogram: Real Pure Function F( X ) Real,Pointer :: X Real :: F f = 1.0 x = 2.0 ! (A) Nullify(x) ! (B) End Function F This subprogram does not conform to Fortran 2003, because both statements (A) and (B) violate constraint C1272 which says "C1272 In a pure subprogram any designator with a base object that ... is a dummy argument of a pure function ... shall not be used ... [in] a variable definition context ...". However, the corresponding constraint in Fortran 2008, C1283, is missing the condition that applies the constraint to a dummy argument of a pure function, except when it has INTENT(IN). Thus the statements marked (A) and (B) do not violate C1283, and therefore this subprogram appears to conform to Fortran 2008. Was this subprogram intended to be standard-conforming? ANSWER: No, this subprogram was not intended to be standard-conforming. An edit is supplied to re-insert the omitted condition. EDIT to 10-007r1: [312:31] In 12.7, constraint C1283, after "association", insert ", is a dummy argument of a pure function". SUBMITTED BY: Tobias Burnus HISTORY: 12-174 m199 F08/0084 submitted 12-174r1 m199 Revised 12-174r2 m199 Passed by J3 meeting 13-237 m200 Passed by J3 letter ballot #27 13-203 N1990 m202 Passed by WG5 ballot 6, N1988 N200x m203 In F2008 Corrigendum 3 ---------------------------------------------------------------------- NUMBER: F08/0085 TITLE: Problems with PARAMETERs KEYWORDS: PARAMETER DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 3 QUESTION: (1) Consider the program fragment Subroutine s Parameter (n=1) Integer :: x,n !(A) Parameter (x=3) The type declaration statement marked "!(A)", declares the entities X and N to be of type INTEGER. Furthermore, as we see by the immediately preceding and following PARAMETER statements, both X and N are named constants. Unfortunately, a constraint says C507 (R503) "An shall appear if the entity is a named constant (5.3.13)." (BTW, R503 is .) Therefore one concludes that the type declaration statement marked "!(A)" is not conforming as it violates C507 for both X and N. Is this statement intended to be conforming? (2) Firstly, consider Subroutine s2(n) Integer,Parameter :: x(n:n+1) = [ 1,2 ] Character(n),Parameter :: y = 'abc' ... The type declaration statements are not conforming because according to 5.2.2p1, X and Y are automatic data objects, and C506 says that shall not appear in that case. Now consider Subroutine s2b(n) Implicit Character(n) (a-z) Parameter (y = 'abc') Integer :: x(n:n+1) Parameter(x=[1,2]) This is not valid Fortran 2003, because 5.2 contains the requirement: "The combination of attributes that may be specified for a particular entity is subject to the same restrictions as for type declaration statements regardless of the method of specification. This also applies to PROCEDURE, EXTERNAL, and INTRINSIC statements." This requirement does not appear in F2008. However, there is no indication in the Introduction of this new feature. Is this extension to Fortran 2003 deliberate? ANSWER: (1) Yes, the type declaration statement was intended to be allowed. An edit is supplied to correct this mistake. (2) No, the omission of this requirement was inadvertent. An edit is supplied to correct this mistake. EDITS: [88:14] In 5.2.1, Replace constraint "C507 (503)" completely with "C507 (R501) If the PARAMETER keyword appears, shall appear in each ." {Fix Q1.} [88:14+] In 5.2.1, immediately after constraint C507, insert new constraint: "C507a An expression that specifies a length type parameter or array bound of a named constant shall be a constant expression." {Fix Q2.} SUBMITTED BY: Malcolm Cohen HISTORY: 12-189 m199 F08/0085 submitted 12-189r1 m199 Passed by J3 meeting 13-237 m200 Failed as amended by J3 letter ballot #27 13-203 13-239 m200 Revised - passed by J3 meeting 13-262 m201 Passed J3 letter ballot #28 13-255r1 N1990 m202 Passed by WG5 ballot 6, N1988 N200x m203 In F2008 Corrigendum 3 ---------------------------------------------------------------------- NUMBER: F08/0086 TITLE: Implied-shape and separate PARAMETER statement KEYWORDS: Implied-shape, PARAMETER DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 3 QUESTION: Q1. Consider Program test1 Character(*) a,b(*) Dimension c(*) Parameter (a='123', b=['1','2','3']) Character(*),Parameter :: c = [ '44','55','66' ] Print *,a,b,c End The definition of the assumed-length character named constant A conforms to Fortran 77 to Fortran 2008. However, the definition of the implied-shape named constant B appears not to conform to Fortran 2008, as the standard says in 5.4.11p2 "A named array constant defined by a PARAMETER statement shall have its shape specified in a prior specification statement." On the other hand, the named constant C does not have such a requirement, so its definition would appear to be conforming. This apparent requirement on the named constant B would thus appear to be inconsistent with those on the named constant C, as well as inconsistent with the way that assumed length works, and with the general principle of allowing attributes to be specified either in a single type declaration statement or with separate specification statements. Is the program intended to conform to the Fortran standard? Q2. Consider Subroutine test2(a) Real,Dimension(*) :: a,c Parameter (c = [ 45.6 ]) a(:size(c)) = c End Subroutine The in the type declaration statement is ambiguous; if it is an then the declaration of A as an assumed-size array is erroneous, but if it is an then the declaration of C as an implied-shape array is erroneous. Is this program-unit intended to be standard-conforming? ANSWER: A1. Yes, the program was intended to conform to the Fortran standard. An edit is provided to modify the requirement for prior specification so as to allow this case. A2. Yes, the program is intended to conform to the Fortran standard. An edit is provided to add syntax to permit this unambiguously. EDITS to 10-007r1: [94:10] 5.3.8.1, R515, Change "" to "". {This will be the unambiguous implied-shape syntax.} [94:10+] Insert new production "<> ". {This will be the otherwise-ambiguous syntax.} [95:32] 5.3.8.5p1 Replace sentence "An assumed-size array is declared with an ." with "A dummy argument is declared to be an assumed-size array by an or an ." {Now two ways of declaring assumed size.} [95:33-] Insert new BNF term "R520a <> [ : ] *" [95:33] R521 , after "<>" Replace entire RHS "[ , ]... [ : ] *" with ", " {The unambiguous case has a list of s.} [95:37+] Insert new BNF rules and constraint "R521a <> C534a An object whose array bounds are specified by an shall be a dummy data object or a named constant." {The otherwise-ambiguous case. Note careful wording.} [96:24-25] 5.3.8.6p1 Replace sentence "An implied-shape array is declared... ." with "A named constant is declared to be an implied-shape array with an that is an or an ." {Now two ways of declaring implied shape.} [96:26] R522, Replace right-hand-side (after "<>") "[ : ] *" with ", ". {This is now the unambiguously implied-shape spec.} [96:28] p2, Change "s" -> "s" and "the " -> "its ", making the entire paragraph read: "The rank of an implied-shape array is the number of s in its ." {Change rank determination to accord with new syntax term.} [107:11] 5.4.11p1 "shape" -> "rank". {In the PARAMETER statement, only require the rank to be specified in a prior specification statement.} NOTE for future investigation: The current wording of C533 is slightly defective, as it does not clearly prohibit "REAL,DIMENSION(*) :: dummy,nondummy", seeing as how that does indeed declare "the array bounds of a dummy data object". C533 should probably be reworded similarly to C534a. SUBMITTED BY: Bill Long HISTORY: 12-191 m199 F08/0086 submitted - revised by Malcolm Cohen - passed by J3 meeting 13-237 m200 Failed letter ballot 13-235 m200 Revised with straw votes 13-235r1 m200 Passed by J3 meeting 13-262 m201 Passed as amended by J3 letter ballot #28 13-255r1 N1990 m202 Passed by WG5 ballot 6, N1988 N200x m203 In F2008 Corrigendum 3 ** Revised edits from draft corrigendum ballot - replace entire interp ---------------------------------------------------------------------- NUMBER: F08/0087 TITLE: Mixed-kind character assignment KEYWORDS: Mixed kind, character assignment DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 3 QUESTION: For a processor that supports both ASCII and ISO 10646 UCS-4 character kinds, assuming without loss of generality that Selected_Char_Kind('ASCII') is equal to 1 and that Selected_Char_Kind('ISO_10646') is equal to 10646, consider the following program: Module charkinds Integer,Parameter :: ascii = 1 Integer,Parameter :: ucs4 = 10646 End Module Module overload Use charkinds Interface Assignment(=) Module Procedure char_asg End Interface Contains Subroutine char_asg(a,b) Character(*,ascii),Intent(Out) :: a Character(*,ucs4),Intent(In) :: b Do i=1,Min(Len(a),Len(b)) a(i:i) = Achar(Mod(Iachar(b(i:i))+1,127)) End Do a(i:) = Repeat('*',Len(a)-Len(b)) End Subroutine End Module Program test Use overload Character(10,ascii) x x = ucs4_'Hello' Print *,'"',x,'"' End Program This program conforms to Fortran 95, which permitted user-defined assignment between all characters with different kinds. However, Fortran 2008 provides intrinsic assignment between ISO 10646 characters and ASCII characters, so user-defined assignment is not permitted (12.4.3.4.3 and Table 7.8). Thus there seems to be a contradiction between the Fortran 95 compatibility description in 1.6.3 and 12.4.3.4.3. Is the program intended to conform to Fortran 2008? And if it does, does it print "Hello " (intrinsic assignment) "Ifmmp*****" (user-defined assignment)? ANSWER: The program was not intended to conform to the standard. An edit is provided to remove the contradiction. EDITS: [24:14] 1.6.3p1, "Any" -> "Except as identified in this subclause, any". {No longer true.} [24:15] Split the sentence "The ..." introducing the list into a separate paragraph (which will be the third paragraph), and insert a new paragraph (as the second paragraph) as follows: "Fortran 95 permitted defined assignment between character strings of the same rank and different kinds. This part of ISO/IEC 1539 does not permit that if both of the different kinds are ASCII, ISO 10646, or default kind." {Describe the incompatibility.} [25:2+] 1.6.4, after p3, insert a new paragraph. "Fortran 90 permitted defined assignment between character strings of the same rank and different kinds. This part of ISO/IEC 1539 does not permit that if both of the different kinds are ASCII, ISO 10646, or default kind." {Describe the incompatibility.} SUBMITTED BY: Van Snyder HISTORY: 13-204 m200 F08/0087 submitted 13-204r1 m200 Revised - passed by J3 meeting 13-262 m201 Passed J3 letter ballot #28 13-255r1 N1990 m202 Passed by WG5 ballot 6, N1988 N200x m203 In F2008 Corrigendum 3 ---------------------------------------------------------------------- NUMBER: F08/0088 TITLE: Can ALLOCATE with SOURCE= have side-effects in a PURE proc? KEYWORDS: Allocate, SOURCE=, PURE, side-effects DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 3 QUESTION: On comp.lang.fortran Ian Harvey brought up a pointer/PURE question. Given a type definition like type :: int_ptr integer, pointer :: i end type int_ptr And a PURE function like PURE function FUN (arg) type(int_ptr), intent(in) :: arg type(int_ptr), allocatable :: tmp FUN = 1 allocate (tmp, source=arg) tmp%i = 2 end function fun Is FUN standard conforming? Doesn't the use of source=arg allow the function to modify a global entity via the tmp%i = ...? There don't seem to be any constraints on what arg%i can point to, which means that the assignment to tmp%i can have side effects. Note that C1283(1) prevents usage like arg%i = 2 ANSWER: This was not intended to be standard-conforming. An edit is supplied to remedy this oversight. EDITS: [312:37] In C1283, delete "or" and add a new item "(4a) as the in a SOURCE= clause if the designator is of a derived type that has an ultimate pointer component, or" SUBMITTED BY: Dick Hendrickson HISTORY: 13-226 m200 F08/0088 submitted 13-226r1 m200 Edits added - passed by J3 meeting 13-262 m201 Passed J3 leter ballot #28 13-255r1 N1990 m202 Passed by WG5 ballot 6, N1988 N200x m203 In F2008 Corrigendum 3 ---------------------------------------------------------------------- NUMBER: F08/0090 TITLE: What restrictions apply to initialization and PARAMETER? KEYWORDS: PARAMETER, initialization, conformable, type conversion DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 3 QUESTION: Consider the programs Program m200c3_1 Integer :: a(10,10) Parameter (a = [ (i,i=1,100) ] ) Print *,a End Program Program m200c3_2 Parameter (b = 'ok') Print *,b End Program Program m200c3_3 Integer :: x(23) = [ 1 ] Print *,x End Program Program m200c3_4 Integer :: y = 'ok' Print *,y End Program The PARAMETER statement for the named constant A has an expression whose shape does not conform with that of A. The PARAMETER statement for the named constant B has an expression whose type does not conform to that of B. The for X is not conformable in shape. The for Y is not conformable in type. There appears to be no requirement either for shape or type conformance, in Fortran 2008 or in previous Fortran standards, except for initializing data pointers. Q1. Do any of these programs conform to Fortran 2008? Q2. If there is meant to be a requirement for the shapes to conform or for the types to be convertible, should this not be a constraint? ANSWER: A1. No, these programs do not conform to Fortran 2008, as no interpretation is established for any of them. Edits are provided to clarify this. A2. This is not a constraint. A future revision of Fortran might choose to mandate diagnosis of these errors. EDIT to 10-007r1: [88:30+] 5.2.1 Syntax, Insert new paragraph at end of subclause "If appears for a nonpointer entity, - its type and type parameters shall conform as specified for intrinsic assignment (7.2.1.2); - if the entity has implied shape, the rank of shall be the same as the rank of the entity; - if the entity does not have implied shape, shall either be scalar or have the same shape as the entity.". [107:12+] 5.4.11 PARAMETER statement, after p2, Insert new paragraph "The constant expression that corresponds to a named constant shall have type and type parameters that conform with the named constant as specified for intrinsic assignment (7.2.1.2). If the named constant has implied shape, the expression shall have the same rank as the named constant; otherwise, the expression shall either be scalar or have the same rank as the named constant.". SUBMITTED BY: Malcolm Cohen HISTORY: 13-229 m200 F08/0090 submitted - passed by J3 meeting 13-262 m201 Passed J3 letter ballot #28 13-255r1 N1990 m202 Passed by WG5 ballot 6, N1988 N200x m203 In F2008 Corrigendum 3 ------------------------------------------------------------------------ NUMBER: F08/0091 TITLE: Derived type with no components KEYWORD: Derived type DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 3 QUESTION: Q1. Consider Program m7_1 Type empty End Type Type(empty),Target :: x Type(empty),Pointer :: y y => x Print *,Associated(y,x) End Is this program standard-conforming, and does it print T or F? According to 16.5.3.2p2, item 1 is default integer etc, N/A item 2 is double precision etc, N/A item 3 is default character, N/A item 4 is C character, N/A item 5 is SEQUENCE type, N/A According to item (6), "a nonpointer scalar object of any type not specified in items (1)-(5) occupies a single unspecified storage unit that is different [from everything else]" If that analysis is correct, X occupies a single unspecified storage unit, not zero storage units, and therefore T should be printed. Q2. Consider Program m7_2 Type sempty Sequence End Type Type(sempty),Target :: x Type(sempty),Pointer :: y y => x Print *,Associated(y,x) End Is this program standard-conforming, and does it print T or F? Now X falls into item 5, which makes it a "sequence of storage sequences corresponding to the sequence of its ultimate components"; there are no ultimate components, this makes it a zero-sized storage sequence and therefore F should be printed. This does not seem to be consistent with the apparent answer to Q1. Q3. Consider Program m7_3 Type numeric_empty Sequence End Type Type character_empty Sequence End Type Type(numeric_empty) a Integer b Character c Type(character_empty) d Equivalence(a,b) ! E1. Equivalence(c,d) ! E2. End Is this program conforming? According to the definitions in 4.5.2.3, NUMERIC_EMPTY is a numeric sequence type and therefore one might expect to be able to EQUIVALENCE it to an INTEGER. Similarly, CHARACTER_EMPTY is a character sequence type and therefore one might expect to be able to EQUIVALENCE it to a CHARACTER. However, NUMERIC_EMPTY is clearly also a character sequence type, and therefore statement E1 violates C592 because B is not character or character sequence. Similarly, CHARACTER_EMPTY is clearly also a numeric sequence type, and therefore statement E2 violates C591. It seems very strange to have a type that is simultaneously numeric and character sequence type. Q4. Consider Program m7_4 Type numeric_empty_2 Sequence Real c(0) End Type Type character_empty_2 Sequence Character(0) c End Type Type(numeric_empty_2) a Integer b Character c Type(character_empty_2) d Equivalence(a,b) ! E3. Equivalence(c,d) ! E4. End Does this program conform? According to the definitions in 4.5.2.3, NUMERIC_EMPTY_2 is a numeric sequence type and not a character sequence type, and conversely CHARACTER_EMPTY_2 is a character sequence type and not a numeric sequence type, and therefore the constraints for the statements at E3 and E4 are not violated. Thus this appears to be conforming, in contradiction to the example in Q3, even though the storage sequence of NUMERIC_EMPTY, NUMERIC_EMPTY_2, CHARACTER_EMPTY, and CHARACTER_EMPTY_2 are all the same. This does not look very consistent with the situation in Q3. ANSWER: A1. The program is conforming and prints T. A2. The program was not intended to conform; SEQUENCE makes no sense when there are no components. An edit is needed to correct this. A3. The program does not conform as a sequence type must have at least one component. A4. The program is conforming. The apparent design inconsistency is not an error in the standard. EDIT to 10-007r1: [62:19] 4.5.2.3, in constraint C436 After "appears," insert "the type shall have at least one component,". SUBMITTED BY: Malcolm Cohen HISTORY: 13-266 m201 F08/0091 submitted 13-266r1 m201 Revised - passed by J3 meeting 13-313 m202 Passed as amended by J3 letter ballot 13-297 N1994 m202 Passed by WG5 ballot 7, N1992 N200x m203 In F2008 Corrigendum 3 ---------------------------------------------------------------------- NUMBER: F08/0092 TITLE: Derived type parameter requirements KEYWORD: Derived type parameter DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 3 QUESTION: Consider Type t1(a,a) Integer,Kind :: a Integer,Len :: a End Type Type t2(a) Integer,Kind :: a,a,a End Type These type definition appears to valid, in that (a) there is no requirement that a type parameter appears only once in the ; (b) there is no requirement that a type parameter appears in only one , and only once. Were these intended to be valid? What is their meaning? ANSWER: These were not intended to be valid, and they are not valid because the standard does not establish an interpretation for them. Unique names for type parameters can possibly be deduced from the scoping rules. Edits are supplied to make the requirements explicit. EDITS to 10-007r1: [61:19+] In 4.5.2.1, after C427 insert new constraint "C427a (R426) The same shall not appear more than once in a ." {Require unique names for type parameters.} [64:8] In 4.5.3.1, C438, after "shall appear" insert "exactly once". {Forbid multiple declarations of a type parameter, whether in the same or more than one.} SUBMITTED BY: Malcolm Cohen HISTORY: 13-267 m201 F08/0092 submitted - passed by J3 meeting 13-313 m202 Passed as amended by J3 letter ballot 13-297 N1994 m202 Passed by WG5 ballot 7, N1992 N200x m203 In F2008 Corrigendum 3 ---------------------------------------------------------------------- NUMBER: F08/0093 TITLE: Process exit status and error termination KEYWORD: ERROR STOP DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 3 QUESTION: Many operating systems today (e.g. Posix-related ones) use a process exit status of zero to indicate successful execution, whereas nonzero indicates an error. (Occasionally nonzero values, e.g. 1, also indicate success.) Fortran STOP and ERROR STOP with an integer are recommended to use the as the exit status. The STOP statement without an integer is recommended to have an exit status of zero; this conforms to common practice since STOP initiates normal termination. The standard is silent on the effect of error termination, except in the case of an ERROR STOP (sans integer ) which is unexpectedly recommended to also return an exit status of zero. Q1. Is this intentional? Should the exit code for ERROR STOP not have been recommended to be nonzero? Q2. Should the recommendation for an ERROR STOP not also apply to error termination by other causes? ANSWER: A1. It was not intended to recommend returning "success" for error termination. An edit is supplied to correct this. A2. Yes, the recommendation for an ERROR STOP without an integer should also apply to other means of standard-defined error termination. An edit is supplied to correct this omission. EDIT to 10-007r1: [33:36+] 2.3.5, before Note 2.7, insert new note "NOTE 2.6a If the processor supports the concept of a process exit status, it is recommended that error termination initiated other than by an ERROR STOP statement supplies a processor-dependent nonzero value as the process exit status." {Recommendation for error termination other than by ERROR STOP.} [188:10+10] In 8.4, Note 8.30, Before "is of type character or does not appear" Insert "in a STOP statement". {Limit zero recommendation to STOP, not ERROR STOP.} [188:10+11+] At the end of Note 8.30, insert a new paragraph "If the in an ERROR STOP statement is of type character or does not appear, it is recommended that a processor-dependent nonzero value be supplied as the process exit status, if the processor supports that concept." {Specify nonzero exit for ERROR STOP.} [459:17+] After the bullet item “how soon an image terminates if another image initiates error termination (2.3.5);” Insert new bullet point "the recommended process exit status when error termination is initiated other than by an ERROR STOP statement with an integer (2.3.5);" {Probably unnecessary, seeing how it is only a recommendation, but maybe a good idea anyway.} SUBMITTED BY: Bill Long/Malcolm Cohen HISTORY: 13-268 m201 F08/0093 submitted - passed by J3 meeting 13-313 m202 Passed as amended by J3 letter ballot 13-297 N1994 m202 Passed as amended by WG5 ballot 7, N1992 ** [460:24+] moved to [459:17+] N200x m203 In F2008 Corrigendum 3 ---------------------------------------------------------------------- NUMBER: F08/0094 TITLE: Procedure statement and double colon KEYWORD: PROCEDURE, Interface block DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 3 QUESTION: Fortran 2003 did not permit a double colon in the in an interface block. Fortran 2008 syntax seems to allow this, but it is not mentioned in the Introduction as a new F2008 feature. Is this apparent new feature deliberate? ANSWER: Yes, this new feature was intended. An edit is provided to add mention of it to the Introduction. EDIT: [xvi] Introduction, p2, "Programs and procedures:" bullet, After "empty CONTAINS section is allowed." Insert "A PROCEDURE statement can have a double colon before the first procedure name." SUBMITTED BY: Malcolm Cohen HISTORY: 13-274 m201 F08/0094 submitted - passed by J3 meeting 13-313 m202 Passed by J3 letter ballot 13-297 N1994 m202 Passed by WG5 ballot 7, N1992 N200x m203 In F2008 Corrigendum 3 ---------------------------------------------------------------------- NUMBER: F08/0095 TITLE: Is PRESENT allowed in specification and constant expressions KEYWORD: PRESENT, optional dummy argument DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 3 QUESTION: Q1. Consider Subroutine s1(a) Integer,Optional :: a Logical,Parameter :: x = Present(a) Print *,x End Subroutine Does this program unit conform to the standard? 7.1.12 item (4) permits "a specification inquiry where each designator or function argument is ... (b) a variable whose properties inquired about are not (i) assumed, (ii) deferred, or (iii) defined by an expression that is not a constant expression," PRESENT is a specification inquiry (because it is an intrinsic inquiry function), and the standard does not say that the "presence" of an optional dummy argument is an assumed or deferred attribute, and it does not appear to be "defined by an expression" either. On the other hand, the standard does not say anything about what kind of property the presence is. Q2. Consider Subroutine s2(a) Integer,Optional :: a Real x(Merge(2,3,Present(a))) If (Present(a)) Then x = [ 1,2,a ] Else x = [ 1,2 ] End If Print *,x End Subroutine Does this program unit conform to the standard? It appears to satisfy the rules for specification expression, similarly to how it satisfies the rules for a constant expression, but then the standard is silent as to what sort of property "presence" is... Q3. Consider Subroutine s3(a) Character(*),Optional :: a Real x(Len(a)) Print *,Size(x) End Subroutine Does this program unit conform to the standard? Using the same reasoning as Q1 and Q2, it appears to conform, but if A is absent, LEN(A) is not permitted by 12.5.2.12. ANSWER: A1. Program unit S1 was not intended to conform to the standard. An edit is provided to clarify that this is not valid. A2. Program unit S2 was intended to conform to the standard. An edit is provided to clarify that this is valid. A3. Program unit S3 was not intended to conform to the standard. An edit is provided to clarify that this is not valid. EDITS to 10-007r1: [150:24] 7.1.11p2, item (9)(b) after "variable" insert ",that is not an optional dummy argument, ". {Prevent specification enquiries on optional dummy arguments.} [150:27+] 7.1.11p2, after item (9) entirely, insert "(9a) a specification inquiry that is a constant expression, (9b) a reference to the intrinsic function PRESENT," {Allow inquiries on optional dummy arguments that will not violate the rules in 12.5.2.12 when the dummy is absent, and allow PRESENT to be used.} [150:37] 7.1.11p4, item (1) after "intrinsic inquiry function" insert "other than PRESENT". {Remove PRESENT from list of specification inquiries, this fixes constant expressions.} SUBMITTED BY: Malcolm Cohen/Van Snyder HISTORY: 13-278 m201 F08/0095 submitted 13-278r1 m201 Passed by J3 meeting 13-313 m202 Passed by J3 letter ballot 13-297 N1994 m202 Passed by WG5 ballot 7, N1992 N200x m203 In F2008 Corrigendum 3 ---------------------------------------------------------------------- NUMBER: F08/0096 TITLE: Is VALUE permitted for an array in a BIND(C) procedure? KEYWORD: array, BIND(C), VALUE DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 3 QUESTION: Consider INTERFACE SUBROUTINE s(a) BIND(C) USE ISO_C_BINDING REAL(C_float),VALUE :: a(100) END END INTERFACE Q1. Does this interface conform to the Fortran standard? Q2. If so, what prototype does it interoperate with? ANSWER: A1. C does not have arrays that are passed by value, so this was not intended to conform to the Fortran standard. An edit is provided to clarify this. A2. This question is moot. EDITS to 10-007r1: [306:31] 12.6.2.2, C1255, after "(15.3.5, 15.3.6)" insert "that is not an array with the VALUE attribute," {Do not permit BIND(C) to have arrays by value.} {Note: TS 29113 replaces this same constraint.} [433:12] 15.3.7p2, item (4), after "any" insert "scalar". {Do not describe arrays by value in a prototype.} SUBMITTED BY: Malcolm Cohen HISTORY: 13-284 m201 F08/0096 submitted - passed by J3 meeting 13-313 m202 Passed as amended by J3 letter ballot 13-297 N1994 m202 Passed by WG5 ballot 7, N1992 N200x m203 In F2008 Corrigendum 3 ---------------------------------------------------------------------- NUMBER: F08/0097 TITLE: Is the optional comma allowed in TYPE(CHARACTER*...)? KEYWORD: TYPE, CHARACTER DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 3 QUESTION: Consider CHARACTER*1, A TYPE(CHARACTER*1,) B The optional comma in the declaration of B looks ugly. Is this deliberate? ANSWER: No, this syntax was inadvertently allowed. An edit is provided to remove it. EDITS to 10-007r1: [51:26+] 4.3.1.1, after C406, insert new constraint "C406a (R403) In TYPE() the shall not end with a comma." SUBMITTED BY: Malcolm Cohen HISTORY: 13-285 m201 F08/0097 submitted - passed by J3 meeting 13-313 m202 Passed by J3 letter ballot 13-297 N1994 m202 Passed by WG5 ballot 7, N1992 N200x m203 In F2008 Corrigendum 3 ---------------------------------------------------------------------- NUMBER: F08/0098 TITLE: How many ACQUIRED_LOCK= specifiers are allowed in a LOCK stmt? KEYWORD: LOCK DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 3 QUESTION: Consider LOCK ( x, ACQUIRED_LOCK=n1, ACQUIRED_LOCK=n2, STAT=n3, STAT=n4 ) Is this conforming? Multiple STAT= are prohibited from a , but this is a so that does not apply. There is no constraint anywhere about how many ACQUIRED_LOCK= specifiers may appear. ANSWER: No, this was not intended to be conforming. No specifier was intended to be allowed to appear more than once. EDITS to 10-007r1: [194:2+] 8.5.6, after R864, insert new constraint "C852a No specifier shall appear more than once in a given ." SUBMITTED BY: Malcolm Cohen HISTORY: 13-286 m201 F08/0098 submitted - passed by J3 meeting 13-313 m202 Passed by J3 letter ballot 13-297 N1994 m202 Passed by WG5 ballot 7, N1992 N200x m203 In F2008 Corrigendum 3 ----------------------------------------------------------------------