10-006T1-5r1 Fortran interpretations that make up F2003 Corrigendum 1 through 5 Stan Whitlock for /interp 15 June 2010 ++ Fix edits here to match 10-151 update pages to SD 018: ++ F95/0098 [41:34] delete both commas ++ F03/0125 [316:21] different edit ++ F03/0137 full stop at end of insertion ++ F03/0138 "USE" to "use" twice This is the complete list of interpretations that have been fixed in F2003 via Corrigenda 1 through 5: > 05-016 == 05-006T1 (m173) interps (N1640) F03 Corr #1 (N1636) > 08-017 == 06-006T2r1 (m177) interps (N1666) F03 Corr #2 (N1664) > 08-021 == 08-006AT3 (m185) interps (N1730) F03 Corr #3 (N1727) > 09-022 == 09-006AT4 (m187) interps (N1764+) F03 Corr #4 (N1771) > == 10-006T5 (m192) interps (N1805) F03 Corr #5 (N1815) > N1823 - combined TCs 1-5 ====================================================================== Part 0: Summary Status of these Fortran Interpretations ====================================================================== Note N: d == done {if S = C* | T*, then done is assumed} Status S: Defect Type T: P == J3 consideration in progress C == Clarification M Passed by J3 meeting E Erratum B Passed by J3 letter ballot I Interpretation W Passed by WG5 ballot C1 Included in F95 corrigendum 1 (see N1422) C2 Included in F95 corrigendum 2 (see N1473) T1 Included in F03 corrigendum 1 (see N1636/N1640) T2 Included in F03 corrigendum 2 (see N1657/N1664) T3 Included in F03 corrigendum 3 (see N1730/N1727) T4 Included in F03 corrigendum 4 (see N1771/N1764) T5 Included in F03 corrigendum 5 (see N1805/6/N1816) X Excluded for the reasons given N S T number title - - - ------ ----- T1 E F90/0207 Integer bit-model inconsistency T1 E F95/0030 Ordering requirements on definition of specification functions T4 F95/0031 Association of pointer function result with INTENT(OUT) dummy argument (subsumed by 000074) T4 I F95/0074 TARGET dummy arguments and POINTER expressions T1 E F95/0078 Resolving generic procedure references T1 E F95/0096 End-of-record and PAD T5 E F95/0098 Are dummy functions returning assumed-length character legal? T4 I F95/0102 mask-expr evaluated only once T1 I F03/0001 Generic type-bound procedures T1 I F03/0002 Component value for pointer components T4 E F03/0003 Referencing deferred bindings T4 E F03/0004 Type-bound procedures and undefined association status T1 E F03/0005 Argument association and the TARGET attribute T1 E F03/0006 Intrinsic assignment and allocatable components T1 E F03/0007 Finalization of structure constructors in specifications T2 E F03/0008 Pointer assignment and arrays T1 E F03/0009 VALUE attribute for passed-object dummy arguments T1 E F03/0010 Unlimited polymorphic pointer/allocatable dummy arguments T1 E F03/0011 Allocating objects of abstract types T2 E F03/0012 Procedure pointers and the EXTERNAL attribute T1 E F03/0013 VALUE attribute for polymorphic dummy arguments T1 E F03/0014 Automatic arrays in interface bodies T1 E F03/0015 TARGET attribute for associate names T1 E F03/0016 Invoking type-bound procedures via array objects T2 E F03/0020 Kinds of intrinsic type parameters T5 E F03/0022 Coexistence of IEEE and non-IEEE kinds T2 E F03/0023 IEEE_SET/GET_UNDERFLOW_MODE T5 E F03/0024 DEALLOCATE and array pointers T2 E F03/0025 Abstract types in CLASS IS type guard statements T2 E F03/0026 Intrinsic types in CLASS IS type guard statements T2 E F03/0027 Assumed character length in type guard statements T2 E F03/0028 Commas in complex namelist output T2 E F03/0029 Negative zero and intrinsic functions T1 I F03/0031 IEEE invalid T1 I F03/0032 Sign bit of IEEE NaN T1 I F03/0033 IEEE_VALUE() T5 E F03/0034 IEEE_LOGB() T1 I F03/0035 IEEE_NEXT_AFTER() T1 I F03/0036 IEEE_REM() T1 I F03/0037 IEEE_RINT() T1 I F03/0038 IEEE_SCALB() T5 E F03/0039 HYPOT() T1 I F03/0040 2.0+2.0 and IEEE T1 I F03/0041 IEEE halting and exceptions T1 E F03/0043 Passed-object arguments and procedure pointer components T1 E F03/0044 Implicit interfaces and conflicting references T2 E F03/0045 Finalization and assumed-sized arguments with INTENT(OUT) T4 E F03/0049 Separators in list-directed output involving UDDTIO T3 E F03/0050 Questions about internal files T1 I F03/0052 ADVANCE= specifier in child data transfer statements T1 E F03/0054 Denormal inputs to EXPONENT, FRACTION, and SET_EXPONENT T1 E F03/0055 Denormal inputs to SPACING and RRSPACING T2 I F03/0056 Null input values and list-directed UDDTIO T2 E F03/0057 Namelist I/O and UDDTIO T2 I F03/0058 Recursive namelist output T2 E F03/0060 Default initialization of INTENT(OUT), assumed-size arrays {subsumed by F03/0045} T2 E F03/0061 Polymorphism and explicit-shape or assumed-size dummy arguments T2 E F03/0062 Finalization of array constructors T5 E F03/0063 Procedure pointers in BLOCK DATA program units T2 I F03/0066 Precision of operation T2 I F03/0067 Accuracy of conversion of real literal constants T2 E F03/0068 First character of namelist output records T2 E F03/0069 Procedure pointers in defined assignment T2 E F03/0070 Can child I/O statements be advancing I/O statements? T5 E F03/0071 Subroutine/function ambiguity in generics T2 E F03/0072 Default initialization for "automatic" components T4 I F03/0073 C interop of dummy procedures T4 E F03/0074 Type mismatch for C character arguments T4 E F03/0075 C interop of derived types with array components T4 I F03/0076 Scope of Fortran names of procedures with binding labels T4 E F03/0077 LBOUND of array structure component T5 C F03/0078 IEEE_SUPPORT_DATATYPE vs. mathematical equivalence T3 E F03/0079 Value of decimal exponent for a real zero value T3 I F03/0080 Formatted output of a negative real zero value T4 I F03/0081 F edit descriptor with field width 0 T4 I F03/0082 VALUE in place of INTENT for pure procedure dummy arguments T3 E F03/0086 Elemental and BIND(C) T4 I F03/0087 Entry names as dummy procedure arguments T3 E F03/0088 Defined operations/assignments and VOLATILE/ASYNCHRONOUS T3 E F03/0089 Interoperability of non-BIND derived types T5 E F03/0090 Polymorphic array constructors T3 E F03/0092 Procedure characteristics and unlimited polymorphic T3 E F03/0093 Allocatable array on intrinsic assignment with scalar expr T3 E F03/0094 Final subroutine and VALUE attribute T3 I F03/0095 Bounds remapped pointer assignment and ASSOCIATED T3 E F03/0097 Blanks as separators in NAMELIST input T4 E F03/0098 Does allocate with source= define subcomponents? T4 E F03/0099 Clause 16 does not account for volatile variable T3 E F03/0101 Is UDDTIO output suitable for namelist and list-directed input T4 C F03/0102 Evaluation of bound-expr in data pointer assignment T3 I F03/0104 Deallocation and finalization of bounds-remapped pointers T3 E F03/0106 Inquire by unit inconsistencies T3 E F03/0107 Are the IEEE_* elemental routines required T3 C F03/0108 Is IEEE_SUPPORT_NAN consistent with the other IEEE_SUPPORT functions T4 E F03/0109 Referencing deferred binding via absent dummy argument T4 C F03/0111 Is defined assignment to a vector subscripted array allowed? T5 E F03/0112 Attributes allowed for dummy arguments in defined assignments T4 E F03/0113 Size and uniqueness considerations for ID= T4 E F03/0114 Inconsistent restrictions on i/o specifiers T4 E F03/0117 STOP executed via function in input/output list T5 E F03/0119 Elemental procedures and deferred length character components T5 E F03/0122 When do objects of sequence derived type have the same type? T5 E F03/0125 Definitions of EXTENDS_TYPE_OF and SAME_TYPE_AS T5 E F03/0126 References to VOLATILE variables in pure procedures T5 E F03/0127 Duration of procedure execution T5 E F03/0129 C_LOC of character substrings T5 I F03/0130 Elemental specific intrinsic procedure characteristics T5 E F03/0131 SAVE attribute and EQUIVALENCE T5 E F03/0132 Unformatted i/o and private components T5 E F03/0133 Is unlimited polymorphic allowed in COMMON? T5 E F03/0134 Implicit typing of procedure pointers T5 E F03/0135 Interaction between RESULT, recursion, and host generic T5 E F03/0136 Are subroutines distinguishable from arrays? T5 E F03/0137 Dummy procedure type compatibility T5 E F03/0138 External as T5 E F03/0140 Type of nested construct entities T5 E F03/0141 More than one specific interface for a procedure ====================================================================== Part 1: Fortran 90 and Fortran 95 Interpretations included in Fortran 2003 Corrigendum #1 ====================================================================== NUMBER: F90/000207 TITLE: Integer bit-model inconsistency KEYWORDS: Bit manipulation procedures, models for integer data DEFECT TYPE: Erratum QUESTION: Is the following observation true? [F90 185:last sentence of 13.5.7] and [WG5/N1176, 219:22+] says ``In particular, whereas the models are identical for w_{z-1}=0, they do not correspond for w_{z-1}=1 and ...'' This statement assumes r==2 in the model for integer data defined in 13.7.1, it is not true for general r. The above sentence should be changed to something like ``In particular, whereas the models are identical for r=2 and w_{z-1}=0, they do not correspond for r/=2 or w_{z-1}=1, and = ...'' ANSWER: Yes. DISCUSSION: The integer model in 13.7.1 describes integer values using a signed-magnitude, base r representation. The bit model in 13.5.7 describes a method for characterizing a sequence of bits. The two models do not generally correspond and the final sentence of 13.5.7 is defective. EDITS: [293:5-6] Remove the sentence beginning "In particular..." SUBMITTED BY: Michael Hennecke HISTORY: submitted F90/0207 Mar. 12, 1996 (in 96-006r2) WG5/N1404 Draft answer 00-260 m154 Passed by J3 meeting 00-329 m155 Failed J3 letter ballot WG5/N1452 Suggested revision 01-292 m158 Passed by J3 meeting 11-1 01-380 m159 Failed J3 letter ballot 04-305r1 m168 Passed by J3 meeting vote 04-417r1 m170 Passed by J3 letter ballot #8 05-180 m172 Passed by WG5 ballot N1617 05-006T1 m173 N1640 interps for F2003 Corr 1 == N1636 ---------------------------------------------------------------------- NUMBER: F95/000030 TITLE: Ordering requirements on definition of specification functions KEYWORDS: Specification expressions, specification functions DEFECT TYPE: Erratum QUESTION: Consider the following program unit. MODULE MOD INTERFACE INT MODULE PROCEDURE F1, F2 END INTERFACE CONTAINS INTEGER PURE FUNCTION F1(I) INTEGER :: A(INT(1_4)), B(INT(1_2)) ! A(1), B(19) INTEGER, PARAMETER :: KIND = SIZE(A) ! KIND == 1 INTEGER(KIND), INTENT(IN) :: I F1 = 17 END FUNCTION F1 INTEGER PURE FUNCTION F2(J) INTEGER :: C(INT(2_4)) ! C(2) INTEGER, PARAMETER :: KIND = SIZE(C) ! KIND == 2 INTEGER(KIND), INTENT(IN) :: J F2 = 19 END FUNCTION F2 END MODULE MOD In processing the references to "INT(1_4)" and "INT(1_2)" in F1, the processor needs to determine whether the references are to the intrinsic function, INT, or to one of the specific procedures, F1 or F2. Determining that requires the processor to have determined the kind type parameter of the dummy argument J, of F2. In turn, that requires the processor to determine whether the reference to "INT(2_4)" is a reference to the intrinsic function, INT, or to one of the specific procedures, F1 or F2. Determining that requires the processor to determine the kind type parameter of the dummy argument I, which requires it to determine that "INT(1_4)" in F1 was a reference to the intrinsic function INT. After all this is determined, the processor can determine that the reference to "INT(1_2)" in the declaration of B in F1 is a reference to the specification function F2. According to 7.1.6.1 [94:38-41], "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." According to 7.1.6.2 [96:27-37], "A variable in a specification expression shall have its type and type parameters, if any, specified by a previous declaration in the same scoping unit, or by the implicit typing rules in effect for the scoping unit, or by host or use association. If a variable in a specification expression is typed by the implicit typing rules, its appearance in any subsequent type declaration statement shall confirm the implied type and type parameters. If a specification expression includes a reference to an inquiry function for a type parameter or an array bound of an entity 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 reference in the same statement. If a specification expression includes a reference to the value of an element of an array specified in the same , the array shall be completely specified in prior declarations." The rules regarding references to variables in a specification expressions and initialization expressions require a strict left-to-right, top-to-bottom ordering between specification and inquiry. Specification functions appear to be unrestricted in this respect. Assuming that the processor supports integers with kind type parameters of 1, 2 and 4, was it the intent of the committee that the program unit above should be standard-conforming? ANSWER: No, it is not the intent that the above program unit be standard conforming. The required complexity of implementation is not justified. The standard has no prohibition against it, but the lack of such a prohibition was an oversight. The edits below correct this oversight. EDITS: Add the following new paragraph immediately before Note 7.11: If an initialization expression in a module includes a reference to a generic, that generic shall have no specific procedures defined in the module subsequent to the initialization expression. Add the following new paragraph immediately before Note 7.10: If a specification expression in a module includes a reference to a generic, that generic shall have no specific procedures defined in the module subsequent to the specification expression. SUBMITTED BY: Henry Zongaro HISTORY: 98-176 m146 Submitted F95/0030 04-312R1 m168 Passed by J3 meeting vote 04-417r1 m170 Passed by J3 letter ballot #8 05-180 m172 Passed by WG5 ballot N1617 06-006T2 m177 N1666 interps for F2003 Corr 2 == N1664 ---------------------------------------------------------------------- NUMBER: F95/0031 TITLE: Association of pointer function result with INTENT(OUT) dummy argument KEYWORDS: Pointer association, dummy argument association, intent attribute DEFECT TYPE: Interpretation STATUS: Subsumed by interp F95/0074 F95/0074 passed by WG5 ballot QUESTION: Consider the following program. PROGRAM P INTEGER, TARGET :: T CALL SUB(FPTR()) CONTAINS FUNCTION FPTR() INTEGER, POINTER :: FPTR FPTR => T END FUNCTION FPTR SUBROUTINE SUB(IO) INTEGER, INTENT(OUT) :: IO IO = 17 END SUBROUTINE SUB END PROGRAM P According to 12.4.1 [200:30-32], "If a dummy argument is not a pointer and the corresponding actual argument is a pointer, the actual argument shall be currently associated with a target and the dummy argument becomes argument associated with that target." According to 12.4.1 [201:19-21], "If a dummy argument has INTENT(OUT) or INTENT(INOUT), the actual argument shall be definable." According to 5.1.2.3 [53:29-31], "The INTENT(OUT) attribute specifies that. . . any actual argument that becomes associated with such a dummy argument shall be definable." The definition of "definable" supplied in Annex A (the term does not appear to be defined in normative text) is: "A variable is <> if its value may be changed by the appearance of its or on the left of an ." According to this definition, "definable" is a property of variables only. In the example above, the actual argument is not a variable. However, the actual argument is pointer associated with an object that is definable. The text cited from 5.1.2.3 refers to the "actual argument that becomes associated with the dummy argument", but the first piece of text cited from 12.4.1 makes it clear that when the actual argument is a pointer, it is the target with which it is associated that becomes argument associated with the dummy argument, and not the actual argument itself. Was it the intent of the committee that this program should not be standard-conforming? ANSWER: The program does not conform to the standard. See the answer to F95 interpretation #000074. EDITS: None SUBMITTED BY: Henry Zongaro HISTORY: 98-177 m146 F95/0031 submitted N1414 Draft answer 00-260 m154 Passed by J3 meeting 00-329 m155 Failed J3 letter ballot 01-200 m157 Passed by J3 meeting 10-2 01-275 m158 Failed J3 letter ballot 04-417r1 m170 Subsumed by interp #74 05-180 m172 F95 interp 000074 failed WG5 ballot N1617 08-259 m185 F95 interp 000074 passed J3 ballot 08-213 N1770 m187 F95 interp 000074 passed WG5 ballot 6 N1764-N1765 as revised 09-006AT4 m187 N1764 interps for F2003 Corr 4 == N1771 ---------------------------------------------------------------------- NUMBER: F95/0074 TITLE: TARGET dummy arguments and POINTER expressions KEYWORDS: TARGET, POINTER, dummy arguments DEFECT TYPE: Interpretation STATUS: Passed by WG5 ballot see also F95 interp 000031 QUESTION: Consider the following program. PROGRAM questionable REAL,TARGET :: x CALL s1(f(x)) CALL s2(f(x)) CALL s3(f(x)) CONTAINS FUNCTION f(a) REAL,POINTER :: f REAL,TARGET :: a f => a END FUNCTION SUBROUTINE s1(variable) variable = 42 ! statement 1 END SUBROUTINE SUBROUTINE s2(variable) INTENT(OUT) variable variable = 42 ! statement 2 END SUBROUTINE SUBROUTINE s3(targ) REAL,TARGET :: targ REAL,POINTER :: p p => targ PRINT *,ASSOCIATED(p,x) ! statement 3 END SUBROUTINE END Is this program standard-conforming, and if so, what value is printed? The real question is whether an expression argument that is a pointer function reference is treated as a variable (data-object) argument with the variable being the target of the pointer expression. (Or whether it is dereferenced as usual in the absence of POINTER dummy arguments). Re (statement 1), the question is whether VARIABLE is definable when argument-associated with "F()". Re (statement 2), if the previous answer was Yes (VARIABLE is definable), then presumably it can be made INTENT(OUT). A random sample of 4 compilers revealed that they considered it not to be definable. Re (statement 3), the question is whether P is pointer-associated with X, not pointer-associated with X, or processor-dependent. Of the same random sample 3 thought it was associated with X, 1 thought not. ANSWER: These answers are in the context of Fortran 2003. 1. The call to s1 is not standard conforming. 5.1.2.7 states "If no INTENT attribute is specified for a dummy argument, its use is subject to the limitations of the associated actual argument." The associated actual argument is the function reference f(x); this is an expression, not a variable, and therefore not definable, because only variables can be defined (in the sense of being given a value, see 2.4.3.1.1 and 2.5.5). 2. The call to s2 is not standard conforming. 12.4.1.2 says: "If a nonpointer dummy argument has INTENT(OUT) or INTENT(INOUT), the actual argument shall be definable." Again the actual argument is a function reference, which is not definable. 3. The call to s3 is standard conforming and the pointer assignment in s3 causes p and x to become associated. This may be deduced from 12.4.1.2, which says [270:5-9] "If the dummy argument has the TARGET attribute, does not have the VALUE attribute, and is either a scalar or an assumed-shape array, and the corresponding actual argument has the TARGET attribute but is not an array section with a vector subscript then (1) Any pointers associated with the actual argument become associated with the corresponding dummy argument on invocation of the procedure ..." EDITS: None SUBMITTED BY: Malcolm Cohen HISTORY: 99-198 m150 F95/0074 submitted WG5/N1414 Draft answer 00-260 m154 Passed by J3 meeting 00-329 m155 Failed J3 letter ballot 04-311 m168 Passed by J3 meeting vote - alternate answer removed 04-417r1 M170 Passed by J3 letter ballot #8 05-180 m172 Failed WG5 ballot N1617 08-172 m184 Revised answer - Passed by J3 meeting 08-259 m185 Passed by J3 letter ballot #17 08-213 N1770 m187 Passed WG5 ballot 6 N1764-N1765 as revised 09-006T4 m187 N1773 interps for F2003 Corr 4 == N1775 ---------------------------------------------------------------------- NUMBER: F95/000078 TITLE: Resolving generic procedure references KEYWORDS: INTENT(IN), NULLIFY DEFECT TYPE: Erratum QUESTION: 14.1.2.4 (Resolving procedure references) seems to fail to resolve the following example. Consider: INTERFACE sin CHARACTER FUNCTION sinch(c) CHARACTER,INTENT(IN) :: c END END INTERFACE PRINT *,sin(3.5) ! Reference to which procedure? END According to rule (1)(a), SIN is established to be generic; thus references are resolved by the rules in 14.1.2.4.1. In 14.1.2.4.1: Rule (1) fails - the reference is not consistent with any specific interface in the interface block for SIN. Rule (2) fails for the same reason. Rule (3) fails because there is no INTRINSIC statement. Rule (4) fails because there is no host scoping unit. Is this program legal? How should the reference to the generic procedure be resolved? ANSWER: This program was intended to be valid. The reference is to the intrinsic SIN. An edit is supplied to clarify this. DISCUSSION: (1) INTERFACE OPERATOR(+) does not hide the intrinsic operator. (2) CHARACTER SIN does not hide the intrinsic function. Given that, it would seem perverse for INTERFACE SIN to completely block the intrinsic. Indeed, according to interp F90/000054 the intrinsic is still accessible in this kind of situation. Furthermore, it is clear from the original version of Fortran 90 that a user generic was not intended to hide the intrinsic. This text was modified by interpretation F90/000083 which allowed the user to override an intrinsic function by providing a specific function with the same argument characteristics. The failure of the current 14.1.2.4.1 to resolve the above example was an inadvertent side-effect of that change. EDITS: [278:5+] Append new paragraph "If (1), (2), (3) and (4) do not apply, the name is that of an intrinsic procedure, and the reference is consistent with the interface of that intrinsic procedure, then the reference is to that intrinsic procedure." {Note: This edit made to Fortran 2003 in WG5/N1620 is made as item (5), not as a new paragraph.} SUBMITTED BY: Malcolm Cohen HISTORY: 99-202 m150 submitted F95/0078 04-296r1 m168 Passed J3 meeting vote 04-417r1 m170 Passed by J3 letter ballot #8 05-180 m172 Passed by WG5 ballot N1617 06-006T2 m177 N1666 interps for F2003 Corr 2 == N1664 ---------------------------------------------------------------------- NUMBER: F95/000096 TITLE: End-of-record and PAD KEYWORDS: End-of-record, PAD DEFECT TYPE: Erratum Subclause 9.4.3 specifies: If an end-of-record condition occurs during execution of a nonadvancing input statement, the following occurs: if the PAD= specifier has the value YES, the record is padded with blanks (9.4.4.4.2) to satisfy the input list item and corresponding data edit descriptor that require more characters than the record contains; There appears to be a problem if a list item does not correspond to exactly one edit descriptor. QUESTION: If an End-of-record condition occurs during execution of a nonadvancing input statement and the PAD= specifier has the value YES (1) do enough blanks get supplied for the next data edit descriptor and whatever part of the list item corresponds to that edit descriptor, or (2) do enough blanks get supplied for the remainder of the list item and as many edit descriptors as necessary, or (3) do enough blanks get supplied to process the rest of the input list? ANSWER: The situation can only arise for list items of complex type, because list items of derived type are processed as if their components had appeared as list items -- see [149:8-10]. It is clear from text at [150:15] and [153:13] that blanks are not supplied for more than one list item. So the answer to part (3) of the question is "no". Since the texts at [150:15] and [153:13] also refer to a single format item, this leaves the answer to parts (1) and (2) of the question ambiguous: Is it one list item, or one edit descriptor? The answer is that enough blanks are supplied by the processor to satisfy all of the edit descriptors for a list item. EDITS: Fortran 2003 introduced the concept of an "effective list item," which should be exploited to clarify this question. [198:12] Replace "input item and its corresponding data edit descriptor" by "effective input item and its corresponding data edit descriptors". [218:6-7] Replace "input list item (9.5.3.4.2) and corresponding data edit descriptor that requires" by "effective input item (9.5.2) and its corresponding data edit descriptors that require". SUBMITTED BY: Van Snyder HISTORY: 01-340 m158 submitted F96/0096 04-303 m168 Passed by J3 meeting vote 04-417r1 m170 Pass by J3 letter ballot #8 05-180 m172 Passed by WG5 ballot N1617 06-006T2 m177 N1666 interps for F2003 Corr 2 == N1664 ---------------------------------------------------------------------- NUMBER: F95/0098 TITLE: Are dummy functions returning assumed-length character legal? KEYWORDS: Dummy function, assumed-length character DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot QUESTION: (1) Is a dummy function allowed to have assumed character length? (2) If so, can it be invoked directly from that scoping unit? (3) If so, is this still true if the invoked function itself has a result variable that is assumed-length (this is obsolescent). (4) If an assumed-length function is declared in another scoping unit as a specific length, can it be passed as an actual argument that corresponds to a dummy function of that specific length and be invoked via the dummy function? (5) Clarification request - see discussion - Example 1 does not have any external function with assumed character length, so does it use any obsolescent feature or not? Example 1 (for questions 1 and 2): PROGRAM EX1 CHARACTER F*5 EXTERNAL F CALL S(F) END SUBROUTINE S(D) CHARACTER D*(*) PRINT *,D() END CHARACTER*5 FUNCTION F() F = 'OK' END Example 2 (for question 3): The same as example 1 except for F which is assumed-length, making the whole example 2: PROGRAM EX2 CHARACTER F*5 EXTERNAL F CALL S(F) END SUBROUTINE S(D) CHARACTER D*(*) PRINT *,D() END CHARACTER*(*) FUNCTION F() F = 'OK' END Example 3 (for question 4): The same as example 3 except that S declares the dummy function with a specific length, making it: PROGRAM EX3 CHARACTER F*5 EXTERNAL F CALL S(F) END SUBROUTINE S(D) CHARACTER D*5 PRINT *,D() END CHARACTER*(*) FUNCTON F() F = 'OK' END DISCUSSION: Examples 2 and 3 use the obsolescent feature of "assumed length character for an external function". It seems ambiguous whether example 1 uses an obsolescent feature: by C416 and the text of 4.4.4.1 it would apparently not be obsolescent but by C417 it would appear to be obsolescent. Example 1 does not use any feature described in Annex B, which implies that it is not obsolescent. It would be nice to clarify this. A straightforward reading of the literal words of the standard appears to indicate that example 1 is standard-conforming, but that example 2 is not valid due to it violating item 4 of the list at the end of subclause 4.4.4.1 (page 41). Similarly, example 3 would appear to be invalid by the same rule: this last certainly seems counter-intuitive, but does seem to be what the standard literally says. The basic issue underlying examples 1 and 2 is that the standard says "If used to declare a dummy argument of a procedure, the dummy argument assumes the length of the associated actual argument." It has been argued that this should only apply to dummy variables and not to dummy functions, but that is not what the standard says. ANSWER: (1) Yes, a dummy function is allowed to have assumed length; this is clearly implied by the permission given in C417. (2) Yes, there is no prohibition against invoking such a function. (3) Yes, the actual invoked function may have an assumed-length result. The prohibition against this in item (4) is an error; an edit is supplied to correct this. (4) Yes, this is also valid. The prohibition against this in item (4) is in error; an edit is supplied to correct this. (5) The implication of constraint C417 that a dummy function having assumed length is obsolescent is a typographical error: an edit is provided to correct this. EDITS: [41:11-12] In C417, change "\obs{unless ... dummy function}" to "unless it is of type CHARACTER and is the name of a dummy function \obs{or the name of the result of an external function}". {Note: \obs{...} indicates obsolescent font.} [41:34,36] At the end of 4.4.4.1, item (4), after "\obs{invoking the function}" insert "\obs{or passing it as an actual argument}"; change "\obs{host or use}" to "\obs{argument, host, or use}". SUBMITTED BY: Larry Meadows HISTORY: 02-157 m160 F95/0098 submitted 04-417r1 m170 Duplicate of interp #6 05-180 m172 Failed WG5 ballot N1617 - not a duplicate of F95 interp 000006 09-233 m188 Revised answer 09-261 m189 Revised again 09-263 m189 Rewritten and revised to cover more of the issue - Passed by J3 meeting 09-295 m190 Passed by J3 letter ballot #19 09-292 N1816 m191 Passed by WG5 ballot #7 {N1805/6} - F2008 edit in 10-138 passed m191 10-006T5 m192 N1805 interps for F2003 Corr 5 == N1815 ---------------------------------------------------------------------- NUMBER: F95/0102 TITLE: mask-expr evaluated only once KEYWORDS: WHERE DEFECT TYPE: Interpretation STATUS: Passed by WG5 ballot QUESTION: Is a mask-expr required to be evaluated in a WHERE such as: WHERE ( (/ .TRUE., .TRUE. /) ) A = A + 1 ELSE WHERE (MASKF()) A = MAX END WHERE where an optimizing compiler might notice that the ELSEWHERE branch will never be executed ? Page 112, line 38 says of the mask expression in ELSEWHERE statements "The mask-expression is evaluated only once." ANSWER: The above quote is from the Fortran 95 standard. In Fortran 2003 the mask expression in an ELSEWHERE is not required to be evaluated, and this is made clear by the fourth paragraph of 7.4.3.2 (at [147:7]) which, referring to a masked ELSEWHERE statement, states "The is evaluated at most once." This also applies to the mask expressions of nested WHERE construct statements; this is made clear by the last sentence of the seventh paragraph of 7.4.3.2 (at [147:16]) which also states that it is evaluated "at most once". However, this does not apply to the mask expression of the outermost WHERE construct statement, which must be evaluated exactly once; this is made clear by the last statement of the first paragraph of 7.4.3.2 (at [147:1]) which states that this mask expression is evaluated "only once". That does not guarantee invocation of functions in that expression if they are not required to determine its value. EDITS: None SUBMITTED BY: Matthijs van Waveren HISTORY: 03-239 m165 F95/0102 Passed by J3 meeting 04-417r1 m170 Passed by J3 letter ballot #8 05-180 m172 Failed WG5 ballot N1617 08-171 m184 Revised answer - Passed by J3 meeting 08-259 m185 Passed by J3 letter ballot #17 08-213 N1770 m187 Passed WG5 ballot 6 N1764-N1765 09-006T4 m187 N1773 interps for F2003 Corr 4 == N1775 ---------------------------------------------------------------------- ====================================================================== Part 2: Fortran 2003 Interpretations included in Tecnical Corrigenda ====================================================================== NUMBER: F03/0001 TITLE: Generic type-bound procedures KEYWORDS: generic, type-bound DEFECT TYPE: Interpretation STATUS: Included in F03 corrigendum 1 QUESTION: Section 12.4.5 discusses how a in a (R1219) is resolved if the is that of a generic type-bound procedure. This seems to imply that it is intended to be possible to invoke a generic type-bound procedure (which one might have guessed anyway :-)). However, according to the bnf in 4.5.4, only a specific binding has a . The in is a list of specific binding names. Thus the discussion of generic s in 12.4.5 is moot, there being no such things. Consequently, R1219 appears to provide no syntax for invoking generic type-bound procedures. Should R1219 and 12.4.5 be modified to allow a reference of the form " % " where is the name of a generic binding of the declared type of ? ANSWER: No. As is, the standard provides syntax for invoking a generic type-bound procedure. DISCUSSION: There is no explicit BNF definition of in 4.5.4 or elsewhere; therefore it's use in R1219 is, by our implicit BNF rules, simply equivalent to with the only constraints being those specified for R1219. In R1219, is allowed and indeed required to be a "binding name". This is a technical term defined in 4.5.4 (at [57:23-26]) to mean both the of a specific type- bound procedure and the of a generic type-bound procedure. Thus all of the analysis in the question is based on a false premise. EDITS: None. SUBMITTED BY: Richard Maine HISTORY: 04-320 m169 Submitted F03/0001 04-320r1 m169 Passed by J3 meeting 04-418r1 m170 Passed J3 letter ballot #9 05-180 m172 Passed by WG5 ballot N1617 05-182r1 m172 Added to F03 Corrigendum 1 N1636 - no edits ---------------------------------------------------------------------- NUMBER: F03/0002 TITLE: Component value for pointer components KEYWORDS: component, value, pointer DEFECT TYPE: Interpretation STATUS: Included in F03 corrigendum 1 QUESTION: According to 4.5.7, the component value for an allocatable component includes the bounds if the component is allocated. However, no mention is made of the bounds of pointer components. It is possible for pointers with different bounds to be associated with the same target (13.7.13); therefore, I conclude that the bounds are not part of the association. Is it standard conforming for a processor to print 1 as a result of the following program? program me type t integer, pointer :: p(:) end type t type(t) :: x allocate(x%p(3:5)) call sub(x) contains subroutine sub(y) type(t), value :: y write (*,*) lbound(y%p) end subroutine sub end program me ANSWER: No, a processor is required to print 3 as a result of the above program. The conclusion that the bounds are not part of a pointer's association is incorrect. DISCUSSION: The analysis appears to be based on the theory that the ASSOCIATED intrinsic function defines what is meant by "pointer association". In fact, the 1-argument form of that function only returns the pointer association *status*, and the 2-argument form only tests the association between a pointer and a target - it does not compare the pointer association of two pointers. If the bounds were not part of "pointer association", non-component pointers would be similarly faulty. Pointer association is established by the ALLOCATE statement (6.3.1.2) and pointer assignment (7.4.2.1). Both of these specify array bounds for the association. These are the defining sections for pointer association, and therefore, the bounds form part of that association. It is recommended that a future revision of the standard contain a more comprehensible definition of the term "pointer association". EDITS: None. SUBMITTED BY: Richard Maine HISTORY: 04-321 m169 Submitted F03/0002 04-321r1 m169 Passed by J3 meeting 04-418r1 m170 Passed J3 letter ballot #9 05-180 m172 Passed by WG5 ballot N1617 05-182r1 m172 Added to F03 Corrigendum 1 N1636 - no edits ---------------------------------------------------------------------- NUMBER: F03/0003 TITLE: Referencing deferred bindings KEYWORDS: Type-bound procedure, deferred binding DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot QUESTION: I thought that the intent was that it would be impossible to reference a deferred binding. However, it doesn't appear to me that this intent was achieved. Consider the following program (Sorry, but I don't have any compilers up to syntax-checking this). module defer type, abstract :: t contains procedure (sub), nopass, deferred :: deferred_proc end type t type, extends(t) :: t2 contains procedure, nopass :: deferred_proc => sub2 end type t2 contains subroutine sub write (*,*) 'Hello.' end subroutine sub subroutine sub2 write (*,*) 'Goodbye.' end subroutine sub2 end module defer program p use defer class(t), pointer :: x nullify(x) call x%deferred_proc end program p Is this a valid program? If not, what restriction of the standard does it violate? Note that x%deferred_proc does not require the value of x (4.5.7) and thus is not a reference to x (2.5.6). Therefore, [83:23-24] does not prohibit this. Nor is it clear that there is an intent to prohibit invocation of type-bound procedures for disassociated pointer objects; except in the case of deferred bindings, this seems well-defined and potentially useful. Because x is disassociated, its dynamic type is the same as its declared type, thus making the interpretation of x%nondeferred_proc reasonably clear. ANSWER: No, this was not intended to be a valid program. A type-bound procedure may not be invoked through an undefined pointer, a disassociated pointer, or an unallocated allocatable variable. An edit is supplied to clarify this situation. The same answer and edit also apply to F03/0004. EDITS: All edits refer to 04-007. Insert after [04-007: 266:24]: "The shall not be an unallocated allocatable variable or a pointer whose association status is disassociated or undefined." Note: this is the same edit as interp F03/0004. SUBMITTED BY: Richard Maine HISTORY: 04-322 m169 F03/0003 Submitted 04-322r1 m169 Passed by J3 meeting 04-418r1 m170 Subsumed by interp F03/0004 05-180 m172 Failed WG5 ballot N1617 - the edit is subsumed by F03/0004 07-280 m182 Revised 07-280r1 m182 Passed by J3 meeting 08-133r2 m183 Passed by letter ballot #15 08-101 08-164r1 m184 Passed WG5 ballot #5 N1722-N1726 with a changed edit 09-006T4 m187 N1773 interps for F2003 Corr 4 == N1775 ---------------------------------------------------------------------- NUMBER: F03/0004 TITLE: Type-bound procedures and undefined association status KEYWORDS: Type-bound procedure, dynamic type DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot QUESTION: It appears that the dynamic type is undefined for a pointer with undefined association status. This impacts type-bound procedures. Consider the following program. module undefined type :: t contains procedure, nopass :: nondeferred_proc => sub end type t type, extends(t) :: t2 contains procedure, nopass :: nondeferred_proc => sub2 end type t2 contains subroutine sub write (*,*) 'Hello.' end subroutine sub subroutine sub2 write (*,*) 'Goodbye.' end subroutine sub2 end module undefined program p use undefined class(t), pointer :: x call x%nondeferred_proc end program p Is this a valid program? If not, what restriction of the standard does it violate? If so, what does it print. Note that x%nondeferred_proc does not require the value of x (4.5.7) and thus is not a reference to x (2.5.6). Therefore, [83:23-24] does not prohibit this. If x were disassociated, its dynamic type would be t and the interpretation of this would be reasonably clear. However, the standard does not appear to specify the dynamic type of x when its association status is undefined. Nor can I find any prohibition that applies to this case. ANSWER: No, the program is not valid, because the standard does not establish an interpretation of it. An edit is supplied to clarify this. Furthermore, the case with a disassociated pointer was not intended to be valid. An edit is supplied to correct this oversight. DISCUSSION: Access to object-bound procedures (a.k.a. procedure pointer components) always require there to be an object. Access to type-bound procedures of an object was intended to require this too, but the effect of the NOPASS attribute on this was overlooked. EDITS: All edits refer to 04-007. Insert after [04-007: 266:24]: "The shall not be an unallocated allocatable variable or a pointer whose association status is disassociated or undefined." Note: this is the same edit as interp F03/0003. SUBMITTED BY: Richard Maine HISTORY: 04-323 m169 F03/0004 submitted 04-323r1 m169 Passed by J3 meeting 04-418r1 m170 Passed J3 letter ballot #9 05-180 m172 Failed WG5 ballot N1617 07-337 m182 Passed by J3 meeting 08-133r2 m183 Passed by letter ballot #15 08-101 08-164r1 m184 Passed WG5 ballot #5 N1722-N1726 with a changed edit 09-006T4 m187 N1773 interps for F2003 Corr 4 == N1775 ---------------------------------------------------------------------- NUMBER: F03/0005 TITLE: Argument association and the TARGET attribute KEYWORDS: argument, association, target, pointer DEFECT TYPE: Erratum STATUS: Included in F03 corrigendum 1 QUESTION: Fortran 95 allowed the following program to print "T". Fortran 2003 does not appear to allow this. module m integer, pointer :: i_ptr contains subroutine sub(j) integer j call sub2(j) end subroutine subroutine sub2(j2) integer, target :: j2 print *, associated (i_ptr, j2) end subroutine end module program foo use m integer, target :: i i_ptr => i call sub(i) end program Fortran 95 stated, in section 12.4.1.1, on page 200: If the dummy argument does not have the TARGET or POINTER attribute, any pointers associated with the actual argument do not become associated with the corresponding dummy argument on invocation of the procedure. If such a dummy argument is associated with a dummy argument with the TARGET attribute, whether any pointers associated with the original actual argument become associated with the dummy argument with the TARGET attribute is processor dependent. Fortran 2003 (04-007) states, in section 12.4.1.2, on page 269: If the dummy argument does not have the TARGET or POINTER attribute, any pointers associated with the actual argument do not become associated with the corresponding dummy argument on invocation of the procedure. If such a dummy argument is associated with an actual argument that is a dummy argument with the TARGET attribute, whether any pointers associated with the original actual argument become associated with the dummy argument with the TARGET attribute is processor dependent. It's clear in this example that j is not associated with i_ptr, because it doesn't have the TARGET attribute. The dummy argument j2 with the TARGET attribute falls into the case described by the second sentence quoted from Fortran 95. It does not fall into the case described by the second sentence quoted from Fortran 2003, since j is not associated with an actual argument that is a dummy argument with the TARGET attribute. It appears that the second sentence in Fortran 2003 gets things backwards. Was it intended in the example above that the program should be allowed to print "T"? ANSWER: Yes. An edit is supplied to correct this error. EDITS: All edits refer to 04-007. [270:1-2] Change "associated with an actual argument that is" to "used as an actual argument that is associated with". REFERENCES: 02-148r1 inserted this clarification but it is incorrect. SUBMITTED BY: Rob James HISTORY: 04-330 m169 Submitted F03/0005 04-330r1 m169 Passed by J3 meeting 04-418r1 m170 Passed J3 letter ballot #9 05-180 m172 Passed by WG5 ballot N1617 05-182r1 m172 Added to F03 Corrigendum 1 N1636 ---------------------------------------------------------------------- NUMBER: F03/0006 TITLE: Intrinsic assignment and allocatable components KEYWORDS: assignment, allocatable DEFECT TYPE: Erratum STATUS: Included in F03 corrigendum 1 QUESTION: Consider the following code: type t integer, allocatable :: i end type type(t) :: x allocate(x%i) x = x print *, allocated(x%i) end In the intrinsic assignment, it is unclear whether the value of the expression on the right-hand side of the assignment should be determined before the any part of the left-hand side becomes defined. Section 7.4.1.3 of Fortran 2003 states: The execution of the assignment shall have the same effect as if the evaluation of all operations in and occurred before any portion of is defined by the assignment. In this case, there are no operations in , so this sentence does not apply. There doesn't appear to be anything else to cover this situation, so it appears that in this case, does not have to be evaluated before any part of is defined. If x%i becomes deallocated before the is evaluated, then the call to the ALLOCATED intrinsic in this example would return the value .false. Was it intended that this program could print "F"? ANSWER: No. It was intended that the in an intrinsic assignment must be evaluated before any part of the is defined. An edit is supplied to correct this oversight. EDITS: All edits refer to 04-007. [139:17] Change "the evaluation of all operations in and " to "the evaluation of and the evaluation of all expressions in ". [141:20,21,22] Before "" insert "the value of", thrice. SUBMITTED BY: Rob James HISTORY: 04-331 m169 Submitted F003/0006 04-331r1 m169 Passed by J3 meeting 04-418r1 m170 Passed J3 letter ballot #9 05-180 m172 Passed by WG5 ballot N1617 05-182r1 m172 Added to F03 Corrigendum 1 N1636 ---------------------------------------------------------------------- NUMBER: F03/0007 TITLE: Finalization of structure constructors in specifications KEYWORDS: finalization, structure constructor, specification expression DEFECT TYPE: Erratum STATUS: Included in F03 corrigendum 1 QUESTION: Paragraphs 3-5 of subclause 4.5.5.2 specify when finalization occurs for function results in executable constructs and in specification expressions. They also specify when finalization occurs for structure constructors in executable constructs. However, structure constructors in specification expressions do not appear to be mentioned. The apparent conclusion would be that structure constructors in specification expressions are not finalized, which seems inconsistent and contrary to the purpose of finalization. Q1. Are structure constructors in specification expressions finalized? If so, when? The phrase "before the first executable statement in a scoping unit" is used in two places in the standard (4.5.5.2 and at [116:8] after note 6.24) to describe the first thing executed in a scoping unit. This phrase has two problems. First, not all executable statements can be executed as single statements; the description of execution sequence is in terms of executable constructs rather than executable statements. (See 2.3.4, 8.1.1.3, and 12.5.2.0). Although this distinction seems unlikely to lead to confusion, the terminology seems inconsistent. Second, and more problematic, is that the first executable statement or construct in a scoping unit is not necessarily the first thing executed in the scoping unit; nor is it necessarily executed only once. An entry statement may cause execution to start at some other executable construct, in which case one might wonder whether the specified actions ever happen. A goto might cause the construct to be executed multiple times, in which case one might wonder whether the specified actions happen again. I seriously doubt that either of these represent the intent. Q2. If an event is specified to occcur before the first executable statement in a scoping unit, then for a single execution of that scoping unit, may the event happen zero times, multiple times, or after the execution of some other executable statement or construct in the scoping unit? ANSWER: A1. Yes, structure constructors in specification expressions are finalized. Just as with function results in specification expressions, this finalization occurs before execution of the executable constructs in the scoping unit. This was an accidental omission from the standard. Edits are supplied to correct it. A2. No. The intent is to describe events that happen once and only once per execution of a procedure defined by a scoping unit. Edits are supplied to state this more precisely. EDITS: All edits refer to 04-007. [59:30] and [116:8] Change "first executable statement" -> "executable constructs" [59:30+] Insert new para "If a specification expression in a scoping unit references a structure constructor, the entity created by the structure constructor is finalized before execution of the executable constructs in the scoping unit." SUBMITTED BY: Richard Maine HISTORY: 04-332 m169 Submitted F03/0007; Passed by J3 meeting 04-418r1 m170 Passed J3 letter ballot #9 05-180 m172 Passed by WG5 ballot N1617 05-182r1 m172 Added to F03 Corrigendum 1 N1636 ---------------------------------------------------------------------- NUMBER: F03/0008 TITLE: Pointer assignment and arrays KEYWORDS: pointer assignment, array, data-ref DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot QUESTION: There appears to be no explicit requirement that the s in R736 and R741 be scalar. If data-pointer-object and proc-component ref were data-refs, then C614 would prohibit the s from being arrays. However, although the syntax looks like a special case of a data-ref, nothing appears to say that R736 and R741 actually constitute data-refs. The standard gives no interpretation as to what the meaning would be in the case of an array. Even when variable is a scalar, the standard does not appear to define what the properties (such as type and shape) of a data-pointer-object or proc-pointer-object are in the case where the syntax has a "%". All we have is a syntax with no established meaning. Q1. Is the in R736 or R741 allowed to be an array? Q2. Is the interpretation of the forms in R736 and R741 the same as that of a data-ref? ANSWER: A1. No. The standard provides no interpretation of what such a form would mean. Therefore, by the first sentence of 1.5, it is not standard-conforming. Edits are provided to make this prohibition more direct. A2. Yes. EDITS: All edits refer to 04-007. [143:12,24,35,37] Insert "" before "", four times. SUBMITTED BY: Richard Maine HISTORY: 04-333 m169 F03/0008 Submitted 04-333r1 m169 Passed by J3 meeting 04-418r1 m170 Failed J3 letter ballot #9 04-421 m170 Revised - Passed by J3 meeting 05-146 m171 Passed J3 letter ballot #10 N1658 m176 Passed WG5 ballot N1657 N1663 Reaffirmed in WG5 ballot N1661 on N1660 06-006T2 m177 N1666 interps for F2003 Corr 2 == N1664 ---------------------------------------------------------------------- NUMBER: F03/0009 TITLE: VALUE attribute for passed-object dummy arguments KEYWORDS: VALUE, passed-object, dummy argument DEFECT TYPE: Erratum STATUS: Included in F03 corrigendum 1 QUESTION: Consider the following program: module m type t integer :: id contains procedure :: doThings => doThingsT end type contains subroutine doThingsT (a) class(t), value :: a a%id = 5 end subroutine end module program p use m type(t) :: z = t(1) call z%doThings print *, z%id end program Section 12.4.1.1 of Fortran 2003 states: In a reference to a type-bound procedure that has a passed-object dummy argument (4.5.3.3), the of the or is associated, as an actual argument, with the passed-object dummy argument. This seems to be contrary to the idea of the VALUE attribute. For argument association where the dummy argument has the VALUE attribute, section 12.4.1.2 of Fortran 2003 states: If the dummy argument has the VALUE attribute it becomes associated with a definable anonymous data object whose initial value is that of the actual argument. Subsequent changes to the value or definition status of the dummy argument do not affect the actual argument. It looks like the passed-object dummy argument is argument associated with the object z itself, rather than an anonymous data object whose initial value is that of z. What value should the above program print? ANSWER: This program was not intended to be standard-conforming; the VALUE attribute is not appropriate for a passed-object dummy argument. Edits are supplied to clarify this situation. DISCUSSION: As perhaps evidenced by its own name, the passed-object dummy argument was intended to be THE object through which the type-bound procedure was invoked. It performs the same function as the "self" or "this" variable of other object-oriented languages. EDITS: All edits refer to 04-007. [53:1] Append to constraint "It shall not have the VALUE attribute." SUBMITTED BY: Rob James HISTORY: 04-334 m169 Submitted F03/0009 04-334r1 m169 Revised 04-334r2 m169 Passed by J3 meeting 04-418r1 m170 Passed J3 letter ballot #9 05-180 m172 Passed by WG5 ballot N1617 05-182r1 m172 Added to F03 Corrigendum 1 N1636 ---------------------------------------------------------------------- NUMBER: F03/0010 TITLE: Unlimited polymorphic pointer/allocatable dummy arguments KEYWORDS: polymorphism, POINTER, ALLOCATABLE, argument DEFECT TYPE: Erratum STATUS: Included in F03 corrigendum 1 QUESTION: Consider the following program: module m type t integer i end type contains subroutine s (x) class (*), pointer, intent(inout) :: x end subroutine end module program p use m class (*), pointer :: up class (t), pointer :: lp call s (lp) call s (up) end program Section 12.4.1.2 states: If a dummy argument is allocatable or a pointer, the associated actual argument shall be polymorphic if and only if the dummy argument is polymorphic, and the declared type of the actual argument shall be the same as the declared type of the dummy argument. Section 5.1.1.2 states: An object declared with the CLASS(*) specifier is an unlimited polymorphic object. An unlimited polymorphic entity is not declared to have a type. It is not considered to have the same declared type as any other entity, including another unlimited polymorphic entity. Taken together, these two statements seem to imply that no unlimited polymorphic dummy argument that has the ALLOCATABLE or POINTER attribute can be associated with any actual argument. Are either of the procedure calls in the given example standard-conforming? ANSWER: The first procedure call is not standard-conforming. The second procedure call was intended to be standard-conforming. Edits are provided to correct this oversight. EDITS: All edits refer to 04-007. [268:23] Before "the declared", insert "either both the actual and dummy argument shall be unlimited polymorphic, or". SUBMITTED BY: Rob James HISTORY: 04-335 m169 Submitted F03/0010; Passed by J3 meeting 04-418r1 m170 Passed J3 letter ballot #9 05-180 m172 Passed by WG5 ballot N1617 05-182r1 m172 Added to F03 Corrigendum 1 N1636 ---------------------------------------------------------------------- NUMBER: F03/0011 TITLE: Allocating objects of abstract types KEYWORDS: ALLOCATE, ABSTRACT DEFECT TYPE: Erratum STATUS: Included in F03 corrigendum 1 QUESTION: Consider the following code: module m type, abstract :: t integer :: i end type class(t), allocatable :: d end module program foo use m allocate(d) end One cannot declare a non-polymorphic object of an abstract type. Similarly, a polymorphic object should not be allocated with a dynamic type that is abstract. A in an allocate statement cannot specify an abstract type. But the effect of the allocate statement in the example above is the same as if a specifying an abstract type appeared in the allocate statement, which would not be standard-conforming. Was this example intended to be standard-conforming? ANSWER: No, this example was not intended to be standard-conforming. An edit is provided to correct this oversight. EDITS: All edits refer to 04-007. [111:11-12] Change the words "unlimited polymorphic" in the constraint to "unlimited polymorphic or is of abstract type" so that it reads: C625 (R623) If any is unlimited polymorphic or is of abstract type, either or SOURCE= shall appear. SUBMITTED BY: Rob James HISTORY: 04-336 m169 Submitted F03/0011 04-336r2 m169 Passed by J3 meeting 04-418r1 m170 Passed J3 letter ballot #9 05-180 m172 Passed by WG5 ballot N1617 05-182r1 m172 Added to F03 Corrigendum 1 N1636 ---------------------------------------------------------------------- NUMBER: F03/0012 TITLE: Procedure pointers and the EXTERNAL attribute KEYWORDS: Procedure pointers, EXTERNAL DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot QUESTION: Is the following program unit standard conforming? SUBROUTINE SUB ( RPP ) REAL, EXTERNAL, POINTER :: RPP EXTERNAL :: PP POINTER :: PP PROCEDURE(REAL), POINTER :: PPP => NULL() END SUBROUTINE SUB The last sentence of "5.1.2.6 EXTERNAL attribute" appears to indicate that it is allowed: "A procedure that has both the EXTERNAL and POINTER attributes is a procedure pointer." That the title of subclause 12.2.1.2 is "Characteristics of dummy procedures and dummy procedure pointers" suggests that it is allowed. That subclause continues "... whether it is a pointer, ..." so it was clearly envisioned that at least dummy procedures could have the POINTER attribute. C1216 [264:30] appears to require PPP to be allowed: "C1216 (R1214) If => appears in , the procedure entity shall have the pointer attribute." On the other hand, A conspiracy of C512 [72:28-29] "C512 (R501) If the POINTER attribute is specified, the ALLOCATABLE, TARGET, EXTERNAL, or INTRINSIC attribute shall not be specified." the second sentence of subclause 5.1.2.6 [80:38-40] "This [EXTERNAL] attribute may also be specified by ... a ..." the first paragraph of subclause 5.2 [85:15ff] "The combination of attributes that may be specified for a particular entity is subject to the same restrictions ... regardless of the method of specification. This also applies to the PROCEDURE, EXTERNAL and INTRINSIC statements." and the last sentence of the first paragraph of 12.3.2.3 [264:8] "It [the procedure declaration statement] specifies the EXTERNAL attribute...." appears to completely wipe out procedure pointers (PPP because of the first paragraph of 12.3.2.3). C521 [73:6-7] and C568 [91:5] also appear to prohibit RPP and PP: "C521 (R504) The shall be the name of an external function, a function dummy procedure{, or a statement function}." "C568 (R541) A shall also be declared in a ." But then the first paragraph after R1210 (defining the EXTERNAL statement) [264:1] appears to allow RPP and PP: "Each shall be the name of ... a procedure pointer...." There is also a problem with protected procedure pointers. C535 clearly envisions their existence: "C535 (R501) The PROTECTED attribute is permitted only for a procedure pointer...." while C536 prohibits their existence: "C536 (R501) If the PROTECTED attribute is specified, the EXTERNAL ... attribute shall not be specified." ANSWER: The discussion of procedure pointers is indeed inconsistent. The program unit is intended to be standard conforming. It was an oversight during the development of the procedure pointer facility that the EXTERNAL attribute was not removed from C512, that "procedure pointer" was not added to C521, that C535 and C536 contradict one another, and that an external statement and specifying the EXTERNAL attribute in a type declaration statement were not allowed in C568. It is not helpful that the last sentence of the first paragraph of subclause 5.2 refers to "PROCEDURE ... statements" (which could be confused with the PROCEDURE statement in an interface block) where it should refer to "procedure declaration ... statements." EDITS: Delete ", EXTERNAL" from C512 [72:28]. Insert ", a procedure pointer" after "dummy procedure" in C521 [73:7]. Replace C536 [73:35-36]: "C536 (R501) If the PROTECTED attribute is specified, the INTRINSIC or PARAMETER attribute shall not be specified. If the PROTECTED and EXTERNAL attributes are specified, the POINTER attribute shall also be specified." Replace the last sentence of the first paragraph of subclause 5.2 [86:1] by "This also applies to procedure declaration statements, and to EXTERNAL and INTRINSIC statements." Replace C568 [91:5]: "C568 (R541) The EXTERNAL attribute (5.1.2.6) shall be explicitly specified for a ." SUBMITTED BY: Van Snyder HISTORY: 04-358 m169 F03/0012 Submitted 04-358r2 m169 Revised 04-418r1 m170 Failed J3 letter ballot #9 04-401r2 m170 Passed by J3 meeting 05-146 m171 Passed J3 letter ballot #10 N1658 m176 Passed WG5 ballot N1657 - fix typo N1663 Reaffirmed in WG5 ballot N1661 on N1660 06-006T2 m177 N1666 interps for F2003 Corr 2 == N1664 ---------------------------------------------------------------------- NUMBER: F03/0013 TITLE: VALUE attribute for polymorphic dummy arguments KEYWORDS: VALUE, CLASS DEFECT TYPE: Erratum STATUS: Included in F03 corrigendum 1 QUESTION: The VALUE attribute is not allowed for any dummy argument that has a (visible) nonconstant length type parameter. (Or indeed for any array.) The intent appears to be to restrict VALUE arguments to being of constant size. However consider: SUBROUTINE S(x) CLASS(t),VALUE :: x ... There is no requirement that X not be polymorphic, so this requires copying a variable (known only at runtime) sized value, in violation of the apparent intent of the other restrictions. For example, X might have an invisible nonconstant length type parameter in its dynamic type; this allows the user to bypass that particular VALUE restriction simply by obfuscating his code so that the nonconstant length type parameter is in the dynamic type but not in the declared type. Should there be a restriction that a VALUE dummy argument not be polymorphic? ANSWER: Yes, this restriction was accidentally omitted. An edit is provided to fix this oversight. DISCUSSION: The deduced intent is apparent from the rejection of the UK comment C7 on the FCD ballot. WG5 agreed that the existing constraint was inconsistent, but felt that there were potential implementation concerns with deleting it completely. Therefore, the constraint was instead modified to a simpler and more consistent form. EDITS: All edits refer to 04-007. [72:23] Append "It shall not have the VALUE attribute." SUBMITTED BY: Malcolm Cohen HISTORY: 04-360 m169 Submitted F03/0013; Passed by J3 meeting 04-418r1 m170 Passed J3 letter ballot #9 05-180 m172 Passed by WG5 ballot N1617 05-182r1 m172 Added to F03 Corrigendum 1 N1636 ---------------------------------------------------------------------- NUMBER: F03/0014 TITLE: Automatic arrays in interface bodies KEYWORDS: automatic array, interface body DEFECT TYPE: Erratum STATUS: Included in F03 corrigendum 1 QUESTION: Is the following program standard-conforming. program main interface subroutine sub(n) integer, intent(in) :: n real :: x(n) end subroutine sub end interface call sub(2) end program main subroutine sub(n) integer, intent(in) :: n real :: x(n) write (*,*) size(x) end subroutine sub The potential problem is the declaration of X in the interface body. According to C542 "An explicit-shape array whose bounds are not initialization expressions shall be a dummy argument, a function result, or an automatic array of a procedure." The definition of an automatic array is "An automatic array is an explicit-shape array that is declared in a subprogram, is not a dummy argument, and has bounds that are not initialization expressions." Although the X in subroutine sub fits this definition, the X in the interface body does not because an interface body is not a subprogram. In 12.3.2.1, at [259:36-37], we have "The specification part of an interface body may specify attributes or define values for data entities that do not determine characteristics of the procedure. Such specifications have no effect." The presumed reason for this is to allow the specification part of a procedure to be copied into an interface body. If the declarations of automatic arrays cannot be so copied, that would appear to negate the reason for the feature. ANSWER: Yes. This was intended to be standard conforming. Edits are provided to fix this error. EDITS: [78:23] "subprogram" -> "subprogram or interface body" [78:21-22] "shall be... procedure." -> "shall be declared only in a subprogram or interface body." SUBMITTED BY: Richard Maine HISTORY: 04-361 m169 Submitted F03/0014; Passed by J3 meeting 04-418r1 m170 Passed by J3 letter ballot #9 with comment 05-180 m172 Passed by WG5 ballot N1617 05-182r1 m172 Added to F03 Corrigendum 1 N1636 ---------------------------------------------------------------------- NUMBER: F03/0015 TITLE: TARGET attribute for associate names KEYWORDS: TARGET, POINTER, ASSOCIATE DEFECT TYPE: Erratum STATUS: Included in F03 corrigendum 1 QUESTION: Consider the following code: program assocTarget integer, pointer :: first_ptr integer, pointer :: second_ptr integer, target :: tgt tgt = 20 first_ptr => tgt associate(aname => first_ptr) second_ptr => aname end associate end Section 16.4.1.5 (Construct association) indicates that the associating entity aname is associated with the target of first_ptr. However, section 8.1.4.3 (Attributes of associate names) indicates that aname does not have the TARGET attribute, since this would only be true if the selector had the TARGET attribute. Was this example intended to be standard-conforming? ANSWER: Yes, this example was intended to be standard-conforming. Edits are supplied to correct this oversight. EDITS: All edits refer to 04-007. [161:18-19] Remove ", TARGET,". [161:19] After "attribute.", insert the following sentence: The associating entity has the TARGET attribute if and only if the selector is a variable and has either the TARGET or POINTER attribute. SUBMITTED BY: Rob James HISTORY: 04-366 m169 Submitted F03/0015 04-366r1 m169 Passed by J3 meeting 04-418r1 m170 Passed by J3 letter ballot #9 05-180 m172 Passed by WG5 ballot N1617 05-182r1 m172 Added to F03 Corrigendum 1 N1636 ---------------------------------------------------------------------- NUMBER: F03/0016 TITLE: Invoking type-bound procedures via array objects KEYWORDS: elemental, type-bound procedure, NOPASS attribute DEFECT TYPE:Erratum STATUS: Included in F03 corrigendum 1 QUESTION: Consider INTERFACE SUBROUTINE sub; END END INTERFACE TYPE t CONTAINS PROCEDURE,NOPASS :: p => sub END TYPE TYPE(t) x(100) CALL x%p END (1) Is this program-unit standard-conforming? If so, how many times is SUB invoked? (2) If SUB has the ELEMENTAL attribute, does this change its standard conformance? If it is conforming, how many times is it executed? Consider: TYPE t ... CONTAINS PROCEDURE ep => emp END TYPE ... ELEMENTAL SUBROUTINE emp(x) CLASS(t),INTENT(INOUT) :: x ... END SUBROUTINE ... TYPE(t) a(10) CALL a%ep (3) Is this fragment standard-conforming, and if so, is "CALL a%ep" equivalent to "CALL emp(a)"? Consider: INTERFACE ELEMENTAL SUBROUTINE esub(r); REAL,INTENT(IN) :: r; END END INTERFACE TYPE t CONTAINS PROCEDURE,NOPASS :: ep => esub END TYPE TYPE(t) x(100) REAL y(50) CALL x%ep(y) END (4) Is this standard-conforming? If so, is ESUB invoked 50 times or 100 times? ANSWER: (1) No. (2) No. (3) Yes. (4) No. If the invoking object is an array, the type-bound procedure must be elemental and have the PASS attribute. An edit is supplied to clarify this. DISCUSSION: The invoking object can only enable elementalisation if it is an actual argument, i.e. if the type-bound procedure has the PASS attribute. If the type-bound procedure does not have both the PASS and ELEMENTAL attributes, the invoking object shall be scalar. EDITS: All edits refer to 04-007. [266:24+] Insert new constraint "C1224a (R1219) If is an array, the referenced type-bound procedure shall have the PASS attribute." SUBMITTED BY: Malcolm Cohen HISTORY: 04-368 m169 Submitted F03/0016; Passed by J3 meeting 04-418r1 m170 Passed by J3 letter ballot #9 05-180 m172 Passed by WG5 ballot N1617 05-182r1 m172 Added to F03 Corrigendum 1 N1636 ---------------------------------------------------------------------- NUMBER: F03/0020 TITLE: Kinds of intrinsic type parameters KEYWORDS: type parameter, kind, intrinsic type DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot QUESTION: Q1. What are the kinds of the type parameters for intrinsic types? In most contexts, it doesn't matter. Fortran 95 did not even have the concept of the kind of a type parameter or a context in which such a thing could be detected in a standard-conforming program. Fortran 2003 added the concept in support of derived types. It also added a syntax which exposes the question for intrinsic types. Q2. What is the KIND of a type parameter inquiry? Q3. For example, consider the program program what_kind character c write (*,*) kind(c%kind) == kind(0) write (*,*) kind(c%len) == kind(0) end Are both write statements guaranteed to print .true. (meaning that the c%kind and c%len are of default kind) or not? For KIND parameters, although I can't find it explicitly stated, I see fairly strong evidence that all intrinsic kind parameters are intended to be default integers. This evidence is in the intrinsic functions. The KIND intrinsic function and all the selected_*_kind functions are specified to return default integers, which would make for some strangeness if the kind parameters were not default integer, in particular if the KIND intrinsic could not return the kind of its argument because that kind could not be represented in a default integer. There also seems no obvious benefit to having the kind of the intrinsic kind parameters be anything other than default. In practice, the number of supported values for kind is small and would have no trouble being represented in a default integer; large arrays of kind values are rare, so there isn't much benefit in using representations smaller than default. For character length, I see no similar evidence. Indeed, the LEN intrinsic seems to suggest that lengths might be other than default integer. I believe that there was clear intent to facilitate (but not require) support for character lengths longer than could be expressed by a default integer. In most contexts, it doesn't directly matter what the kind of length is. Parameter specifications in type-specs don't have to match in kind. So the user could specify and do arithmetic on lengths using whatever kind was appropriate for the anticipated problem sizes. The limit on maximum character length is processor-dependent anyway and is not necessarily the same as HUGE(whatever) (though it is a bit hard to imagine how it could usefully be larger). The only context in which I can see that might matter is in a type parameter inquiry (6.1.3). We don't appear to have defined the kind of a type parameter inquiry. Although we didn't say, I am assuming that a type parameter inquiry ought to "return" the kind of the type parameter it is inquiring about. Otherwise, there would be no way to inquire about the type parameter values of some derived type variables (if the values didn't fit in a default integer). We probably ought to explicitly say, though. ANSWER: Q1. The kind parameters of all the intrinsic types are of default integer kind. The kind parameter of the intrinsic character length parameter is processor-dependent. The support for this answer is as described in the question. Edits are provided to make this answer explicit. Q2. The kind parameter of a type inquiry is the same as that of the type parameter inquired about. See page 123, lines 35-36. Q3. The first write statement is guaranteed to print a .true. value; it is processor dependent whether the second one prints a .true. or .false. value. EDITS: All edits apply to 04-007. At [36:14], [37:30], [39:15], [40:14], and [44:2], insert the following sentence before "The kind": The kind type parameter is of type default integer. At [40:10], before "its", insert "its kind is processor-dependent and". SUBMITTED BY: Richard Maine HISTORY: 04-408 m170 F03/0020 Submitted 04-408r1 m170 Passed by J3 meeting 05-146 m171 Passed J3 letter ballot #10 N1658 m176 Passed WG5 ballot N1657 N1663 Reaffirmed in WG5 ballot N1661 on N1660 06-006T2 m177 N1666 interps for F2003 Corr 2 == N1664 ---------------------------------------------------------------------- NUMBER: F03/0022 TITLE: Coexistence of IEEE and non-IEEE kinds KEYWORDS: IEEE, kind DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot QUESTION: Is it allowed for a processor to have one or more real kinds for which there is no IEEE support, while also having real kinds for which there is IEEE support? Much of the IEEE material appears to assume that a processor could simultaneously support both IEEE and non-IEEE kinds. I thought this was the intent. However, the first sentence of the second paragraph in section 14 says that if IEEE_EXCEPTIONS or IEEE_ARITHMETIC is accessible in a scoping unit, then IEEE_OVERFLOW and IEEE_DIVIDE_BY_ZERO are supported in the scoping unit for *ALL* [emphasis mine] kinds of real and complex data. This says to me that if there is any kind of real for which the processor cannot support IEEE_OVERFLOW or IEEE_DIVIDE_BY_ZERO, then pretty much none of the IEEE stuff can be used on that processor at all; there isn't much of the IEEE stuff that can be used without IEEE_ARITHMETIC or IEEE_EXCEPTIONS. This seems draconian and unintended. I speculate that this condition is intended to apply to all IEEE real kinds rather than to all real kinds. ANSWER: Yes, this is allowed. It was a mistake to require that IEEE_OVERFLOW and IEEE_DIVIDE_BY_ZERO be supported for all kinds of real and complex data within that scoping unit. Support of these two flags means that the exceptions can be detected for real and complex kinds that are IEEE floating point data. The Standard makes no claims about non-IEEE kinds. An edit is provided to clarify this. EDITS: All edits pertain to 04-007. Clause 14 "Exceptions and IEEE arithmetic", 1st sentence of 2nd paragraph [363:9-10] replace "for all kinds of real and complex data" with "for all kinds of real and complex IEEE floating-point data" SUBMITTED BY: Richard Maine HISTORY: 04-419 m170 F03/0022 submitted 04-419r1 m170 Passed by J3 meeting 05-146 m171 Failed J3 letter ballot #10 09-223 m188 Revised answer 09-223r1 m188 Passed by J3 meeting + F2008 fix 09-226 09-295 m190 Passed as amended by J3 letter ballot #19 09-292 N1816 m191 Passed by WG5 ballot #7 {N1805/6} 10-006T5 m192 N1805 interps for F2003 Corr 5 == N1815 ---------------------------------------------------------------------- NUMBER: F03/0023 TITLE: IEEE_SET/GET_UNDERFLOW_MODE KEYWORDS: IEEE, underflow mode DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot QUESTION: Is it allowed for the argument of IEEE_SET_UNDERFLOW_MODE or IEEE_GET_UNDERFLOW_MODE to be an array? There appears to be no restriction against arrays in these procedures. For IEEE_SET_UNDERFLOW_MODE, it is ill-defined what an array would mean. The wording implies a scalar, in that it talks about being true or false, but the restriction to scalars is not explicit. For IEEE_GET_UNDERFLOW_MODE, it could be defined, but seems a little silly and nonparallel. The similar procedures for rounding mode do explicitly specify that their arguments are scalar. ANSWER: No, arrays are not allowed for these arguments. Edits are provided to correct this error. EDITS: [374:21] Add "scalar and" after "shall be" [380:13] Add "scalar and" after "shall be" SUBMITTED BY: Richard Maine HISTORY: 04-420 m170 F03/0023 Submitted - Passed by J3 meeting 05-146 m171 Passed J3 letter ballot #10 N1658 m176 Passed WG5 ballot N1657 N1663 Reaffirmed in WG5 ballot N1661 on N1660 06-006T2 m177 N1666 interps for F2003 Corr 2 == N1664 ---------------------------------------------------------------------- NUMBER: F03/0024 TITLE: Pointer deallocation and "whole object" KEYWORDS: DEALLOCATE, POINTER DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot QUESTION: 6.3.3.2 paragraph 2 (F03 [116:24-25]) states "If a pointer appears in a DEALLOCATE statement, it shall be associated with the whole of an object that was created by allocation." What does this requirement entail? In particular, which of the following examples conform to this requirement? Q1. REAL,POINTER :: X(:),Y(:) ALLOCATE(X(10)) Y => X(1:10) ! Note that ASSOCIATED(X,Y) is true. DEALLOCATE(Y) Q2. REAL,POINTER :: X(:),Y(:) ALLOCATE(X(10)) Y => X(10:1:-1) ! Note that ASSOCIATED(X,Y) is false because the order differs. DEALLOCATE(Y) Q3. REAL,POINTER :: X(:),Y(:) ALLOCATE(X(0)) Y => X ! Note that ASSOCIATED(X,Y) is false because they are zero-sized. DEALLOCATE(Y) Q4. REAL,POINTER :: X(:),Y(:,:) ALLOCATE(X(100)) Y(1:10,1:10) => X(1:100) ! Note that ASSOCIATED(X,Y) is false because the shapes differ. DEALLOCATE(Y) Q5. REAL,POINTER :: X(:),Y ALLOCATE(X(1)) Y => X(1) ! Note that one is not permitted to ask ASSOCIATED(X,Y). DEALLOCATE(Y) Q6. TYPE T REAL NOTHING(0) REAL A(0) CHARACTER C END TYPE TYPE(T),POINTER :: X CHARACTER,POINTER :: Y ALLOCATE(X) Y => X%C ! Note that one is not permitted to ask ASSOCIATED(X,Y). DEALLOCATE(Y) Q7. TYPE T CHARACTER C END TYPE TYPE,EXTENDS(T) :: XT ! No additional components END TYPE TYPE(XT),POINTER :: X TYPE(T),POINTER :: Y ALLOCATE(X) Y => X%T ! Note that one is not permitted to ask ASSOCIATED(X,Y). DEALLOCATE(Y) ANSWER: In this context, "whole object" requires the type and type parameter values to be the same, and if the object is an array that the elements are the same elements in the same array element order. A scalar is never the "whole" of an array (a processor is permitted to have extra padding between array elements). This gives the answers to the specific questions as follows: Q1 - conforming; Q2 - not conforming (order differs); Q3 - conforming; Q4 - conforming; Q5 - not conforming (scalar vs. array); Q6 - not conforming (type differs); Q7 - not conforming (type differs). An edit is supplied to clarify this intent. EDITS: [116:25] After "by allocation." insert new sentence "The pointer shall have the same dynamic type and type parameters as the allocated object, and if the allocated object is an array the pointer shall be an array whose elements are the same as those of the allocated object in array element order." SUBMITTED BY: Aleksandar Donev HISTORY: 04-378 m170 F03/0024 submitted 04-378r1 m170 Passed by J3 meeting 05-146 m171 Failed J3 letter ballot #10 09-205 m188 Revised answer - passed by J3 meeting + F2008 fix 09-226 09-295 m190 Passed by J3 letter ballot #19 09-292 N1816 m191 Passed by WG5 ballot #7 {N1805/6} 10-006T5 m192 N1805 interps for F2003 Corr 5 == N1815 ---------------------------------------------------------------------- NUMBER: F03/0025 TITLE: Abstract types in CLASS IS type guard statements KEYWORDS: ABSTRACT, CLASS IS, type guard, SELECT TYPE DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot QUESTION: Consider the following program: PROGRAM foo TYPE, ABSTRACT :: base INTEGER i END TYPE TYPE, EXTENDS(base) :: child INTEGER j END TYPE CLASS(*), POINTER :: x TYPE(child), TARGET :: c1 x => c1 SELECT TYPE (x) CLASS IS (base) PRINT *, 'Class is base' CLASS DEFAULT PRINT *, 'Class is not base' END SELECT END Constraint C401 seems to prohibit the abstract type "base" from appearing in a CLASS IS type guard statement, thus prohibiting this program. There seems to be no reason to prohibit this, and allowing it seems to be useful in some situations. Was this program intended to be standard-conforming? ANSWER: Yes, this program was intended to be standard-conforming. Edits are provided to correct this oversight. EDITS: All edits refer to 04-007. [162:17] Change "" to "". [162:19] After "", insert "or ". [162:20] After "", insert "or ". [162:21] After "", insert "or ". SUBMITTED BY: Rob James HISTORY: 04-411 m170 F03/0025 Submitted 04-411r1 m170 Passed by J3 meeting 05-146 m171 Passed J3 letter ballot #10 N1658 m176 Passed WG5 ballot N1657 N1663 Reaffirmed in WG5 ballot N1661 on N1660 06-006T2 m177 N1666 interps for F2003 Corr 2 == N1664 ---------------------------------------------------------------------- NUMBER: F03/0026 TITLE: Intrinsic types in CLASS IS type guard statements KEYWORDS: CLASS IS, type guard, SELECT TYPE, intrinsic type DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot QUESTION: Consider the following program: PROGRAM foo CLASS(*), POINTER :: x INTEGER, TARGET :: i x => i SELECT TYPE (x) CLASS IS (INTEGER) PRINT *, 'How can INTEGER be a class?' END SELECT END The description of a CLASS IS type guard statement refers to an extension of the type specified. This makes no sense for nonextensible types. C815 disallows all nonextensible derived types, but nothing disallows intrinsic types, which are also nonextensible. Was this program intended to be standard-conforming? ANSWER: No, this program was not intended to be standard-conforming. Edits are supplied to correct this oversight. EDITS: All edits refer to 04-007. Note that these edits are the same as the edits proposed for F03/0025. [162:17] Change "" to "". [162:19] After "", insert "or ". [162:20] After "", insert "or ". [162:21] After "", insert "or ". SUBMITTED BY: Rob James HISTORY: 04-412 m170 F03/0026 Submitted 04-412r1 m170 Passed by J3 meeting 05-146 m171 Passed J3 letter ballot #10 N1658 m176 Passed WG5 ballot N1657 N1663 Reaffirmed in WG5 ballot N1661 on N1660 06-006T2 m177 N1666 interps for F2003 Corr 2 == N1664 ---------------------------------------------------------------------- NUMBER: F03/0027 TITLE: Assumed character length in type guard statements KEYWORDS: CHARACTER, assumed length, type guard, SELECT TYPE DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot QUESTION: Consider the following program: PROGRAM foo CHARACTER, TARGET :: c CLASS(*), POINTER :: p p => c SELECT TYPE (p) TYPE IS (CHARACTER(*)) PRINT *, 'Character of length ', LEN(p) END SELECT END Constraint C814 says that, in a type guard statement, the shall specify that each length type parameter is assumed. Constraint C416 does not list a type guard statement as a context in which "*" can be used as a length type parameter for a character. Was this program intended to be standard-conforming? ANSWER: Yes, this program was intended to be standard-conforming. Edits are supplied to correct this oversight. EDITS: All edits refer to 04-007. These edits assume that the edits for F03/0026 are passed. [41:9] Remove "or". [41:9+] Add a new list item: "(3.5) in the or of a type guard statement (8.1.5), or" [41:33+] Add a new list item: "(3.5) If used in the of a type guard statement, the associating entity assumes its length from the selector." SUBMITTED BY: Rob James HISTORY: 04-413 m170 F03/0027 Submitted 04-413r1 m170 Passed by J3 meeting 05-146 m171 Passed J3 letter ballot #10 N1658 m176 Passed WG5 ballot N1657 - fix edits N1663 Reaffirmed in WG5 ballot N1661 on N1660 - fix edits 06-006T2 m177 N1666 interps for F2003 Corr 2 == N1664 ---------------------------------------------------------------------- NUMBER: F03/0028 TITLE: Commas in complex namelist output KEYWORDS: Namelist, complex formatting, comma, semicolon DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot QUESTION: The 7th paragraph in 10.9.2 for list directed output says: "Complex constants are enclosed in parentheses with a separator between the real and imaginary parts, each produced as defined above for real constants. The separator is a comma if the decimal edit mode is POINT; it is a semicolon if the decimal edit mode is COMMA." There are similar words in most other places where complex formatting is described. The second paragraph of 10.10.1.3 Namelist group object list items says: "When the next effective item is of type complex, the input form of the input value consists of a left parenthesis followed by an ordered pair of numeric input fields separated by a comma and followed by a right parenthesis. " Other places correctly describe namelist complex output as having a separator, either a comma or a semicolon, depending on the decimal edit mode. Should the namelist version be reworded to say "comma or semicolon"? ANSWER: Yes. Edits are supplied to correct this oversight. In addition, a similar issue exists for list directed input of undelimited character values and namelist output of character values. EDITS: All edits refer to 04-007. [240:13] Replace "comma" with "comma (if the decimal edit mode is POINT), semicolon (if the decimal edit mode is COMMA)". [244:29] Replace "a comma" by "a comma (if the decimal edit mode is POINT) or a semicolon (if the decimal edit mode is COMMA),". [244:30] Before "The first", add the following sentence: The separator is a comma if the decimal edit mode is POINT; it is a semicolon if the decimal edit mode is COMMA. [244:32] Replace "comma" with "separator". [244:33] Replace "comma" with "separator". [245:4] After "comma," insert " semicolon,". SUBMITTED BY: Dick Hendrickson HISTORY: 04-409 m170 F03/0028 Submitted 04-409r1 m170 Passed by J3 meeting 05-146 m171 Failed interp letter ballot #10 05-164 m171 Passed by J3 meeting 05-170 m172 Failed J3 letter ballot #11 05-257 m173 Passed by J3 meeting 06-133 m175 Passed J3 letter ballot #12 N1658 m176 Passed WG5 ballot N1657 - fix edits N1663 Reaffirmed in WG5 ballot N1661 on N1660 06-006T2 m177 N1666 interps for F2003 Corr 2 == N1664 ---------------------------------------------------------------------- NUMBER: F03/0029 TITLE: Negative zero and intrinsic functions KEYWORDS: Negative zero, IEEE, intrinsic functions DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot QUESTION: 4.4.2 states "Processors that distinguish between positive and negative zeros shall treat them as equivalent ... as actual arguments to intrinsic procedures other than those for which it is explicitly specified that negative zero is distinguished" Q1. Does this mean that TRANSFER(-0.0,42) is required to give the same answer as TRANSFER(+0.0,42)? The definition of TRANSFER has no explicit mention of negative zero. Q2. Does this mean that MERGE(+0.0,-0.0,flag) always returns +0.0? Q3. Does this mean that SPREAD(-0.0,2) has the value [+0.0,+0.0] instead of [-0.0,-0.0]? Q4. Does this mean that RESHAPE([-0.0],[1]) has the value [+0.0] instead of [-0.0]? Q5. Does this mean that SET_EXPONENT(-0.0,10) is +0.0 not -0.0? Q6. Does this mean that if a REAL variable X has a negative zero value, REAL(x,...) has a positive zero value? Q7. Does this mean that CMPLX(0,-0.0) has the value (+0.0,+0.0) instead of (+0.0,-0.0)? Q8. Does this mean that if a complex variable C has a negative zero imaginary part, that AIMAG(C) returns +0.0 instead of -0.0? Q9. In any other intrinsic function, if the definition of the intrinsic would imply a different result for negative zero than for positive zero, does this mean that the function returns the positive zero answer for a negative zero argument? ANSWER: Q1. No. The definition of TRANSFER explicitly states that its result has the same physical representation as its first argument. This would not be possible if "equivalent" meant that the exact same result had to be produced. Q2. No, this would contradict the definition of MERGE. Q3. No. SPREAD "replicates" its argument, which means that the value of each copy is the same as the original, not just compare equal. As with TRANSFER, this would not be possible with the suggested interpretation of the text in 4.4.2. Q4+. No. As with the previous questions, this would require an overly strict interpretation of the term "equivalent", contradicting the clear intent of the function in question. DISCUSSION: The term "equivalent" in the quoted text in 4.4.2 refers to the concept of mathematical equivalence, not physical or computational equivalence. A clarifying edit is supplied. EDITS: [38:2] Before "equivalent" insert "mathematically". SUBMITTED BY: Malcolm Cohen HISTORY: 04-422 m170 F03/0029 Submitted - Passed by J3 meeting 05-146 m171 Passed J3 letter ballot #10 N1658 m176 Passed WG5 ballot N1657 N1663 Reaffirmed in WG5 ballot N1661 on N1660 06-006T2 m177 N1666 interps for F2003 Corr 2 == N1664 ---------------------------------------------------------------------- NUMBER: F03/0031 TITLE: IEEE invalid KEYWORDS: IEEE-754, invalid exception DEFECT TYPE: Interpretation STATUS: Included in F03 corrigendum 1 QUESTION: What exceptions (if any) are raised by the following: infinity + (-infinity) infinity - infinity 0.0 * infinity infinity / infinity 0.0 / 0.0 Fortran 2003 is silent on these expressions. IEEE-754 defines (in 7.1) those as invalid. ANSWER: The Fortran Standard and Technical Report ISO/IEC TR 15580 were written to supplement the IEEE International Standard and to allow for systems that do not fully support it. That the IEEE International Standard is a normative reference is made clear in 1.9. The questions related to infinity are answered by the third paragraph of 14.8, which states "The inquiry function IEEE_SUPPORT_INF is provided to inquire whether the processor supports IEEE infinities. Where these are supported, their behavior for unary and binary operations, including those defined by intrinsic functions and by functions in intrinsic modules, shall be consistent with the specifications in the IEEE International Standard." The expression 0.0 / 0.0 is defined as invalid by the IEEE International Standard and therefore causes the exception IEEE_INVALID to occur. EDITS: None SUBMITTED BY: Fred Tydeman HISTORY: 05-110 m171 Submitted F03/0031 05-110r1 m171 Passed by J3 meeting 05-170 m172 Passed J3 letter ballot #11 05-182r1 m172 Added to F03 Corrigendum 1 N1636 - no edits ---------------------------------------------------------------------- NUMBER: F03/0032 TITLE: Sign bit of IEEE NaN KEYWORDS: IEEE-754, NaN, sign bit, negative DEFECT TYPE: Interpretation STATUS: Included in F03 corrigendum 1 QUESTION: Do IEEE-754 NaNs have a sign bit? Can they be negative? Does a sign bit imply a value can be either positive or negative? Fortran 2003 in 14.10.2 (IEEE_COPY_SIGN) says that NaNs have a sign bit. But, 14.10.10 (IEEE_IS_NEGATIVE) says NaNs are not negative. This appears to be a contradiction between two parts of Fortran 2003. ANSWER: The representation of a NaN has a sign bit, and this is what is referred to in 14.10.2. However, that bit is not interpreted as a sign (see IEEE standard, 6.3 "This standard does not interpret the sign of a NaN"). Thus 14.10.10 correctly says that a NaN is never negative. EDITS: None SUBMITTED BY: Fred Tydeman HISTORY: 05-111 m171 Submitted F03/0032 05-111r1 m171 Passed by J3 meeting 05-170 m172 Passed J3 letter ballot #11 05-182r1 m172 Added to F03 Corrigendum 1 N1636 - no edits ---------------------------------------------------------------------- NUMBER: F03/0033 TITLE: IEEE_VALUE() KEYWORDS: IEEE-754, IEEE_VALUE DEFECT TYPE: Interpretation STATUS: Included in F03 corrigendum 1 QUESTION: What does "Generate an IEEE value" in 14.9.2 mean? Fortran 2003 in 14.9.2 has: "Generate an IEEE value" without any explanation of what that means, nor any indication that it is defined elsewhere. ANSWER: 14.9 contains tables of procedures with a short description of each, modeled on 13.5. Each procedure is specified in 14.10 and the reader should have no difficulty in finding its specification there. EDITS: None SUBMITTED BY: Fred Tydeman HISTORY: 05-112 m171 Submitted F03/0033 05-112r1 m171 Passed by J3 meeting 05-170 m172 Passed J3 letter ballot #11 05-182r1 m172 Added to F03 Corrigendum 1 N1636 - no edits ---------------------------------------------------------------------- NUMBER: F03/0034 TITLE: IEEE_LOGB() KEYWORDS: IEEE-754, ieee_logb() DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot QUESTION: What is ieee_logb(denormal)? Is it of the hardware representation, or is it as if the hardware had an unbounded exponent range? What is ieee_logb(NaN)? ieee_logb(-INF)? ieee_logb(+INF)? ieee_logb() should be defined as if the hardware representation had an unbounded exponent range. ieee_logb(NaN) should be the same NaN; shall be a NaN. ieee_logb(-INF) shall be +INF ieee_logb(+INF) shall be +INF ANSWER: Case (i) of 14.10.12 correctly specifies that if the value of X is denormal, its unbiased exponent is returned, that IEEE_LOGB(X) is equal to EXPONENT(X)-1. That this conclusion is true is the subject of F2003 interp F03/0054, answered in Corrigendum 1. For consistency with the IEEE International Standard, edits are also supplied for the case where X is infinite and X is NaN. EDITS: Page and line numbers refer to 04-007. Subclause 14.10.12 "IEEE_LOGB (X)" Result value [376:17+] add: "Case (iii) If IEEE_SUPPORT_INF(X) is true and X is infinite, the result is +infinity. Case (iv) If IEEE_SUPPORT_NAN(X) is true and X is a NaN, the result is a NaN." SUBMITTED BY: Fred Tydeman HISTORY: 05-113 m171 F03/0034 submitted 05-113r1 m171 Passed by J3 meeting 05-170 m172 Passed J3 letter ballot #11 N1622 m172 Failed WG5 ballot N1629 09-221 m188 Revised answer 09-221r1 m188 Passed by J3 meeting + F2008 fix 09-226 09-295 m190 Passed by J3 letter ballot #19 09-292 N1816 m191 Passed by WG5 ballot #7 {N1805/6} 10-006T5 m192 N1805 interps for F2003 Corr 5 == N1815 ---------------------------------------------------------------------- NUMBER: F03/0035 TITLE: IEEE_NEXT_AFTER() KEYWORDS: IEEE-754, nextafter() DEFECT TYPE: Interpretation STATUS: Included in F03 corrigendum 1 QUESTION: What is NEXT_AFTER(+0.0,-0.0)? NEXT_AFTER(-0.0,+0.0)? What is NEXT_AFTER(X,Y) if X and/or Y is NaN? C99 and IEEE-754R (the revision of IEEE-754 now in progress) define NEXT_AFTER(X,Y) as Y (not X) when X == Y. NEXT_AFTER(X,Y) when both X and Y are NaN shall be a NaN, and should be one of NaN arguments. NEXT_AFTER(X,Y) when one of X and Y is a NaN shall be a NaN, and should the NaN argument. ANSWER: The first paragraph of 14.8 states "Complete conformance with the IEEE International Standard is not required, but ... the functions copysign, scalb, logb, nextafter, rem, and unordered shall be provided by the functions IEEE_COPY_SIGN, IEEE_SCALB, IEEE_LOGB, IEEE_NEXT_AFTER, IEEE_REM, and IEEE_UNORDERED." For NEXT_AFTER(X,Y) with X == Y == 0, the result is X, see 14.10.13, Case (i). This is the recommendation of the IEEE International Standard. The current draft revision of that Standard uses the definition copysign(x,y) in this case. We will reconsider the Fortran definition of NEXT_AFTER if a revised IEEE Standard is adopted with this change present. The case of NEXT_AFTER(X,Y) when one or both of X and Y is a NaN is as defined by the IEEE International Standard, see the words from 14.8 quoted above. EDITS: None SUBMITTED BY: Fred Tydeman HISTORY: 05-114 m171 Submitted F03/0035 05-114r1 m171 Passed by J3 meeting 05-170 m172 Passed J3 letter ballot #11 05-182r1 m172 Added to F03 Corrigendum 1 N1636 - no edits ---------------------------------------------------------------------- NUMBER: F03/0036 TITLE: IEEE_REM() KEYWORDS: IEEE-754, remainder() DEFECT TYPE: Interpretation STATUS: Included in F03 corrigendum 1 QUESTION: What is REM(infinity,Y)? REM(X,0.0)? What is REM(X,Y) if X and/or Y is NaN? IEEE-754 requires (in 7.1) both REM(infinity,Y) and REM(X,0.0) shall be a NaN and raise invalid. REM(X,Y) when both X and Y are NaN shall be a NaN, and should be one of the NaN arguments. REM(X,Y) when one of X and Y is a NaN shall be a NaN, and should be the NaN argument. ANSWER: The first paragraph of 14.8 states "Complete conformance with the IEEE International Standard is not required, but ... the IEEE operation rem shall be provided by the function IEEE_REM." The behaviour of IEEE_REM for the cases cited here is as defined for REM by the IEEE International Standard. EDITS: None SUBMITTED BY: Fred Tydeman HISTORY: 05-115 m171 Submitted F03/0036 05-115r1 m171 Passed by J3 meeting 05-170 m172 Passed J3 letter ballot #11 05-182r1 m172 Added to F03 Corrigendum 1 N1636 - no edits ---------------------------------------------------------------------- NUMBER: F03/0037 TITLE: IEEE_RINT() KEYWORDS: IEEE-754, rint() DEFECT TYPE: Interpretation STATUS: Included in F03 corrigendum 1 QUESTION: What is RINT(+infinity)? RINT(-infinity)? RINT(NaN)? DISCUSSION: RINT(X) when X is an infinity shall be X. RINT(X) when X is a NaN shall be a NaN, and should be the NaN argument. ANSWER: The second and third paragraphs of 14.8 state "The inquiry function IEEE_SUPPORT_NAN is provided to inquire whether the processor supports IEEE NaNs. Where these are supported, their behavior for unary and binary operations, including those defined by intrinsic functions and by functions in intrinsic modules, shall be consistent with the specifications in the IEEE International Standard. The inquiry function IEEE_SUPPORT_INF is provided to inquire whether the processor supports IEEE infinities. Where these are supported, their behavior for unary and binary operations, including those defined by intrinsic functions and by functions in intrinsic modules, shall be consistent with the specifications in the IEEE International Standard. " Therefore, the behaviour of IEEE_RINT for the cases cited here is as defined by the IEEE International Standard in section 5.5. EDITS: None SUBMITTED BY: Fred Tydeman HISTORY: 05-116 m171 Submitted F03/0037 05-116r1 m171 Passed by J3 meeting 05-170 m172 Passed J3 letter ballot #11 05-182r1 m172 Added to F03 Corrigendum 1 N1636 - no edits ---------------------------------------------------------------------- NUMBER: F03/0038 TITLE: IEEE_SCALB() KEYWORDS: IEEE-754, scalb() DEFECT TYPE: Interpretation STATUS: Included in F03 corrigendum 1 QUESTION: What is SCALB(NaN,Y)? DISCUSSION: SCALB(X,Y) when X is a NaN shall be a NaN, and should be the NaN argument. ANSWER: The second paragraph of 14.8 states "The inquiry function IEEE_SUPPORT_NAN is provided to inquire whether the processor supports IEEE NaNs. Where these are supported, their behavior for unary and binary operations, including those defined by intrinsic functions and by functions in intrinsic modules, shall be consistent with the specifications in the IEEE International Standard." Therefore, the behaviour of IEEE_SCALB for the case cited here is as defined for scalb by the IEEE International Standard. EDITS: None SUBMITTED BY: Fred Tydeman HISTORY: 05-117 m171 Submitted F03/0038 05-117r1 m171 Passed by J3 meeting 05-170 m172 Passed J3 letter ballot #11 05-182r1 m172 Added to F03 Corrigendum 1 N1636 - no edits ---------------------------------------------------------------------- NUMBER: F03/0039 TITLE: HYPOT() KEYWORDS: IEEE-754, hypot() DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot QUESTION: HYPOT is the Fortran function defined in Note 14.17. What is HYPOT(NaN,infinity)? HYPOT(NaN,finite)? HYPOT(X,Y) when X and/or Y is an infinity (even if the other is a NaN) shall be +infinity. Reason: hypot(), when one of the arguments is an infinity, is +infinity independent of the value of the other argument. So, if the NaN argument is replaced by zero, any finite number, or any infinity, hypot(infinity,NaN) is still infinity. HYPOT(X,Y) when X and/or Y is a NaN (and neither is infinite) shall be a NaN, and should one of the NaN arguments. ANSWER: The HYPOT example in note 14.17 illustrates the use of the features of this section to provide reliable software that is fast in the uncomplicated case. It is not intended to be the C "hypot" function. EDITS: None. SUBMITTED BY: Fred Tydeman HISTORY: 05-118 m171 F03/0039 submitted 05-118r3 m171 Passed by J3 meeting 05-170 m172 Passed J3 letter ballot #11 N1622 m172 Failed WG5 ballot N1629 09-222 m188 Revised answer 09-222r1 m188 Revised again to test for NAN arguments 09-222r2 m188 Passed by J3 meeting + F2008 fix 09-226 09-295 m190 Passed by J3 letter ballot #19 09-292 N1816 m191 Passed as amended by WG5 ballot #7 {N1805/6} 10-006T5 m192 N1805 interps for F2003 Corr 5 == N1815 ---------------------------------------------------------------------- NUMBER: F03/0040 TITLE: 2.0+2.0 and IEEE KEYWORDS: IEEE-754, accuracy, transformation DEFECT TYPE: Interpretation STATUS: Included in F03 corrigendum 1 QUESTION: For processors that use IEEE arithmetic, must 2.0+2.0 be 4.0? May x/5.0 be transformed into x*0.2? 1.4 (6) [2:4-5] has: "This standard does not specify: The physical properties of the representation of quantities and the method of rounding, approximating, or computing numeric values on a particular processor." That has been used as the reason why 2.0+2.0 is not required to be 4.0. Section 14 [364:6-13] has: "If a scoping unit has access to IEEE_DATATYPE of IEEE_FEATURES, within the scoping unit the processor shall support IEEE arithmetic and return true from IEEE_SUPPORT_DATATYPE(X) (14.10.23) for at least one kind of real. Similarly, if IEEE_DENORMAL, IEEE_DIVIDE, IEEE_INF, IEEE_NAN, IEEE_ROUNDING, or IEEE_SQRT is accessible, within the scoping unit the processor shall support the feature and return true from the corresponding inquiry function for at least one kind of real. In the case of IEEE_ROUNDING, it shall return true for all the rounding modes IEEE_NEAREST, IEEE_TO_ZERO, IEEE_UP, and IEEE_DOWN." IEEE-754 specifies methods of rounding and computing numeric values, and in particular, requires that 2.0+2.0 be 4.0. So, does section 14 override the weasel words of 1.4(6)? If not, should something along the lines of: "The requirements of this section override 1.4(6)" be added to section 14? Using IEEE arithmetic, x/5.0 and x*0.2 are not equivalent, so the former may not be transformed into the latter. Does IEEE arithmetic override 7.1.8.3 and Note 7.18 and prohibit that transformation? If not, should something along the lines of: "The requirements of this section override 7.1.8.3" be added to section 14? ANSWER: Yes, for processors that use IEEE arithmetic, 2.0+2.0 and 4.0 have the same value. That is a requirement of the IEEE International Standard. However, your example is very simple. For a more complicated expression, the IEEE Standard does not specify whether intermediate results are kept in extended- precision registers. The words in Section 1 are applicable and give compilers the freedom to choose whether to keep intermediate results in such registers. No, section 14 does not override the weasel words of 1.4(6). As you point out, Section 7 allows x/5.0 to be evaluated as x*0.2. The results may be different on any binary computer. Section 14 tells us about the rounding that will occur once the processor has chosen which way to evaluate this. EDITS: None SUBMITTED BY: Fred Tydeman HISTORY: 05-119 m171 Submitted F04/0040 05-119r1 m171 Passed by J3 meeting 05-170 m172 Passed J3 letter ballot #11 05-182r1 m172 Added to F03 Corrigendum 1 N1636 - no edits ---------------------------------------------------------------------- NUMBER: F03/0041 TITLE: IEEE halting and exceptions KEYWORDS: IEEE-754, trapping, exception DEFECT TYPE: Interpretation STATUS: Included in F03 corrigendum 1 QUESTION: If a specific Floating-Point (FP) exception flag is raised, and then HALTING for that FP exception is enabled for the first time, does the program halt? Or, must the specific FP exception happen after the halting is enabled for the program to halt? Section 14.5 [368:1-8] does not answer the question. ANSWER: Section 14.5 states "Halting is not precise and may occur any time after the exception has occurred." It is therefore processor dependent as to when, if ever, the program halts. EDITS: None SUBMITTED BY: Fred Tydeman HISTORY: 05-120 m171 Submitted F03/0041 05-120r1 m171 Passed by J3 meeting 05-170 m172 Passed J3 letter ballot #11 05-182r1 m172 Added to F03 Corrigendum 1 N1636 - no edits ---------------------------------------------------------------------- NUMBER: F03/0043 TITLE: Passed-object arguments and procedure pointer components KEYWORDS: DEFECT TYPE: Erratum STATUS: Included in F03 corrigendum 1 QUESTION: Section 4.5.3.3 [52:5-7] of 04-007 indicates that passed-object dummy arguments are relevant for both type-bound procedures and procedure pointer components. However, section 12.4.1.1 [268:17-19] of 04-007 on the passed-object dummy argument and argument association mentions only type-bound procedures. Should procedure pointer components also be mentioned in 12.4.1.1? ANSWER: Yes. This was an omission in section 12.4.1.1. EDITS: [268:17] After "procedure" insert " or a procedure pointer component" {The edit in 05-182r1 reads After "procedure", insert ", or a procedure pointer component," } SUBMITTED BY: Bill Long HISTORY: 05-106 m171 Submitted F03/0043, passed by J3 meeting 05-170 m172 Passed J3 letter ballot #11 05-182r1 m172 Added to F03 Corrigendum 1 N1636 ---------------------------------------------------------------------- NUMBER: F03/0044 TITLE: Implicit interfaces and conflicting references KEYWORDS: implicit interface, procedure pointer, dummy procedure, procedure reference DEFECT TYPE: Erratum STATUS: Included in F03 corrigendum 1 QUESTION: Is the following program legal? module test_mod contains subroutine reference (proc,choice) ! Proc has implicit interface external :: proc ! Or ! procedure (), pointer :: proc logical :: choice if(choice) then call proc (1.0) ! Call with real argument else call proc (1) ! Call with integer argument end if end subroutine subroutine proc_real (x) real :: x end subroutine subroutine proc_integer (i) ! respelled from original submission ! without loss of generality integer :: i end subroutine end module program test use test_mod call reference (proc_real, .true.) call reference (proc_integer, .false.) end program 12.3.2.5 says: "The type...of dummy arguments of a procedure referenced from a scoping unit where the interface of the procedure is implicit shall be such that the actual arguments are consistent with the characteristics of the dummy arguments." We define a procedure reference in 2.5.6 as the "appearance of procedure designator, ... in a context requiring execution at that point." Are both calls to proc above references, at compile time? If both calls to proc are references then they both need to be consistent with the interface of the actual argument associated with the dummy procedure. This is not possible and the program would be illegal. However, if only the call executed counts as a reference, than the program is legal. The same question applies to both dummy procedures and procedure pointers with implicit interfaces. ANSWER: Technically, the question is ill-formed in asking whether the calls are references "at compile time". The standard does not have a notion of compile-time. The calls to proc are indeed references according to the definition in 2.5.6. This is a purely syntactic notion since a call-stmt is an example of "a context requiring execution at that point" and proc is the procedure designator in call proc(1.0) and call proc(1) 12.3.2.5 specifies a requirement, violations of which are not required to be detected at compile-time (12.3.2.5 is not a constraint). Every line of the program when it is actually executed by a standard-conforming processor uses only forms and relationships defined by the standard [2:9-10], and the program has an interpretation according to the standard. This program was intended to be standard conforming. However, the current language of 12.3.2.5 is confusing. The requirement on the type of dummy arguments must be laid on the procedure actually invoked and not on the procedure named in the procedure reference. A procedure with only an implicit interface has no nominal dummy arguments on which a requirement can be levied! (Ask yourself: what are the names of the dummy argument(s) of proc ?) Put another way, in call proc (1.0) proc is a "procedure reference" but proc_real is actually the procedure referenced. An edit is supplied to make this clearer. EDITS: In [266:8] change "referenced" to "invoked" SUBMITTED BY: Aleksandar Donev HISTORY: 05-127 m171 Submitted F03/0044 05-127r3 m171 Passed by J3 meeting 05-170 m172 Passed J3 letter ballot #11 05-182r1 m172 Added to F03 Corrigendum 1 N1636 ---------------------------------------------------------------------- NUMBER: F03/0045 TITLE: Finalization and assumed-size arguments with INTENT(OUT) KEYWORDS: finalization, INTENT(OUT), assumed size, dummy argument DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot QUESTION: Consider the following program: MODULE m TYPE t INTEGER :: i CONTAINS FINAL :: finalizeT END TYPE CONTAINS ELEMENTAL SUBROUTINE finalizeT(f) TYPE(t), INTENT(INOUT) :: f f%i = 10 END SUBROUTINE END MODULE SUBROUTINE xyz (d) USE m TYPE(t), INTENT(OUT) :: d(*) END SUBROUTINE PROGRAM foo USE m EXTERNAL xyz TYPE(t) :: a(10) = t(5) CALL xyz(a(2)) END PROGRAM 4.5.5.2 of Fortran 2003 states: When a procedure is invoked, a nonpointer, nonallocatable object that is an actual argument associated with an INTENT(OUT) dummy argument is finalized. For assumed-size arguments, this situation is similar to that of default initialization with INTENT(OUT). Default initialization is prohibited for INTENT(OUT), assumed-size dummy arguments by C544. A similar restriction on finalization may have been overlooked. Was this program intended to be standard-conforming? ANSWER: No, this program was not intended to be standard-conforming. An edit is supplied to correct this oversight. DISCUSSION: The unstated philosophy of assumed-size arrays in the standard is that no action is allowed on an assumed-size array which would need to be applied elementally to the whole array. That is why no whole array assignment is allowed, for example. In accordance with this philosophy, (1) types with ultimate allocatable components also need to be excluded from being INTENT(OUT) assumed-size, as procedure invocation in this case requires deallocation of all the allocated components. (2) polymorphic INTENT(OUT) assumed-size arrays should also be excluded, as they might have finalisation, default initialisation or allocatable components. This interp subsumes Fortran 2003 interp #0060. EDITS: All edits refer to 04-007. [80:9] Before "of a type", insert "polymorphic, of a finalizable type, of a type with an ultimate allocatable component, or". SUBMITTED BY: Rob James HISTORY: 05-136 m171 F03/0045 Submitted, passed by J3 meeting 05-170 m172 Passed J3 letter ballot #11 N1622 m172 Failed WG5 ballot N1629 05-256 m173 Passed by J3 meeting 06-133 m175 Passed J3 letter ballot #12 N1658 m176 Passed WG5 ballot N1657 N1663 Reaffirmed in WG5 ballot N1661 on N1660 06-006T2 m177 N1666 interps for F2003 Corr 2 == N1664 ---------------------------------------------------------------------- NUMBER: F03/0049 TITLE: Separators in list-directed output involving UDDTIO KEYWORDS: list-directed output, separators, UDDTIO DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot QUESTION: Consider the following program: MODULE m TYPE t INTEGER i END TYPE INTERFACE WRITE(FORMATTED) MODULE PROCEDURE formattedWriteT END INTERFACE CONTAINS SUBROUTINE formattedWriteT(dtv, unit, iotype, v_list, iostat, iomsg) CLASS(t), INTENT(IN) :: dtv INTEGER, INTENT(IN) :: unit CHARACTER(LEN=*), INTENT(IN) :: iotype INTEGER, INTENT(IN) :: v_list(:) INTEGER, INTENT(OUT) :: iostat CHARACTER(LEN=*), INTENT(INOUT) :: iomsg WRITE(unit, *) dtv%i, 'a' END SUBROUTINE END MODULE PROGRAM foo USE m TYPE(t) :: t1 = t(5) OPEN(10, FILE='foo.txt', ACCESS='SEQUENTIAL', FORM='FORMATTED', & DELIM='NONE') WRITE(10, *) 'xyz', t1, 'zyx' END PROGRAM 10.9.2 of Fortran 2003 states that character sequences produced for list-directed output are not separated from each other by value separators when the delimiter mode is NONE. The implication of this is obvious when the adjacent effective output list items are both of character type. But when user-defined derived-type input/output is involved, it is much less clear whether a separator should be included in the output. In the example given, it is unclear whether the output should be: xyz 5 azyx or: xyz 5 a zyx 1. Should a separator be inserted between two non-delimited character sequences when one of the character sequences is written by a child data transfer statement, and the other is written by a parent data transfer statement, where both statements are list-directed? 2. Should a separator be inserted between two non-delimited character sequences when the character sequences are written by two different child data transfer statements, where both statements are list-directed? 3. Should a separator be inserted between two character sequences when one of the character sequences is written by a child data transfer statement, and the other is written by a parent data transfer statement, where one of the statements is list-directed and the other is format-directed? 4. Should a separator be inserted between two character sequences when the character sequences are written by two different child data transfer statements, where one of the statements is list-directed and the other is format-directed? There is also the further question of whether, in the case of recursive i/o, this is affected by intervening i/o operations to a different unit. For example, in the modified program: MODULE m2 TYPE t INTEGER i END TYPE INTERFACE WRITE(FORMATTED) MODULE PROCEDURE formattedWriteT END INTERFACE CONTAINS SUBROUTINE formattedWriteT(dtv,unit,iotype,v_list,iostat,iomsg) CLASS(t), INTENT(IN) :: dtv INTEGER, INTENT(IN) :: unit CHARACTER(LEN=*), INTENT(IN) :: iotype INTEGER, INTENT(IN) :: v_list(:) INTEGER, INTENT(OUT) :: iostat CHARACTER(LEN=*), INTENT(INOUT) :: iomsg CHARACTER(100) temp WRITE (temp,'(I0)') dtv%i WRITE (unit,*) TRIM(temp) END SUBROUTINE END MODULE PROGRAM foo2 USE m2 TYPE(t) :: t1 = t(5) OPEN(10, FILE='foo.txt', ACCESS='SEQUENTIAL', & FORM='FORMATTED', DELIM='NONE') WRITE(10, *) 'xyz', t1, 'zyx' END PROGRAM 5. Does the second example write xyz 5xyz or xyz5xyz That is, in this case, does the data transfer which is an internal file write affect whether 'xyz' and TRIM(temp) are adjacent? 6. Similarly, if the outer list-directed WRITE were to an internal file does an intervening external file i/o operation affect whether the character sequences are considered adjacent (i.e. the opposite way around to the second example)? ANSWER: 1) No. It is the intent of the standard (10.9.2) that when both the parent and child data transfer statements are both list-directed output statements, or both are namelist output statements, the processor treats the first list item appearing in a child data transfer statement as if that list item had immediately followed the last list item processed by the parent data transfer statement, as long as no other data transfers to that unit occurred in between the processing of those two list items. Therefore, in this case, the two character sequences are considered adjacent. 2) No. It is the intent of the standard (10.9.2) that when two different child data transfer statements are both list-directed output statements, or both namelist output statements, they write to the same unit, and no other data transfers to that unit occur in between the two child data transfer statements, the processor treats the first list item appearing in the second child data transfer statement as if that list item had immediately followed the last list item processed by the first child data transfer statement. Therefore, in this case, the two character sequences are considered adjacent. 3) It is processor dependent whether or not a separator appears between two such character sequences. In section 10.9.2, the phrase "adjacent undelimited character sequences" refers to character sequences produced by list-directed output. When one of the sequences is written by a child or parent output statement that is not list-directed, the exception described in the first paragraph of 10.9.2 does not apply. The other rules for inserting optional blanks around values in list-directed output allow the processor to insert optional leading and trailing blanks around a list item. The standard does not specify when optional blanks are written; therefore, when two adjacent list items (the values thereof) are written to an output record, and only one of them was written by list-directed input/output, the standard does not specify whether or not any optional blanks appear between those values in the output record. 4) It is processor dependent whether or not a separator appears between two such character sequences. See answer 3. 5) The result should be "xyz5xyz", that is, the recursive i/o to the internal file does not affect whether the character sequences being written by the outer data transfer statement are considered adjacent. 6) No, if an outer data transfer is to an internal file, then a recursive i/o operation to a different internal file or an external file does not affect whether the character sequences are considered adjacent. NOTE TO J3: In Fortran 2008, recursive i/o operations to a different external unit are allowed and these also ought not to affect whether the character sequences written by the outer data transfer statement are considered to be adjacent. The edit to F2003 below will produce that result when applied to the (draft) F2008. EDITS: [241:5] In Section 10.9.2, add the following to the end of the first paragraph: "Two undelimited character sequences are considered adjacent when both were written using list-directed input/output, no intervening data transfer or input/output file positioning operations on that unit occurred, and both were written either by a single data transfer statement, or during the execution of a parent data transfer statement along with its child data transfer statements." SUBMITTED BY: Rob James HISTORY: 05-140 m171 F03/0049 submitted 05-140r1 m171 Passed by J3 meeting 05-170 m172 Failed J3 letter ballot #11 06-367r1 m178 Passed by J3 meeting 07-272 m181 Passed as changed by J3 letter ballot #13 08-155 m184 Failed WG5 ballot #4 N1711-N1721 08-182r1 m184 Revised answer - Passed by J3 meeting 08-259 m185 Passed by J3 letter ballot #17 08-213 N1770 m187 Passed WG5 ballot 6 N1764-N1765 as revised: this edit should come before the Corrigendum 3 edit in the same place 09-006T4 m187 N1773 interps for F2003 Corr 4 == N1775 ---------------------------------------------------------------------- NUMBER: F03/0050 TITLE: Questions about internal files KEYWORDS: internal file, data transfer DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot QUESTIONS: Question 1: Fortran 2003 does not seem to prohibit this kind of recursive internal input/output. Was this program intended to be standard-conforming? If so, then what does the program print? MODULE m1 CHARACTER(20) :: ifile = '' CONTAINS CHARACTER(3) FUNCTION foo() WRITE(ifile, *) 'QWERTY' foo = 'abc' END FUNCTION END MODULE PROGRAM ex1 USE m1 WRITE(ifile, *) 'xyz', foo(), 'zyx' PRINT *, ifile END PROGRAM Question 2: Fortran 2003 does not seem to prohibit this kind of recursive internal input/output. Was this program intended to be standard-conforming? If so, then what does the program print? MODULE m2 CHARACTER(20) :: ifile = 'abc def ghi jkl mno ' CHARACTER(3) :: char CONTAINS CHARACTER(3) FUNCTION foo() READ(ifile, *) char foo = 'abc' END FUNCTION END MODULE PROGRAM ex2 USE m2 WRITE(ifile, *) 'xyz', foo(), 'zyx' PRINT *, ifile PRINT *, char END PROGRAM Question 3: Fortran 2003 does not appear to prohibit modifying a character variable when it is being used as an internal file in a data transfer statement that is currently executing. Was this program intended to be standard-conforming? If so, then what does the program print? MODULE m3 CHARACTER(20) :: ifile = '' CONTAINS CHARACTER(3) FUNCTION foo() ifile = 'bad thing to do?' foo = 'abc' END FUNCTION END MODULE PROGRAM ex3 USE m3 WRITE(ifile, *) 'xyz', foo(), 'zyx' PRINT *, ifile PRINT *, flag END PROGRAM Question 4: Fortran 2003 does not appear to prohibit referencing a character variable when it is being used as an internal file in a data transfer statement that is currently executing. Was this program intended to be standard-conforming? If so, then what does the program print? MODULE m4 CHARACTER(20) :: ifile = '' LOGICAL :: flag = .FALSE. CONTAINS CHARACTER(3) FUNCTION foo() IF (ifile == ' xyz') THEN flag = .TRUE. END IF foo = 'abc' END FUNCTION END MODULE PROGRAM ex4 USE m4 WRITE(ifile, *) 'xyz', foo(), 'zyx' PRINT *, ifile PRINT *, flag END PROGRAM ANSWER: All of these examples were intended to be prohibited. Edits are provided to prohibit referencing or defining a variable used as an internal unit as a result of evaluating any output list items, or transferring values to any input list item. EDITS: In section 9.5.3.4, after the seventh paragraph: "If an internal file has been specified, an input/output list item shall not be in the file or associated with the file." add these paragraphs [196:29+]: "During the execution of an output statement that specifies an internal file, no part of that internal file shall be referenced, defined, or become undefined as the result of evaluating any output list item. During the execution of an input statement that specifies an internal file, no part of that internal file shall be defined or become undefined as the result of transferring a value to any input list item." SUBMITTED BY: Rob James HISTORY: 05-141 m171 F03/0050 Submitted 06-368 m178 Passed by J3 meeting 07-272 m181 Passed as changed by J3 letter ballot #13 08-155 m184 Passed by WG5 ballot #4 N1711-N1721 08-006AT3 m185 N1730 interps for F2003 Corr 3 == N1727 ---------------------------------------------------------------------- NUMBER: F03/0052 TITLE: ADVANCE= specifier in child data transfer statements KEYWORDS: ADVANCE=, UDDTIO, data transfer DEFECT TYPE: Interpretation STATUS: Included in F03 corrigendum 1 QUESTION: The appearance of the ADVANCE= specifier in a child data transfer statement is not prohibited, but such an appearance is meaningless. 9.5.3 of Fortran 2003 states that the file is positioned after data transfer only if the statement is not a child data transfer. The appearance of the ADVANCE= specifier in such a statement would seem to serve only to confuse people maintaining a program that contains it. Was it intended that the ADVANCE= specifier should be allowed to appear in a child data transfer statement? ANSWER: Yes, it was intended that the ADVANCE= specifier should be allowed to appear in a child data transfer statement. Such a specifier has no effect. Note that a user defined derived type I/O routine can be called explicitly by the user, and in that case, the I/O statements therein are not child data transfer statements. EDITS: None SUBMITTED BY: Rob James HISTORY: 05-143 m171 Submitted F03/0052 05-143r1 m171 Passed by J3 meeting 05-170 m172 Passed J3 letter ballot #11 05-182r1 m172 Added to F03 Corrigendum 1 N1636 - no edits ---------------------------------------------------------------------- NUMBER: F03/0054 TITLE: Denormal inputs to EXPONENT, FRACTION, and SET_EXPONENT KEYWORDS: denormal, intrinsic, EXPONENT, FRACTION, SET_EXPONENT DEFECT TYPE: Erratum STATUS: Included in F03 corrigendum 1 QUESTION: What results do EXPONENT, FRACTION, and SET_EXPONENT return if the value of X is denormal? If a denorm is loaded into the cpu in extended precision, it becomes a normal value with changed fractional and exponent parts. Which of these values should be taken? In the definition of EXPONENT, the words 'of the model representation for the value of X' appear; but in the definition of FRACTION and SET_EXPONENT, the words are 'for the model representation of X'. Was this difference intended? ANSWER: In all three cases, the intention was to treat the value as if it were held according to the model in 13.14 with the same radix b, but with an expanded exponent range. This is why the words 'for the value of X' were used in EXPONENT. It has to be this way for a denormal value since otherwise it does not lie within the model. Edits are provided to make the intention clear. DISCUSSION: This interpretation is satisfactory from a mathematical point of view since the values of EXPONENT(X) and EXPONENT(DBLE(X)) will be the same when X is of type default real and has a denormal value. Similar properties holds for the other two functions. EDITS: Page and line numbers refer to J3/04-007. [316:5-6] Subclause 13.7.37, Result Value, lines 1-2. Replace "model ... X" by "representation for the value of X in the model (13.4) that has the radix of X but no limits on exponent values". [317:8] Subclause 13.7.40, Result Value, line 2. Replace "model ... X" by "representation for the value of X in the model that has the radix of X but no limits on exponent values". [351:5] Subclause 13.7.107, Result Value, line 2. Replace "model ... X" by "representation for the value of X in the model that has the radix of X but no limits on exponent values". SUBMITTED BY: John Reid HISTORY: 05-152 m171 F03/0054 submitted; Passed by J3 meeting 05-170 m172 Passed J3 letter ballot #11 05-182r1 m172 Added to F03 Corrigendum 1 N1636 ---------------------------------------------------------------------- NUMBER: F03/0055 TITLE: Denormal inputs to SPACING and RRSPACING KEYWORDS: denormal, intrinsic, SPACING, RRSPACING DEFECT TYPE: Erratum STATUS: Included in F03 corrigendum 1 QUESTION: What results do SPACING and RRSPACING return if the value of X lies outside the model of 13.4, in particular if it is denormal? In the definition of EXPONENT, the words 'of the model representation for the value of X' appear; but in the definition of SPACING and RRSPACING, the words are 'for the model representation of X'. Was this difference intended? Is the intention to indicate that for SPACING and RRSPACING, the model is that of all reals with the same kind type parameter value as X? In the IEEE model, the spacing between any two adjacent denorms is equal to the smallest denorm. Is it intended that this value be returned by SPACING? ANSWER: The informal description refers to 'model numbers near the argument value', but the text does not reflect this. Edits are provided to correct this. Yes, the difference was intended. In both models, the lower bound on the exponent has a profound effect on the spacing of tiny values, so it is important that it be taken into account. It was intended to refer to the model for all the reals with the same kind type parameter value as X. Here is it the model of 13.4 that is involved, as the words in 13.4 make clear. If the argument value is a positive denorm, the model numbers near it are TINY(X) and 0. Their spacing is TINY(X). Edits are provided to make this intention clear. EDITS: Page and line numbers refer to J3/04-007. [347:22] Subclause 13.7.100, Result Value, line 2. Replace "the model representation of X." by "the value nearest to X in the model for real values whose kind type parameter is that of X; if there are two such values, the value of greater absolute value is taken." [353:9] Subclause 13.7.113, Result Value, line 2. Replace "the model representation of X." by "the value nearest to X in the model for real values whose kind type parameter is that of X; if there are two such values, the value of greater absolute value is taken." SUBMITTED BY: John Reid HISTORY: 05-153 m171 F03/0055 submitted; Passed by J3 meeting 05-170 m172 Passed J3 letter ballot #11 05-182r1 m172 Added to F03 Corrigendum 1 N1636 ---------------------------------------------------------------------- NUMBER: F03/0056 TITLE: Null input values and list-directed UDDTIO KEYWORDS: null value, UDDTIO DEFECT TYPE: Interpretation STATUS: Passed by WG5 ballot QUESTION: Consider the following program: MODULE m PRIVATE TYPE, PUBLIC :: t INTEGER i INTEGER j CONTAINS PROCEDURE, PRIVATE :: readFormatted => readFormattedT GENERIC :: READ(FORMATTED) => readFormatted END TYPE CONTAINS SUBROUTINE readformattedT(dtv, unit, iotype, v_list, iostat, iomsg) CLASS(t), INTENT(INOUT) :: dtv INTEGER, INTENT(IN) :: unit CHARACTER(*), INTENT(IN) :: iotype INTEGER, INTENT(IN) :: v_list(:) INTEGER, INTENT(OUT) :: iostat CHARACTER(*), INTENT(INOUT) :: iomsg READ (unit, *) dtv%i READ (unit, *) dtv%j END SUBROUTINE END MODULE PROGRAM p USE m INTEGER i TYPE(t) x, y, z x%i = 10 x%j = 15 y%i = 20 y%j = 25 z%i = 30 z%j = 35 i = 100 READ (*,*) x, y, z, i PRINT *, x, y, z, i END PROGRAM The following is given as input to this program: 1044 2167 3977 / 1 2 3 10.9.1.1 of Fortran 2003 (Null values) states: A slash encountered as a value separator during execution of a list-directed input statement causes termination of execution of that input statement after the assignment of the previous value. If a child data transfer statement encounters a slash as a value separator, it is unclear whether this statement applies to just the child statement, or to the parent data transfer statement as well. The significance for any subsequent child statement is also unclear. What is the behaviour of this program when it is given the specified input? ANSWER: When a child data transfer statement encounters a slash as a value separator, only that data transfer statement encounters the slash. None of its parent data transfer statements encounters the slash. Only the data transfer statement that encounters the slash is terminated. The program above should print the following: 1044.2167.3977.25.1.2.3 where "." represents a value separator. EDITS: None. SUBMITTED BY: Rob James HISTORY: 05-171 m172 F03/0056 Submitted 05-218 m173 Passed by J3 meeting 06-133 m175 Passed J3 letter ballot #12 N1658 m176 Passed WG5 ballot N1657 N1663 Reaffirmed in WG5 ballot N1661 on N1660 06-006T2 m177 N1666 interps for F2003 Corr 2 == N1664 ---------------------------------------------------------------------- NUMBER: F03/0057 TITLE: Namelist I/O and UDDTIO KEYWORDS: namelist, UDDTIO DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot QUESTION: Can namelist I/O ever invoke a user-defined derived-type I/O procedure? 10.10.1.2 of Fortran 2003 (Namelist input values) implies that namelist input cannot invoke a user-defined derived-type I/O procedure. It says that, for a derived-type variable, "the effect is as if the variable represented were expanded into a sequence of scalar list items of intrinsic data types", which would preclude any derived-type I/O. However, the same sentence says that this is done "in the same way that formatted input/output list items are expanded (9.5.2)", which would result in some effective list items of derived type. 9.5.3.6 and 9.5.3.7.2 also imply that a user-defined derived-type I/O procedure could be invoked for a namelist group object. ANSWER: Yes, namelist I/O can invoke a user-defined derived-type I/O procedure. Edits are provided to correct this problem. EDITS: All edits refer to 04-007. [244:8] Remove "of intrinsic data types". [244:10] Remove "intrinsic". SUBMITTED BY: Rob James HISTORY: 05-172 m172 F03/0057 Submitted 05-219 m173 Passed by J3 meeting 06-133 m175 Passed J3 letter ballot #12 N1658 m176 Passed WG5 ballot N1657 N1663 Reaffirmed in WG5 ballot N1661 on N1660 06-006T2 m177 N1666 interps for F2003 Corr 2 == N1664 ---------------------------------------------------------------------- NUMBER: F03/0058 TITLE: Recursive namelist output KEYWORDS: UDDTIO, namelist, output DEFECT TYPE: Interpretation STATUS: Passed by WG5 ballot QUESTION: Consider the following program: MODULE mod PRIVATE TYPE, PUBLIC :: node INTEGER :: value = 0 CONTAINS PROCEDURE, PRIVATE :: nodeFormattedWrite => writeroutine GENERIC :: WRITE(FORMATTED) => nodeFormattedWrite END TYPE CONTAINS SUBROUTINE writeroutine(dtv, unit, iotype, vlist, iostat, iomsg) CLASS(node), INTENT(IN) :: dtv INTEGER, INTENT(IN) :: unit CHARACTER(LEN=*), INTENT(IN) :: iotype INTEGER, INTENT(IN) :: vlist(:) INTEGER, INTENT(OUT) :: iostat CHARACTER(LEN=*), INTENT(INOUT) :: iomsg REAL a NAMELIST /inner/ a a = 4.0 WRITE(unit, NML=inner) END SUBROUTINE END MODULE PROGRAM foo USE mod TYPE(node) :: a(2) NAMELIST /outer/ a a(1)%value = 1 a(2)%value = 2 WRITE(*, NML=outer) END PROGRAM Is the following output standard-conforming for the above program? If not, please give an example of standard-conforming output. &OUTER A= &INNER A=4.000000000 /, &INNER A=4.000000000 / / ANSWER: Yes EDITS: None SUBMITTED BY: Rob James HISTORY: 05-173 m172 F03/0058 Submitted 05-220 m173 Passed by J3 meeting 06-133 m175 Passed J3 letter ballot #12 N1658 m176 Passed WG5 ballot N1657 N1663 Reaffirmed in WG5 ballot N1661 on N1660 06-006T2 m177 N1666 interps for F2003 Corr 2 == N1664 ---------------------------------------------------------------------- NUMBER: F03/0060 TITLE: Default initialization of INTENT(OUT), assumed-size arrays KEYWORDS: default initialization, INTENT(OUT), assumed size, polymorphism DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot QUESTION: Consider the following program: MODULE m TYPE base INTEGER I END TYPE TYPE, EXTENDS(base) :: child INTEGER :: j = 5 END TYPE CONTAINS SUBROUTINE sub(b) CLASS(base), INTENT(OUT) :: b(*) END SUBROUTINE END MODULE PROGRAM foo USE m TYPE(child) :: c(3) c%i = 12 c%j = 47 CALL sub(c) PRINT *, c%j END PROGRAM C544 prevents nonpolymorphic, INTENT(OUT), assumed-size arrays from having default initialization. The polymorphic case, however, is not checkable at compile time, so it cannot be a constraint. Was it intended that the dynamic type of an INTENT(OUT), assumed-size array could have default initialization? If so, what does the above program print? ANSWER: No, this was not intended. This interp is subsumed by Fortran 2003 interp # 45, which contains edits making the above example non-conforming. EDITS: None SUBMITTED BY: Rob James HISTORY: 05-175 m172 F03/0060 Submitted 05-222 m173 Edit provided 05-222r1 m173 Subsumed by 0045 - Passed by J3 meeting 06-133 m175 Passed J3 letter ballot #12 N1658 m176 Passed WG5 ballot N1657 N1663 Reaffirmed in WG5 ballot N1661 on N1660 06-006T2 m177 N1666 interps for F2003 Corr 2 == N1664 ---------------------------------------------------------------------- NUMBER: F03/0061 TITLE: Polymorphism and explicit-shape or assumed-size dummy arguments KEYWORDS: polymorphism, assumed size, actual argument, dummy argument DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot QUESTION: Consider the following program: MODULE m TYPE t1 INTEGER :: i END TYPE CONTAINS SUBROUTINE abc (b) CLASS(t1) :: b(*) EXTERNAL xyz CALL xyz(b(2)) END SUBROUTINE END MODULE SUBROUTINE xyz(d) USE m TYPE(t1) :: d(2,3) END SUBROUTINE PROGRAM foo USE m TYPE, EXTENDS(t1) :: t2 INTEGER :: j END TYPE TYPE(t2) a(10) CALL abc(a(2)) END PROGRAM During the execution of "xyz", the dummy argument "d" is sequence associated with the associated actual argument (which is true if "d" has either explicit shape or assumed size). This implies that the entity that is argument associated with "d" must be contiguous. The dummy argument "b" of the module subroutine "abc" is polymorphic, and its dynamic type in this case is different than its declared type. In this scoping unit, "xyz" has an implicit interface, so we know it doesn't have any polymorphic arguments. So, the dummy argument of "xyz" must be nonpolymorphic, and have the same declared type as the actual argument (b(2)). This implies that we only want to pass the parent portion of b(2). But the dummy argument of "xyz" may be an explicit-shape or assumed-size array (in this case, it is an explicit-shape array). This means that we have to pass a contiguous array to "xyz". This wouldn't be a problem if the dynamic type of "b" was the same as the declared type, but in this case it is not. The parent portion of "b" (from element 2 to the end of the array) must be copied into a temporary array. The compiler cannot possibly know how big "b" is because it is an assumed-size array, so it is impossible to make such a copy. Was this program intended to be standard-conforming? ANSWER: No, this program was not intended to be standard-conforming. Edits are provided to correct this oversight. EDITS: All edits refer to 04-007. [270:27] Change "assumed-shape or pointer" to "assumed-shape, pointer, or polymorphic". SUBMITTED BY: Rob James HISTORY: 05-176 m172 F03/0061 Submitted 05-223 m173 Passed by J3 meeting 06-133 m175 Passed J3 letter ballot #12 N1658 m176 Passed WG5 ballot N1657 N1663 Reaffirmed in WG5 ballot N1661 on N1660 06-006T2 m177 N1666 interps for F2003 Corr 2 == N1664 ---------------------------------------------------------------------- NUMBER: F03/0062 TITLE: Finalization of array constructors KEYWORDS: Finalization, array constructor DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot QUESTION: Consider the following program: MODULE m TYPE t INTEGER i CONTAINS FINAL :: finalizeT END TYPE CONTAINS SUBROUTINE finalizeT(obj) TYPE(t) :: obj(:) PRINT *, 'Finalizing a rank-1 array of type t' END SUBROUTINE END MODULE PROGRAM foo USE m TYPE(t) :: a a%i = 5 PRINT *, (/ (a, i=1,5) /) END PROGRAM If the PRINT statement in the main program was printing a function result or a structure constructor, rather than an array constructor, it is clear that the object should be finalized after that PRINT statement. However, for array constructors, this does not appear to be the case. In the main program above, should the entity created by the array constructor be finalized after execution of the PRINT statement? ANSWER: Yes, the array constructor should be finalized. Edits are provided to correct this oversight. EDITS: This edit refers to 04-007. [59:27] After the first occurrence of "structure constructor", insert "or array constructor". On the same line, delete the second occurrence of "structure". This edit refers to the edit introduced by interpretation F03/0007. After the first occurrence of "structure constructor", insert "or array constructor". In the same sentence, delete the second occurrence of "structure". SUBMITTED BY: Rob James HISTORY: 05-177 m172 F03/0062 Submitted 05-224 m173 Passed by J3 meeting 06-133 m175 Passed J3 letter ballot #12 N1658 m176 Passed WG5 ballot N1657 - fix edits N1663 Reaffirmed in WG5 ballot N1661 on N1660 06-006T2 m177 N1666 interps for F2003 Corr 2 == N1664 ---------------------------------------------------------------------- NUMBER: F03/0063 TITLE: Procedure pointers in BLOCK DATA program units KEYWORDS: Procedure pointer, common block, block data DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot QUESTION: It is clear that procedure pointers are permitted in common blocks. However, due to the restrictions on BLOCK DATA program units, it seems that such a common block can not appear in a BLOCK DATA program unit. Was it intended that common blocks containing procedure pointers could be initialized in a BLOCK DATA program unit? ANSWER: It was a mistake to try to allow procedure pointers in common blocks. Edits are provided to correct this blunder. EDITS: All edits refer to 04-007. [98:17] Delete the second line of R558 [98:18] Remove "or " [98:21] After "allocatable," insert "a procedure pointer," [98:25] Remove "or " [100:12-15] Delete "A procedure ... type parameters.". [411:21] Remove item (7) in the list of names in a scoping unit that override the same host-associated name. [416:23-24] "pointer"->"data pointer" SUBMITTED BY: Rob James HISTORY: 05-178 m172 F03/0063 submitted 05-225 m173 Passed by J3 meeting 06-133r2 m175 Passed J3 letter ballot #12 N1658 m176 Failed WG5 ballot N1657 09-148 m187 Revised answer, passed by J3 meeting 09-187r2 m188 Passed J3 letter ballot #18 09-155 as modified N1816 m191 Passed as amended by WG5 ballot #7 {N1805/6} - F2008 fix in 10-139 passed at m191 10-006T5 m192 N1805 interps for F2003 Corr 5 == N1815 ---------------------------------------------------------------------- NUMBER: F03/0066 TITLE: Precision of operation KEYWORDS: precision, operation DEFECT TYPE: Interpretation STATUS: Passed by WG5 ballot QUESTION: Given REAL X X = ... some value ... IF( (X+3.0) .EQ. 3.0 )... may the X+3.0 be computed with more range and/or precision than that of REAL? In other words, is PRECISION(X) .EQ. PRECISION(X+3.0) always true; or is PRECISION(X) .LT. PRECISION(X+3.0) sometimes true? References are to J3/04-007. 2.4.1.1 Intrinsic type has "The kind type parameter indicates ... the decimal precision and exponent range for the real and complex types, ..." 7.1.4.2 Type, type parameters, and shape of the result of an operation has in (4) "For an expression x1 op x2 where op is a numeric intrinsic binary operator with both operands of the same type and kind type parameters, ..., the kind type parameter of the expression is identical to that of each operand." Since X and 3.0 are the same type and have the same kind type parameters, 7.1.4.2 (4) appears to require the X+3.0 have just the range and precision of REAL; no more, no less (otherwise, the precision is not identical). But, several members of the J3 email list have said that the "+" may be done with more precision; using either 1.4(6) or 7.1.8.3 as the reason. Perhaps something alone the lines of "The values of floating operands and of the results of floating expressions may be represented in greater precision and range than that required by the kind type parameter; the kind type parameter is not changed thereby." should be added to 7.1.4.2(4). QUESTION: Is PRECISION(X) .EQ. PRECISION(X+3.0) always true? ANSWER: Yes, that is the definition of PRECISION. The PRECISION intrinsic has nothing to do with the precision in which the computation X+3.0 is computed. 7.1.4.2 (4) only describes the precision of the end result of the computation. The weasel words in 1.4 (6) allow the processor to compute this expression in higher precision than REAL. EDITS: None SUBMITTED BY: Fred Tydeman HISTORY: 05-193 m173 F03/0066 Submitted 05-193r1 m173 Passed by J3 meeting 06-133 m175 Passed J3 letter ballot #12 N1658 m176 Passed WG5 ballot N1657 N1663 Reaffirmed in WG5 ballot N1661 on N1660 06-006T2 m177 N1666 interps for F2003 Corr 2 == N1664 ---------------------------------------------------------------------- NUMBER: F03/0067 TITLE: Accuracy of conversion of real literal constants KEYWORDS: conversion, accuracy DEFECT TYPE: Interpretation STATUS: Passed by WG5 ballot QUESTION: The following is independent of IEEE-754. Fortran 2003 10.6.1.2.6 covers conversions between "decimal values" and "internal values" and has some strong requirements. Are there equivalent requirements on accuracy for conversions of real literal constants? Sections 4.1.2 and 4.4.2 seems like the places to find them (if they exist). What rounding mode is used for conversions of real literal constants? Is the same rounding mode used for all such conversions? The following four questions are about positive values, but the same would apply to negative values. Must all "decimal values" in the range smallest non-zero finite internal value (which could be a denormal) to largest finite internal value, e.g. 0.1, be converted? Must all "decimal values" in the range zero to smallest non-zero finite internal value, e.g. 1.0e-999999999, be converted? Must all "decimal values" larger than the largest finite internal value, e.g. 9.9e+99999999999, be converted if infinity is an internal value? What does nearest rounding mean for these cases? What requirements exist for "decimal values" larger than the largest finite internal value if infinity is not an internal value? ANSWER: There are no requirements on accuracy for conversions of real literal constants. The standard does not specify the rounding mode used for conversions of real literal constants, nor does it require the same rounding mode to be used for all conversions. Whether all decimal values in any range can be converted is not standardized. There are no requirements for "decimal values" larger than the largest finite internal value whether infinity is an internal value or not. EDITS: None SUBMITTED BY: Fred Tydeman HISTORY: 05-206 m173 F03/0067 Submitted 05-206r1 m173 Passed by J3 meeting 06-133 m175 Passed J3 letter ballot #12 N1658 m176 Passed WG5 ballot N1657 N1663 Reaffirmed in WG5 ballot N1661 on N1660 06-006T2 m177 N1666 interps for F2003 Corr 2 == N1664 ---------------------------------------------------------------------- NUMBER: F03/0068 TITLE: First character of namelist output records KEYWORDS: namelist, output, UDDTIO DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot QUESTION: The last sentence of 10.10.2.2 of Fortran 2003 states: Except for continuation of delimited character sequences, each output record begins with a blank character. If a namelist output statement causes a user-defined derived-type output procedure to be called, was it intended to be standard- conforming for that procedure to create a new record (perhaps by using the slash edit descriptor) that does not begin with a blank character? ANSWER: Yes, this situation was intended to be standard-conforming. Explicit formatting in user-defined derived-type output is not required to output a leading blank in this case. An edit is provided to correct this oversight. EDITS: All edits refer to 04-007. [247:33] Before "continuation", insert "new records created by explicit formatting within a user-defined derived-type output procedure or by". SUBMITTED BY: Rob James HISTORY: 05-227 m173 F03/0068 Submitted 05-227r1 m173 Passed by J3 meeting 06-133 m175 Passed J3 letter ballot #12 N1658 m176 Passed WG5 ballot N1657 N1663 Reaffirmed in WG5 ballot N1661 on N1660 06-006T2 m177 N1666 interps for F2003 Corr 2 == N1664 ---------------------------------------------------------------------- NUMBER: F03/0069 TITLE: Procedure pointers in defined assignment KEYWORDS: procedure pointer, defined assignment DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot QUESTION: In 12.3.2.1.1 of Fortran 2003, at [262:8-9], the following is stated about the dummy arguments of a function that defines an operation: The dummy arguments shall be nonoptional dummy data objects and shall be specified with INTENT (IN). This clearly states that a dummy argument of such a function cannot be a procedure pointer. The same is not stated for the dummy arguments of a subroutine that defines assignment. Was it intended that procedure pointers should be allowed in defined assignment, but not in defined operations? ANSWER: No. It was not intended that procedure pointers should be allowed in either defined assignment or defined operations. An edit is provided to correct this oversight. EDITS: All edits refer to 04-007. [263:6] Replace "Each argument shall be nonoptional." with "The dummy arguments shall be nonoptional dummy data objects." SUBMITTED BY: Rob James HISTORY: 05-228 m173 F03/0069 Passed by J3 meeting 06-133 m175 Passed J3 letter ballot #12 N1658 m176 Passed WG5 ballot N1657 N1663 Reaffirmed in WG5 ballot N1661 on N1660 06-006T2 m177 N1666 interps for F2003 Corr 2 == N1664 ---------------------------------------------------------------------- NUMBER: F03/0070 TITLE: Can child I/O statements be advancing I/O statements? KEYWORDS: UDDTIO, ADVANCE= DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot [175:30-31] of Fortran 2003 states: An advancing input/output statement always positions a record file after the last record read or written, unless there is an error condition. Since a child I/O statement does not position a file after the last Record [194:19][199:8-9], this implies that a child I/O statement cannot be an advancing I/O statement. [189:6-9] of Fortran 2003 states: The ADVANCE= specifier determines whether advancing input/output occurs for this input/output statement. If YES is specified, advancing input/output occurs. If NO is specified, nonadvancing input/output occurs (9.2.3.1). If this specifier is omitted from an input/output statement that allows the specifier, the default value is YES. This clearly states that any data transfer statement is an advancing I/O statement if the value 'NO' is not specified for the ADVANCE= specifier. These two statements seem to contradict each other. QUESTION: If a child I/O statement does not have an ADVANCE= specifier with the value 'NO', is it an advancing I/O statement? DISCUSSION: The answer to this question affects the value for the IOSTAT variable for child READ statements in some situations. For example, in the following program, the value of "stat1" should be equal to IOSTAT_EOF if the child READ statement is advancing, but it should be equal to IOSTAT_EOR if the statement is nonadvancing. MODULE m TYPE t CHARACTER(2) :: x(2) CONTAINS PROCEDURE :: readT GENERIC :: READ(FORMATTED) => readT END TYPE CONTAINS SUBROUTINE readT(dtv, unit, iotype, v_list, iostat, iomsg) CLASS(t), INTENT(INOUT) :: dtv INTEGER, INTENT(IN) :: unit CHARACTER(*), INTENT(IN) :: iotype INTEGER, INTENT(IN) :: v_list(:) INTEGER, INTENT(OUT) :: iostat CHARACTER(*), INTENT(INOUT) :: iomsg READ (unit, '(2a2)', IOSTAT=iostat) dtv%x END SUBROUTINE END MODULE PROGRAM p USE m USE, INTRINSIC :: ISO_FORTRAN_ENV TYPE(t) t1 CHARACTER(3) :: c = '123' INTEGER stat1 READ (c, *, IOSTAT=stat1) t1 PRINT *, (stat1 == IOSTAT_EOR), (stat1 == IOSTAT_EOF) END PROGRAM ANSWER: No, such a child I/O statement is not advancing. Edits are provided to correct this inconsistency. EDITS: All edits refer to 04-007. [189:7] Replace "this input/output statement" by "a nonchild input/output statement". [189:9] Replace "from an input/output statement" by "from a nonchild input/output statement". [189:9] After "YES." Insert " A formatted child input/output statement is a nonadvancing input/output statement, and any ADVANCE= specifier is ignored." [199:8+] Add a new bullet: " o Any ADVANCE= specifier in a child input/output statement is ignored." SUBMITTED BY: Rob James HISTORY: 05-229 m173 F03/0070 Submitted 05-229r1 m173 Passed by J3 meeting 06-133 m175 Passed J3 letter ballot #12 - typos fixed N1658 m176 Passed WG5 ballot N1657 - fix edits N1663 Reaffirmed in WG5 ballot N1661 on N1660 06-006T2 m177 N1666 interps for F2003 Corr 2 == N1664 ---------------------------------------------------------------------- NUMBER: F03/0071 TITLE: Subroutine/function ambiguity in generics KEYWORDS: subroutine, generic, implicit DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot QUESTION: Q1. Is the following generic allowed? interface q subroutine qr(f) implicit real(f) external f end subroutine subroutine qc(f) implicit complex(f) external f end subroutine end interface q The uncertainty arises because it is not established whether F is a subroutine or a function. If either F were a subroutine, then it would be clear that the generic was disallowed. One might be able to use this to deduce that both Fs must be functions. This seems like an obscure deduction to demand of the compiler. Q2. Consider the following "obviously" allowed generic module m interface q subroutine qr(f) real, external :: f end subroutine subroutine qc(f) complex, external :: f end subroutine end interface q end module m Is the following main program valid? program main use m external ff call q(ff) end Again, the problem is that it is unclear whether or not ff is a function or subroutine. If it is a subroutine, then the call is ambiguous. One might thus deduce that ff must be a function, and therefore of type real, but this seems like an obscure deduction to demand of the compiler. ANSWER: 1. The program fragment is not conforming. A generic interface is required to be nonambiguous. This is a similar situation to the declaration of an external procedure in a module, where a procedure that is a function is required to have its type and type parameters explicitly declared. An edit is provided to require this for specific procedures in a generic interface. 2. The main program program unit is conforming, although the program would not be if the external procedure FF were not in fact a real function. If the reference had been to QR instead of Q, it would be clear that FF has to be a real function, from the point of view of the main program scoping unit. At the call site, the reference to Q is known to be a reference either to QR or QC (the interface block for Q is not defective), both of which require a function actual argument. FF is known to be either a subroutine or a function, since it explicitly has the EXTERNAL attribute, and if it is a function it is known by implicit typing rules to be real. Because neither specific in the generic allows a subroutine as an argument, FF must therefore be a function. Since FF is real, QR is called. (The generic cannot have a specific that accepts a subroutine as an argument, as that would violate the requirements in 16.2.3.) EDITS: [261:3] In 12.3.2.1 Interface block, immediately after "A generic interface is always explicit.", append new sentence to paragraph "If a specific procedure in a generic interface has a function dummy argument, that argument shall have its type and type parameters explicitly declared in the specific interface." {I.e. if you just say EXTERNAL dummy, you must mean a subroutine.} SUBMITTED BY: Richard Maine HISTORY: 05-265 m174 F03/0071 submitted 08-189r1 m184 Answer provided - Passed by J3 meeting 08-259 m185 Failed J3 letter ballot #17 08-213 08-262 m185 Passed by J3 meeting 09-187r2 m188 Passed J3 letter ballot #18 09-155 N1816 m191 Passed by WG5 ballot #7 {N1805/6} - F2008 in 10-129 passed at m191 10-006T5 m192 N1805 interps for F2003 Corr 5 == N1815 ---------------------------------------------------------------------- NUMBER: F03/0072 TITLE: Default initialization for "automatic" components KEYWORDS: Parameterized Derived Type, Default Initialization DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot QUESTION: Consider TYPE t(len) INTEGER,LEN :: len CHARACTER(len) :: cvalue = "xyz" END TYPE SUBROUTINE s(n) TYPE(t(n)) x ... TYPE t2(len2) TYPE(t(len2)) :: tvalue = t(10,"fred nurke") END TYPE SUBROUTINE s2(n) TYPE(t2(n)) :: y ... The type definition for T appears to conform to the standard; it allows an "automatic" component to be default initialized. However, the declaration of the local variable X in subroutine S will initialize the component differently depending on the value of N, for example, giving the CVALUE component the value "", "x", "xy", "xyz", "xyz " for N being 0, 1, 2, 3, 4 respectively. Q1. Was it intended that "automatic" components can be default-initialized? If the answer is "Yes", the type definition for T2 also appears to conform to the standard. However, the declaration of Y in S2 will not work if N has any value other than 10 at run time. This is surprising; there appears to be no other situation where the runtime value of a length type parameter can render a declaration invalid. Q2. Is this situation intentional? ANSWER: Q1. No, this was not intended. An edit is supplied to fix this. Q2. Not applicable. EDITS: In 4.5.3 Components, immediately before R445 , insert a new constraint: [50:40+] "C447a (R440) If appears, every type parameter and array bound of the component shall be an initialization expression." SUBMITTED BY: Malcolm Cohen HISTORY: 05-285 m174 F03/0072 Submitted 05-285r1 m174 Revised edit 06-133 m175 Passed J3 letter ballot #12 N1658 m176 Passed WG5 ballot N1657 N1663 Reaffirmed in WG5 ballot N1661 on N1660 06-006T2 m177 N1666 interps for F2003 Corr 2 == N1664 ---------------------------------------------------------------------- NUMBER: F03/0073 TITLE: C interop of dummy procedures KEYWORDS: Interoperability, dummy procedures DEFECT TYPE: Interpretation STATUS: Passed by WG5 ballot QUESTION: Is the following interface interoperable, and if yes, what is the interoperable C prototype? subroutine my_sub(my_fun) bind(c, name="My_Proc") interface function my_fun(x) bind(c) use iso_c_binding integer(c_int) :: my_fun real(c_double), value :: x end function end interface end subroutine ANSWER: Yes, this interface is interoperable with the following prototype: void My_Proc(int (*his_fun)(double)); Its formal parameter is of a pointer type, and the referenced type is a function that is interoperable with my_fun, thus satisfying the requirements in item 5 in the list in subclause 15.2.6. EDITS: None SUBMITTED BY: Aleksandar Donev HISTORY: 06-102 m175 F03/0073 submitted 08-188r1 m184 Answer proposed - Passed by J3 meeting 08-259 m185 Passed by J3 letter ballot #17 08-213 N1770 m187 Passed WG5 ballot 6 N1764-N1765 09-006T4 m187 N1773 interps for F2003 Corr 4 == N1775 ---------------------------------------------------------------------- NUMBER: F03/0074 TITLE: Type mismatch for C character arguments KEYWORDS: Interoperability, dummy procedures DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot QUESTION: Is the following conforming if the C character kind (C_CHAR) is not the same as the default character kind (KIND('A'))? use iso_c_binding Interface Subroutine sub(string) Bind(C) import C_Char Character(Kind=C_Char) :: string(*) End Subroutine End Interface Character(Kind=C_Char,Len=10) :: string Call sub(string) The second and 3rd paras of 12.4.1.2 do not treat C character kind the same as default character kind, and seem to require matching type parameter values between the actual and dummy. This makes Note 15.23 nonconforming if C_CHAR is not the same as default character kind, and is also not in sync with 270:25-26. ANSWER: Yes, the program fragment is standard-conforming. An edit is provided to correct the oversight in 12.4.1.2. EDITS: [269:3] After "of type default character", Insert "or of type character with the C character kind (15.1)". [269:5,7-8] After each "of type default character", Insert "or of type character with the C character kind", twice. SUBMITTED BY: Aleksandar Donev HISTORY: 06-105 m175 F03/0074 submitted 08-190r1 m184 Revised answer - Passed by J3 meeting 08-259 m185 Passed by J3 letter ballot #17 08-213 N1770 m187 Passed WG5 ballot 6 N1764-N1765 as revised 09-006T4 m187 N1773 interps for F2003 Corr 4 == N1775 ---------------------------------------------------------------------- NUMBER: F03/0075 TITLE: C interop of derived types with array components KEYWORDS: Interoperability, dummy procedures DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot QUESTION: Is the following C struct: typedef struct { float x[5]; } array; interoperable with this Fortran type: type, bind(c) :: array real(c_float) :: x(3) end type ANSWER: No. According to the words in 15.2.3, the answer is yes, since only interoperability of the types of the C and Fortran components is required. This is, however, an oversight. An edit is provided to correct this. EDITS: In the first sentence of the first paragraph after NOTE 15.12 in subclause 15.2.3 [04-007:398:11-12], replace "have types and type parameters that are interoperable with the types of the corresponding components of the struct type" with "would interoperate with corresponding components of the C struct type as described in 15.2.4 and 15.2.5 if the components were variables". SUBMITTED BY: Aleksandar Donev HISTORY: 06-106 m175 F03/0075 submitted 08-191r1 m184 Revised answer - Passed by J3 meeting 08-259 m185 Passed by J3 letter ballot #17 08-213 N1770 m187 Passed WG5 ballot 6 N1764-N1765 09-006T4 m187 N1773 interps for F2003 Corr 4 == N1775 ---------------------------------------------------------------------- NUMBER: F03/0076 TITLE: Scope of Fortran names of procedures with binding labels KEYWORDS: Interoperability, dummy procedures DEFECT TYPE: Interpretation STATUS: Passed by WG5 ballot QUESTION: Is the following conforming: module A interface subroutine CProc() bind(C,name="AnExternalCProcedure") end subroutine end interface end module module B interface subroutine CSub() bind(C,name="AnExternalCProcedure") end subroutine end interface end module ANSWER: No, the fragment is not conforming. The name of an external procedure is a global entity and is required to be unique. That is, the external C procedure AnExternalCProcedure, must be given a unique Fortran name inside a Fortran program. EDITS: None. SUBMITTED BY: Aleksandar Donev HISTORY: 06-107 m175 F03/0076 submitted 08-187 m184 Passed by J3 meeting 08-259 m185 Passed by J3 letter ballot #17 08-213 N1770 m187 Passed WG5 ballot 6 N1764-N1765 09-006T4 m187 N1773 interps for F2003 Corr 4 == N1775 ---------------------------------------------------------------------- NUMBER: F03/0077 TITLE: LBOUND of array structure component KEYWORDS: LBOUND, lower bounds, bounds, structure component, array sections DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot QUESTION: Given the declarations TYPE t REAL x REAL y(-5:5) END TYPE TYPE(t) z(10:20) What is the result of the following LBOUND references: LBOUND(z(10)%y) LBOUND(z%x) The confusion arises because the existing definition of LBOUND uses the undefined term "array structure component" in determining whether to return the lower bound in the or 1. It seems clear that Z(10)%Y must be an array structure component (so the answer ought to be -5) but it is not clear whether Z%X is one and therefore whether the result of that LBOUND ought to be 1 or 10. ANSWER: Yes, the result of the first LBOUND is indeed -5. The result of the second LBOUND is 1. Clarifying edits are provided. The description of the intrinsic function UBOUND suffers from the same flaw, and the edits provided fix that function as well. EDITS: To avoid the undefined term, or any long phrase, the edit changes the definition of "whole array" to include the case of a whole array component of a structure. [107:2-3] Replace the existing definition which is "A <> is a named array, which may be either a named constant (5.1.2.10, 5.2.9) or a variable; no subscript list is appended to the name." with "A <> is a named array or a structure component whose final is an array component name; no subscript list is appended." {Make "whole array" include the whole array component case.} [107:7-8] Replace "whole array name" with "whole array designator", twice. [326:8] After "a whole array" delete "or array structure component". {No longer need kludgy wording in LBOUND.} [358:6-7] After "a whole array" delete "or array structure component". {No longer need kludgy wording in UBOUND.} [436:36] After "named array" insert "or array component of a structure, with no subscript list." {Fix the glossary.} SUBMITTED BY: Aleksandar Donev HISTORY: 06-118 m175 F03/0077 submitted 08-174 m184 Revised with edits 08-174r1 m184 Fixed typo - Passed by J3 meeting 08-259 m185 Passed as modified by J3 LB #17 08-213 N1770 m187 Passed WG5 ballot 6 N1764-N1765 09-006T4 m187 N1773 interps for F2003 Corr 4 == N1775 ---------------------------------------------------------------------- NUMBER: F03/0078 TITLE: IEEE_SUPPORT_DATATYPE vs. mathematical equivalence KEYWORDS: IEEE_SUPPORT_DATATYPE, mathematical equivalence DEFECT TYPE: Interpretation STATUS: Passed by WG5 ballot QUESTION: Does the function IEEE_SUPPORT_DATATYPE (Section 14.8) override the mathematical equivalence rule (Section 7.1.8.3)? For example, could the program PROGRAM MAIN USE, INTRINSIC :: IEEE_ARITHMETIC USE, INTRINSIC :: IEEE_FEATURES X = 2.0 + 2.0 PRINT *, X END be executed as PROGRAM MAIN USE, INTRINSIC :: IEEE_ARITHMETIC USE, INTRINSIC :: IEEE_FEATURES X = 220.0*(1.0/55.0) PRINT *, X END if IEEE_SUPPORT_DATATYPE(X) is .TRUE.? Background: The committee recently ruled that 2.0 + 2.0 must produce the value 4.0 if IEEE_ARITHMETIC is in effect. I agree that if the particular operation the processor implements is addition of 2.0 and 2.0, the result must be 4.0. However, if IEEE_ARITHMETIC does not override the mathematical equivalence rule, the requirement is essentially meaningless, since there is no assurance that the expression in the program is the expression that will be evaluated. ANSWER: No, the mathematical equivalence rule is not overridden by USE of the IEEE_ARITHMETIC or IEEE_FEATURES modules. Doing so would prevent many benign and useful compiler optimizations and thus have an unnecessarily deleterious effect on performance. The mathematical equivalence displayed in the example is not a reasonable one, but deciding which mathematical equivalences are reasonable or not is outwith the scope of the standard. EDITS: None. SUBMITTED BY: Michael Ingrassia HISTORY: 06-124 m175 F03/0078 submitted 09-265 m189 Passed by J3 meeting 09-295 m190 Passed by J3 letter ballot #19 09-292 N1816 m191 Passed by WG5 ballot #7 {N1805/6} 10-006T5 m192 N1805 interps for F2003 Corr 5 == N1815 ---------------------------------------------------------------------- NUMBER: F03/0079 TITLE: Value of decimal exponent for a real zero value KEYWORDS: Data edit descriptors, Numeric editing, decimal exponent, zero value DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot QUESTION: In formatted output, what is the value of the decimal exponent produced for a real zero value under the D, E, EN, ES, and G edit descriptors? ANSWER: In such a case, the decimal exponent should have the value zero whether or not a nonzero scale factor is in effect. Edits are supplied to make this clear. DISCUSSION: The Fortran 2003 standard does not specify what the value of the decimal exponent of a real zero value should be under formatted output. Every implementation of which Sun is aware uses the value zero for the decimal exponent unless a nonzero scale factor is in effect. Different implementations format real zeros differently under nonzero scale factors, but the difference is mainly in the form of the mantissa and not the exponent. EDITS: [227:15+] At the end of the numbered list in 10.6.1 "Numeric editing", add: "(7) On output of a real zero value, the digits in the exponent field shall all be zero." SUBMITTED BY: Michael Ingrassia HISTORY: 06-125 m175 F03/0079 Submitted 07-281r2 m182 Passed by J3 meeting 08-133r2 m183 Passed by letter ballot #15 08-101 08-164 m184 Passed by WG5 ballot N1722-N1726 08-006AT3 m185 N1730 interps for F2003 Corr 3 == N1727 ---------------------------------------------------------------------- NUMBER: F03/0080 TITLE: Formatted output of a negative real zero value KEYWORDS: formatted output, negative zero, IEEE DEFECT TYPE: Interpretation STATUS: Passed by WG5 ballot QUESTION: Suppose a Fortran processor's representation of the real zero value is signed. When a negative real zero value is written using formatted output, does the Fortran 2003 standard require the representation of the zero value in the output field to be prefixed with a minus sign? ANSWER: Yes, the negative sign is required to appear in formatted output of a negative zero value. In subclause 10.6.1, list item (3) at [227:3-4] says "The representation of a negative internal value in the field shall be prefixed with a minus sign." For a processor that distinguishes between positive and negative zero, there is no exemption for output at [38:1-6]. For the case of IEEE reals, the IEEE_IS_NEGATIVE function at [375:25] explicitly says that -0.0 is "negative". EDITS: None. SUBMITTED BY: Michael Ingrassia HISTORY: 06-126 m175 F03/0080 Submitted 07-282r1 m182 Passed by J3 meeting 08-133r2 m183 Passed by letter ballot #15 08-101 08-164 m184 Passed by WG5 ballot N1722-N1726 08-006AT3 m185 N1730 interps for F2003 Corr 3 == N1727 ---------------------------------------------------------------------- NUMBER: F03/0081 TITLE: F edit descriptor with field width 0 KEYWORDS: Data edit descriptors, F edit descriptor, field width DEFECT TYPE: Interpretation STATUS: Passed by WG5 ballot QUESTION: Does the Fortran 2003 standard allow the output field produced by an F edit descriptor with a field width w whose value is zero for a real value whose magnitude is less than one to include an optional leading zero? For example, is the PRINT statement PRINT '(F0.2)', 0.01 allowed to write "0.01"? ANSWER: No. This is clear from Section 10.6.1 of the Fortran 2003 standard, item (6). EDITS: None SUBMITTED BY: Michael Ingrassia HISTORY: 06-127 m175 F03/0081 submitted 08-175 m184 Editorial revision - Passed by J3 meeting 08-213 m185 In J3 letter ballot #17 08-259 m185 Passed by J3 LB #17 08-213 N1770 m187 Passed WG5 ballot 6 N1764-N1765 09-006T4 m187 N1773 interps for F2003 Corr 4 == N1775 ---------------------------------------------------------------------- NUMBER: F03/0082 TITLE: VALUE in place of INTENT for pure procedure dummy arguments KEYWORDS: VALUE, INTENT, PURE DEFECT TYPE: Interpretation STATUS: Passed by WG5 ballot QUESTION: C1266 requires all nonpointer dummy arguments of a pure function to be data objects that have INTENT(IN). C1267 requires all dummy arguments of a pure subroutine to have specified intents. Was it intended that VALUE not be allowed in place of INTENT(IN), that is, was it intended that if a dummy argument of a pure procedure has the VALUE attribute, it is nonetheless also required to have the INTENT(IN) attribute explicitly specified? ANSWER: The possible extension of the VALUE attribute to allow omission of the INTENT(IN) attribute in the specific case of pure procedures was not considered during the development of Fortran 2003. Nonetheless, the standard is consistent and not in error, and so this restriction should remain in Fortran 2003. EDITS: None. SUBMITTED BY: Van Snyder HISTORY: 06-153 m176 F03/0082 submitted, fix edit, needs more 08-176 m184 Reversed answer + revised alternative edits Passed by J3 meeting 08-259 m185 Passed as modified by J3 LB #17 08-213 N1770 m187 Passed WG5 ballot 6 N1764-N1765 09-006T4 m187 N1773 interps for F2003 Corr 4 == N1775 ---------------------------------------------------------------------- NUMBER: F03/0086 TITLE: Elemental and BIND(C) KEYWORDS: Elemental, BIND(C), ENTRY DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot QUESTION: Is it allowed for a procedure to have both the BIND(C) and elemental attributes? Constraint C1242 disallows trivial ways of writing an elemental BIND(C) procedure. However, the following example achieves the effect for sub_c without violating the syntactic constraint. elemental subroutine sub(x) entry sub_c(x) bind(c) end subroutine sub ANSWER: No, it is not allowed. Constraint C1242 was intended to disallow the combination of elemental and BIND(C), but it inadvertently failed to cover the case shown in the above example. EDITS Replace C1242 in subclause 12.5.2.1 with [280:6-7] "C1242 An elemental procedure shall not have the BIND attribute.". SUBMITTED BY: Richard Maine HISTORY: 07-101 m179 Submitted F03/0086 07-101 m179 Passed by J3 meeting 07-272 m181 Passed as changed by J3 letter ballot #13 08-155 m184 Passed by WG5 ballot #4 N1711-N1721 08-006AT3 m185 N1730 interps for F2003 Corr 3 == N1727 ---------------------------------------------------------------------- NUMBER: F03/0087 TITLE: Entry names as dummy procedure arguments KEYWORDS: Entry names, dummy procedure arguments DEFECT TYPE: Interpretation STATUS: Passed by WG5 ballot QUESTION: Does the following subprogram fragment conflict with the 2003 Fortran standard? If so, was the conflict intended? entry A ( X ) interface subroutine X ( A ) abstract interface subroutine I ( ... ) ... end subroutine I end interface procedure (I) A end subroutine X end interface ... It seems that constraint C1255 in subclause 12.5.2.4 [283:10-12] prohibits the entry name A to appear in the PROCEDURE statement in the interface body. There shouldn't be a problem, however, since the PROCEDURE statement is in a different scoping unit. ANSWER: No, this program fragment conforms to the 2003 Fortran standard. EDITS: None NOTE: C1255 is pointless because Clause 16 applies. It could fruitfully be removed from a future revision of the Fortran standard. SUBMITTED BY: Van Snyder HISTORY: 07-105 m179 F03/0087 submitted 07-105 m179 Passed by J3 meeting 07-272 m181 Failed J3 letter ballot #13 07-250r1 08-192r1 m184 Revised answer - Passed by J3 meeting 08-259 m185 Passed by J3 letter ballot #17 08-213 N1770 m187 Passed WG5 ballot 6 N1764-N1765 09-006T4 m187 N1773 interps for F2003 Corr 4 == N1775 ---------------------------------------------------------------------- NUMBER: F03/0088 TITLE: Defined operations/assignments and VOLATILE/ASYNCHRONOUS KEYWORDS: Defined operations, defined assignment, VOLATILE, ASYNCHRONOUS DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot PROBLEM: Fortran 2008 Unresolved Technical issue 097 asked a question that also affects Fortran 2003. Consider this example: INTERFACE ASSIGNMENT(=) SUBROUTINE s(a,b) REAL,INTENT(OUT),VOLATILE :: a(1,*) REAL,INTENT(IN) :: b(:) END SUBROUTINE END REAL,POINTER :: p(:,:),q(:) ... CALL s(p,q) ! Violation of constraint C1233 [271:9-11], ! associating P with A p = q ! No constraint violation because ! syntax is not being used QUESTION: Did Fortran 2003 intend to enforce constraints on in defined assignment? ANSWER: Yes, the constraints and restrictions should be enforced in defined assignment and in defined operator evaluation. Edits are provided below to do this. EDITS: [262:16] add at the end of the paragraph "All restrictions and constraints that apply to actual arguments in a reference to the function also apply to the corresponding operands in the expression as if they were used as actual arguments." [263:12] insert after "the second argument." "All restrictions and constraints that apply to actual arguments in a reference to the subroutine also apply to the left-hand side and to the right-hand side enclosed in parentheses as if they were used as actual arguments." SUBMITTED BY: Stan Whitlock HISTORY: 07-172 m179 Submitted F03/0088 {see 07-171 for F08 fix} 07-172 m179 Passed by J3 meeting 07-272 m181 Passed as changed by J3 letter ballot #13 08-155 m184 Passed by WG5 ballot #4 N1711-N1721 08-006AT3 m185 N1730 interps for F2003 Corr 3 == N1727 ---------------------------------------------------------------------- NUMBER: F03/0089 TITLE: Interoperability of non-BIND derived types KEYWORDS: Interoperability, derived type DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot INTRODUCTION Subclause 15.2.3 of 04-007 says [398:9-12]: "A Fortran derived type is interoperable with a C struct type if the derived-type definition of the Fortran type specifies BIND(C) (4.5.1), the Fortran derived type and the C struct type have the same number of components, and the components of the Fortran derived type have types and type parameters that are interoperable with the types of the corresponding components of the struct type." QUESTIONS 1. Is a Fortran derived type for which BIND(C) is not specified interoperable with any C struct type? 2. Does a Fortran derived type interoperate with a C struct type that has a different number of components? 3. Does a Fortran derived type interoperate with a C struct type that specifies the same components in a different order? 4. Does a Fortran derived type with a pointer or allocatable component that has interoperable type and type parameters interoperate with any C struct type? ANSWERS: None of these Fortran derived types are interoperable with any C struct type. EDITS: [398:9] Replace "if" by "if and only if". SUBMITTED BY: Van Snyder HISTORY: 07-213 m180 Submitted F03/0089 07-213r2 m180 Passed by J3 meeting 07-272 m181 Passed by J3 letter ballot #13 08-155 m184 Passed by WG5 ballot #4 N1711-N1721 08-006AT3 m185 N1730 interps for F2003 Corr 3 == N1727 ---------------------------------------------------------------------- NUMBER: F03/0090 TITLE: Polymorphic array constructors KEYWORDS: polymorphic, array constructor DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot QUESTION: (1) Consider FUNCTION f1(dummy,n) CLASS(t) dummy TYPE(t) f1(n) f1 = [ (dummy,i=1,n) ] END FUNCTION Is this standard-conforming? (2) If the array constructor elements are polymorphic, is the array constructor polymorphic with the dynamic type of the elements? For example, consider FUNCTION f2(dummy,n) CLASS(t) dummy CLASS(t),ALLOCATABLE :: f2(:) IF (...) THEN ALLOCATE(f2(n),SOURCE=[(dummy,i=1,n)]) ! **1 ELSE ALLOCATE(f2(n),SOURCE=dummy) ! **2 END IF END FUNCTION The second ALLOCATE statement (marked **2) clearly allocates F2 with size N and the dynamic type of DUMMY. If the array constructor is polymorphic, the first ALLOCATE statement (marked **1) will have the same effect, otherwise it will allocate F2 with the dynamic type of F2 equal to the declared type of DUMMY. (3) If the array constructor is polymorphic, what is the dynamic type when multiple items have different dynamic types? ANSWER: (1) Yes. (2) No, it was not intended for array constructors to be polymorphic. A polymorphic array value, if desired, can be safely constructed by using an allocatable array function. (3) Not applicable. An edit is provided to clarify the situation. EDITS: [67:19+] Insert new constraint "CXXX (R469) An shall not be unlimited polymorphic.". [67:21] "same type" -> "same declared type" [68:9] "type and" -> "declared type and" [68:11] "type and" -> "declared type and" [68:14+] Insert new paragraph "The dynamic type of the array constructor is the same as its declared type." SUBMITTED BY: Van Snyder HISTORY: 07-231 m180 F03/0090 submitted (revised by M. Cohen) 07-231 m180 Passed by J3 meeting 07-272 m181 Failed J3 letter ballot #13 07-250r1 09-266 m189 Revised answer - Passed by J3 meeting 09-295 m190 Passed as amended by J3 letter ballot #19 09-292 N1816 m191 Passed as amended by WG5 ballot #7 {N1805/6} - F2008 fix in 10-140 passed at m191 10-006T5 m192 N1805 interps for F2003 Corr 5 == N1815 ---------------------------------------------------------------------- NUMBER: F03/0092 TITLE: Procedure characteristics and unlimited polymorphic KEYWORDS: Procedure, unlimited polymorphic DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot QUESTION: Consider abstract interface function foo (x) class(*) x class(*), pointer :: foo end function end interface procedure (foo), pointer :: proc_ptr procedure (foo), :: proc_tgt proc_ptr => proc_tgt According to the rules of procedure pointer assignment at [144:39-41], proc_ptr and proc_tgt are required to have the same interface characteristics. However because an unlimited polymorphic entity is not considered to have a declared type, the rules for characteristics of dummy data objects [256:26-32] and characteristics of function results [257:2-8] are not applicable. In addition, rules at [145:5-6] require that proc_ptr and proc_tgt have the same function return type. This also does not apply to unlimited polymorphic data. Is the example intended to be standard-conforming? ANSWER: Yes, the example was intended to be standard-conforming. An edit is provided to clarify this. The characteristics however are adequately defined. FOO, and thus both PROC_PTR and PROC_TGT have no type, but are polymorphic; this precisely characterises an unlimited polymorphic entity. Only the requirement of type matching in 7.4.2.2 is incorrect. EDITS to 04-007: [145:5] After "the same type" insert " or both be unlimited polymorphic". SUBMITTED BY: Jim Xia HISTORY: 07-247 m181 F03/0092 Submitted 07-247r1 m181 Passed by J3 meeting 07-279/321 m182 Passed as changed by J3 letter ballot #14 08-155 m184 Passed by WG5 ballot #4 N1711-N1721 08-006AT3 m185 N1730 interps for F2003 Corr 3 == N1727 ---------------------------------------------------------------------- NUMBER: F03/0093 TITLE: Allocatable array on intrinsic assignment with scalar expr KEYWORDS: allocatable array, intrinsic assignment DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot QUESTION: Consider CHARACTER(:), ALLOCATABLE :: str(:) ALLOCATE (CHARACTER(1) :: str(0:9)) str = 'reallocate?' According to the third paragraph of 7.4.1.3, the variable STR should be deallocated on this assignment because it has a deferred length type parameter different from the ('reallocate?'); it should then be allocated with its length type parameter the same as that of the and with the shape and bounds of . But the STR cannot be allocated with the shape and bounds of the since it is a scalar. The standard, however, provides a possible interpretation for the shape of two paragraphs later where it says "If is a scalar and is an array, the is treated as if it were an array of the same shape as with every element of the array equal to the scalar value of ." Q(1). Should the variable STR be reallocated in this case? Q(2). If so, what are the values of its length type parameter, shape and bounds? ANSWER: (1) Yes, STR should be reallocated - that is the purpose of the combination of ALLOCATABLE and deferred type parameters. If the user does not wish for automatic reallocation he can use "str(:) = 'do not reallocate'" instead. (2) The length parameter of str after the assignment is 11 (the value returned by LEN('reallocate?')). The shape and bounds should be unchanged. An edit is provided to clarify this. Note that the standard does not forbid, but does not specify semantics for, str = 'oops' when STR is an unallocated array with a deferred length parameter. An edit is supplied to make it clear that this is not allowed. Note also that this applies to parameterized derived types with deferred type parameters. EDITS: [139:22-] Insert new sentence at beginning of paragraph "If is an unallocated allocatable array, shall have the same rank as ." [139:25] Change "corresponding type parameters of ," to "corresponding type parameter of ." [139:25] Before ", with the shape of " Insert ". If is an array and is scalar it is allocated with the same bounds as before, otherwise it is allocated". SUBMITTED BY: Jim Xia HISTORY: 07-248 m181 F03/0093 Submitted 07-248r2 m181 Passed by J3 meeting 07-279 m182 Passed as changed by J3 LB #14 08-321 08-155 m184 Passed by WG5 ballot #4 N1711-N1721 08-006AT3 m185 N1730 interps for F2003 Corr 3 == N1727 N1727 m184 Note edit changes in F2003 Corrigendum 3 The second [139:25] edit leaves a "," after the insertion. The edit should read: [139:25] Replace ", with" with ". If is an array and is scalar it is allocated with the same bounds as before, otherwise it is allocated with". N1727 combines the 2 edits on [139:25] above as In the second sentence of the third paragraph of the subclause, change "corresponding type parameters of ," to "corresponding type parameter of . If variable is an array and is scalar it is allocated with the same bounds as before, otherwise it is allocated". ---------------------------------------------------------------------- NUMBER: F03/0094 TITLE: Final subroutine and VALUE attribute KEYWORDS: Final subroutine, VALUE DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot QUESTION: Currently, the F03 standard allows the VALUE attribute to be specified for the dummy argument of a final subroutine. This seems to defeat the purpose of final subroutine, which is intended to apply to the finalizable entity (the actual argument) itself. Should the dummy argument of a final subroutine be allowed to have the VALUE attribute? ANSWER: No, the VALUE attribute should not be allowed. An edit is provided to correct this oversight. EDITS to 04-007: [58:14] In the last sentence of C473 in 4.5.5 "Final subroutines", replace "not be INTENT(OUT)" with "not have the INTENT(OUT) or VALUE attribute". SUBMITTED BY: Jim Xia HISTORY: 07-249 m181 F03/0094 Submitted 07-249r1 m181 Passed by J3 meeting 07-279 m182 Passed by J3 letter ballot #14 08-321 08-155 m184 Passed by WG5 ballot #4 N1711-N1721 08-006AT3 m185 N1730 interps for F2003 Corr 3 == N1727 ---------------------------------------------------------------------- NUMBER: F03/0095 TITLE: Bounds remapped pointer assignment and ASSOCIATED KEYWORDS: pointer assignment, bounds-remapping, ASSOCIATED DEFECT TYPE: Interpretation STATUS: Passed by WG5 ballot QUESTION: Case (v) of intrinsic inquiry function ASSOCIATED [305:5-9] says If TARGET is present and is an array target, the result is true if the target associated with POINTER and TARGET have the same shape, are neither of size zero nor arrays whose elements are zero-sized storage sequences, and occupy the same storage units in array element order. Otherwise, the result is false. If POINTER is disassociated, the result is false. This will cause the intrinsic to return false if the POINTER is pointer assigned to the TARGET with bounds-remapping (POINTER and TARGET can be of different ranks). The same issue also exists for case (vii). Is the POINTER associated with the TARGET if the POINTER is pointer assigned to the TARGET with bounds-remapping? ANSWER: No, it is not intended that ASSOCIATED(POINTER, TARGET) return true after pointer assignment using a bounds-remapping that changes the shape or rank. This was a conscious decision made in response to a Fortran 90 interpretation request concerning dummy arguments that are different shaped versions of the same array in the calling procedure. EDITS to 04-007: none SUBMITTED BY: Jim Xia HISTORY: 07-259 m181 F03/0095 Submitted 07-259r2 m181 Passed by J3 meeting 07-279 m182 Passed by J3 letter ballot #14 08-321 08-155 m184 Passed by WG5 ballot #4 N1711-N1721 08-006AT3 m185 N1730 interps for F2003 Corr 3 == N1727 ---------------------------------------------------------------------- NUMBER: F03/0097 TITLE: Blanks as separators in NAMELIST input KEYWORDS: Namelist input, blanks, separators DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot QUESTION: 1) Was it intended that blanks be allowed as separators in Namelist Input? Consider a namelist input fragment: I = 3 J = 4 Page 243:12 says that the name-value subsequences are separated by value separators. Page 243:5 says that namelist value separators are the same as list directed value separators. Page 239:7 says those value separators are "...blanks between values" and then defines what the values are. The "J" above isn't a value, so the blanks aren't separators and the fragment is illegal for namelist input 2) Is there a similar problem with namelist comments as in this fragment? I = 3 ! this is a namelist comment Page 245:29-30 says that a name-value subsequence is separated from the ! in a comment by a value separator. ANSWER: 1) Yes, it was intended to allow blanks as separators for namelist input. Edits are supplied to correct the wording in the standard. 2) Yes, there is a similar problem with comments. The fragment is intended to be legal. The edits correct the error. EDITS: [243:5] Replace the paragraph by "A value separator for namelist formatting is a value separator for list-directed formatting (10.9), or one or more contiguous blanks between a nonblank value and the following object designator or "!" comment initiator." SUBMITTED BY: Dick Hendrickson HISTORY: 07-267 m181 F03/0097 Submitted 07-267r2 m181 Passed by J3 meeting 07-279 m182 Passed as changed by J3 LB #14 08-321 08-155 m184 Passed by WG5 ballot #4 N1711-N1721 08-006AT3 m185 N1730 interps for F2003 Corr 3 == N1727 ---------------------------------------------------------------------- NUMBER: F03/0098 TITLE: Does allocate with source= define subcomponents? KEYWORDS: allocate, source, define DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot QUESTION: Was it intended that an allocate with a source= clause define subcomponents? Bullet 11 on 422 says "Successful execution of an ALLOCATE statement ...causes the subcomponent to become undefined." ANSWER: An Allocate with a SOURCE= specifier was intended to define subcomponents. In fact, none of the lists in clause 16 account for a SOURCE= specifier. Edits are supplied to clarify this. EDITS: [113:21] At the end of the last sentence in 6.3.1.1 insert "unless the SOURCE= specifier appears and the corresponding component of the is allocated". [421:27] 16.5.5, list item 19, after "Allocation", insert ", except by an ALLOCATE statement with a SOURCE= specifier," [421:28+] 16.5.5, insert new list item after (19) "(19a) Successful execution of an ALLOCATE statement with a SOURCE= specifier causes a subobject of the allocated object to become defined if the corresponding subobject of the SOURCE= expression is defined." [422:41-43] 16.5.6, list item (11), replace list item with "Successful allocation of an ALLOCATE statement with no SOURCE= specifier causes a subcomponent of an allocated object to become undefined if default initialization has not been specified for that subcomponent." [422:43+] 16.5.6, add a new list item after (11), "(11a) Successful execution of an ALLOCATE statement with a SOURCE= specifier causes a subobject of the allocated object to become undefined if the corresponding subobject of the SOURCE= expression is undefined." SUBMITTED BY: Dick Hendrickson HISTORY: 07-268 m181 F03/0098 submitted 07-268r2 m181 Passed by J3 meeting 07-279 m182 Passed as changed by J3 LB #14 07-321 08-155 m184 Failed WG5 ballot #4 N1711-N1721 08-183 m184 Revised edits - Passed by J3 meeting 08-259 m185 Passed as modified by J3 LB #17 08-213 N1770 m187 Passed WG5 ballot 6 N1764-N1765 09-006T4 m187 N1773 interps for F2003 Corr 4 == N1775 ---------------------------------------------------------------------- NUMBER: F03/0099 TITLE: Clause 16 does not account for volatile variable KEYWORDS: volatile, defined, undefined DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot QUESTION: Should the various lists in clause 16 that describe definition and association be modified to include the effects of volatile variables? In particular, 16.4.2.1.1 through 16.4.2.1.2 do not mention the fact that pointer association status can be volatile and change by other means. 16.5.4 says "all other variables are initially undefined.? Can a volatile variable be initially defined by other means? 16.5 (26) says volatile variables "become defined", but they also can become undefined, by other means. Allocatable volatile variables can become allocated or unallocated by other means also. ANSWER: Yes, the lists in clause 16 should be modified to include the effects of volatility. In addition, the effects of volatile on pointer objects are not completely specified in clause 5. The effect on allocatable objects is not complete in clause 6. EDITS: [85:10] In the paragraph between note 5.21 and note 5.22, change "association status and array bounds" to "association status, dynamic type and type parameters, and array bounds" [415:27] Add a new paragraph at the end of 16.4.2.1.4 "The association status of a pointer object with the VOLATILE attribute may change by means not specified by the program." [421:43] In 16.5.5 list item (26) change "becomes" to "might become". [423:28+] In 16.5.6 after the last list item insert a new list item "(19) An object with the VOLATILE attribute (5.1.2.16) might become undefined by means not specified by the program." SUBMITTED BY: Dick Hendrickson HISTORY: 07-269 m181 F03/0099 submitted 07-269r2 m181 Passed by J3 meeting 07-279/07-321 Failed letter ballot 07-339 m182 Passed by J3 meeting 08-133r2 m183 Failed letter ballot #15 08-101 08-137 m183 Passed by J3 meeting 08-163 m184 Passed by J3 letter ballot #16 08-141 N1770 m187 Passed WG5 ballot 6 N1764-N1765 09-006T4 m187 N1773 interps for F2003 Corr 4 == N1775 ---------------------------------------------------------------------- NUMBER: F03/0101 TITLE: Is UDDTIO output suitable for namelist and list-directed input KEYWORDS: UDDTIO, list-directed I/O, namelist I/O DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot QUESTION: The first paragraph of 10.9.2 says that the form of the values produced by list-directed output is the same as that required for input. It also says values are separated blanks or commas, etc. The first paragraph of 10.10.2 has similar words for namelist output. It also requires that the variable name be produced in upper case and that the output consist of name-value pairs. Is it intended that output produced by user-defined derived-type output routines conform to these rules? ANSWER: No, it was not intended to constrain the user-defined derived-type output values. There should be an exception similar to the one for adjacent undelimited character values. User-defined derived-type output fields do not need to be readable by either namelist or list-directed input. EDITS: [241:5] Add at the end of the paragraph "The form of the values produced by a user-defined derived-type output routine invoked during list-directed output is specified by the invoked routine. This form need not be compatible with list-directed input." [246:4] After "and logical values" add ", and output produced by user-defined derived-type output" [246:7] Add at the end of the paragraph "The form of the output produced by a user-defined derived-type output routine invoked during namelist output is specified by the invoked routine. This form need not be compatible with namelist input." SUBMITTED BY: Dick Hendrickson HISTORY: 07-275 m181 F03/0101 Submitted 07-275r2 m181 Passed by J3 meeting 07-279 m182 Passed as changed by J3 LB #14 08-321 08-155 m184 Passed by WG5 ballot #4 N1711-N1721 08-006AT3 m185 N1730 interps for F2003 Corr 3 == N1727 ---------------------------------------------------------------------- NUMBER: F03/0102 TITLE: Evaluation of bound-expr in data pointer assignment KEYWORDS: pointer, pointer assignment, bounds, expression DEFECT TYPE: Clarification STATUS: Passed by WG5 ballot DISCUSSION: Currently there are no rules in 7.4.2.1 to prohibit changing of a pointer's association status during evaluation of bound expressions in a data pointer assignment (pointer with either bounds-spec or bounds-remapping specified). This may lead to ambiguous code with regard to the evaluation orders between the bound expression and the data pointer assignment itself. Consider the following code, integer, target :: tar2(100, 100) integer, target :: tar1(100) integer, pointer :: ptr(:,:) ptr(-2:, f1(ptr, tar1, 1, 1):) => tar2 print*, lbound(ptr) print*, ubound(ptr) print*, size(ptr) contains function f1(ptr, arr, i, j) integer :: i, j, f1 integer, pointer :: ptr(:, :) integer, target :: arr(:) ptr (i:j, i:j) => arr f1 = -1 end function end In 7.4.1.3 for interpretation of intrinsic assignments, there are rules explicitly requesting evaluation of all expressions in variable occurred before the variable is defined [139:14-19]. It appears that data pointer assignment should also follow similar rules. Note the similar problem also exists for evaluating the if it references a function that returns a data pointer. QUESTION: (a) Is this program intended to be standard conforming? (b) If it is standard conforming, then what would it print? ANSWER: This program does not conform to the Fortran Standard. The assertion that there are no rules about pointer association status is false because changes in pointer association status necessarily cause changes in definition status, as explained in the opening paragraph of "16.4.2 Pointer association status" which states "If a pointer is associated with a target, the definition status of the pointer is either defined or undefined, depending on the definition status of the target." The reference to F1(PTR,TAR1,1,1) executes the pointer assignment PTR(I:J,I:J)=>ARR; this causes its actual argument PTR to become undefined (using the quoted rule from 16.4.2). In 7.1.8 paragraph 3, it says "If a function reference causes definition or undefinition of an actual argument of the function, that argument or any associated entities shall not appear elsewhere in the same statement." However, PTR appears elsewhere in that statement (as the base object of the variable in the assignment), violating this requirement. Therefore the program is not standard-conforming. EDITS: None. NOTE: This would be clearer if the undefinition case were also added to the list of "Events that cause variables to become undefined" in clause 16, e.g. "(n) When a pointer becomes associated with a target that is undefined, the pointer becomes undefined." This is recommended for a future revision of the Standard. SUBMITTED BY: Jim Xia HISTORY: 07-297r1 m182 F03/0102 submitted 07-297r2 m182 Passed by J3 meeting 08-133r2 m183 Failed J3 letter ballot 08-135 m183 Passed by J3 meeting 08-163 m184 Passed by J3 letter ballot #16 08-141 N1770 m187 Passed WG5 ballot 6 N1764-N1765 09-006T4 m187 N1773 interps for F2003 Corr 4 == N1775 ---------------------------------------------------------------------- NUMBER: F03/0104 TITLE: Deallocation and finalization of bounds-remapped pointers KEYWORDS: deallocate, finalization, bounds-remapping, pointer DEFECT TYPE: Interpretation STATUS: Passed by WG5 ballot INTRODUCTION: Consider the following example assuming a derived type of X is declared previously and made accessible to the current scoping unit, type(X), pointer :: a(:), b(:,:) allocate (a(100)) b(1:10, 1:10) => a DEALLOCATE (b) QUESTION: (a) Is DEALLOCATE (b) in the example intended to be standard conforming? (b) If the answer to (a) is yes, and also assume type X has finalizers of both rank-one and rank-two, then which finalizer should be invoked by the DEALLOCATE statement. ANSWER: (a) Yes, the example is intended to be standard conforming. The deallocation of pointer b should be executed successfully. (b) The Standard is clear about how the finalizations are processed in this case. In 4.5.5.1, the first step in invoking the appropriate final subroutine requires a finalizer matching the rank of the entity being finalized. In this case, object b is being finalized and therefore the rank-two final subroutine of type X will be invoked with object b as the actual argument. EDITS: None. SUBMITTED BY: Jim Xia HISTORY: 07-299 m182 F03/0104 Submitted; Passed by J3 meeting 08-133r2 m183 Passed by letter ballot #15 08-101 08-164 m184 Passed by WG5 ballot N1722-N1726 08-006AT3 m185 N1730 interps for F2003 Corr 3 == N1727 ---------------------------------------------------------------------- NUMBER: F03/0106 TITLE: Inquire by unit inconsistencies KEYWORDS: inquire, unit, not connected DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot QUESTION: There are many things that can be inquired about, such as ACTION or READ, that are purely file or connection properties. In some cases, such as ACTION, the specifier description includes "If there is no connection [the result is] the value UNDEFINED" or similar words. In other cases, such as READ, there seems to be a tacit assumption that there is a file connected to the unit. The descriptions refer to "the file" and don't specify a result if there is no connection. In most cases, there is a phrase like "if the processor is unable to determine if the file ... [the result is] {UNDEFINED, UNKNOWN, -1, etc.}". Question 1) Are the inquire specifiers DIRECT, ENCODING, FORMATTED, NAMED, NEXTREC, NUMBER, POS, READ, READWRITE, SEQUENTIAL, SIZE, STREAM, UNFORMATTED, and WRITE allowed in an INQUIRE by unit when there is no file connected to the unit? Question 2) If so, should the descriptions for the above specifiers be clarified by adding phrases such as "if there is no file specified or connected" to the "UNKNOWN" result descriptions? ANSWER: Question 1) Yes. In an inquiry by unit, the specifiers have little meaning when there is no file connected to the unit. However, the standard should specify the results. Question 2) Yes, edits are supplied below. Note: 9.9.1.15 NAMED= [213:10] needs no edit; the value will be false if the unit specified by UNIT= is not connected to a file EDITS: 9.9.1.8 DIRECT= At [212:15], add to the end of the last sentence "or if the unit specified by UNIT= is not connected to a file" 9.9.1.9 ENCODING= At [212:21], after "file" insert "or if the unit specified by UNIT= is not connected to a file" 9.9.1.12 FORMATTED= At [212:36], add to the end of the last sentence "or if the unit specified by UNIT= is not connected to a file" 9.9.1.16 NEXTREC= At [213:15], change "or if" to ", if" and At [213:16], after "condition" insert ", or if the unit specified by UNIT= is not connected to a file" 9.9.1.17 NUMBER= Replace [213:20-21] with "Execution of an INQUIRE by file statement causes the in the NUMBER= specifier to be assigned the value of the external unit number of the unit that is connected to the file. If there is no unit connected to the file, the value -1 is assigned. Execution of an INQUIRE by unit statement causes the to be assigned the value specified by UNIT=." 9.9.1.21 POS= At [214:19], change "or if" to ", if" and At [214:20], after "conditions" insert ", or if the unit specified by UNIT= is not connected to a file" 9.9.1.23 READ= At [215:2], add to the end of the last sentence "or if the unit specified by UNIT= is not connected to a file" 9.9.1.24 READWRITE= At [215:7], add to the end of the last sentence "or if the unit specified by UNIT= is not connected to a file" 9.9.1.27 SEQUENTIAL= At [215:26], add to the end of the last sentence "or if the unit specified by UNIT= is not connected to a file" 9.9.1.29 SIZE= At [215:34], after "determined" insert "or if the unit specified by UNIT= is not connected to a file" 9.9.1.30 STREAM= At [216:5], add to the end of the last sentence "or if the unit specified by UNIT= is not connected to a file" 9.9.1.31 UNFORMATTED= At [216:10], add to the end of the last sentence "or if the unit specified by UNIT= is not connected to a file" 9.9.1.32 WRITE= At [216:15], add to the end of the last sentence "or if the unit specified by UNIT= is not connected to a file" SUBMITTED BY: Dick Hendrickson HISTORY: 07-309 m182 F03/0106 Submitted 07-309r1 m182 Answer based on 07-310; Passed by J3 meeting 08-133r2 m183 Passed letter ballot #15 08-101 08-164 m184 Passed WG5 ballot #5 N1722-N1726 08-006AT3 m185 N1730 interps for F2003 Corr 3 == N1727 N1727 m184 Note edit changes in F2003 Corrigendum 3 In the edit to 9.9.1.17, N1727 puts "scalar-int-variable" in italics, ie, . ---------------------------------------------------------------------- NUMBER: F03/0107 TITLE: Are the IEEE_* elemental routines required KEYWORDS: IEEE, elemental routines DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot QUESTION: The descriptions for all of the IEEE elemental intrinsics listed in 14.9 say something like "shall not be invoked if IEEE_SUPPORT_DATATYPE(X) is false". I believe this was to allow a careful programmer to do something like if (IEEE_SUPPORT_DATATYPE(x)) then x = IEEE_SCALB(x,2) else x = x*4 endif and program around partial IEEE support. But 14.9.2 says that "IEEE_ARITHMETIC contains the following [routines] for which IEEE_SUPPORT_DATATYPE(X) [is] true" I'd read that as saying the functions aren't there for cases where IEEE_SUPPORT_DATATYPE is false. But, then, there is no way to program around their absence. The example above will fail at load time because IEEE_SCALB is absent. If a processor provides the IEEE_ARITHMETIC module must it provide versions of all of the intrinsics for all of the available datatypes, including those for which IEEE_SUPPORT_DATATYPE() is false? ANSWER: Yes, edits are provided to make this clear. DISCUSSION: It was intended that the above coding snippet could be used by a careful programmer to program portably for processors which have varying degrees of IEEE support. This might require processors to provide some stub function for each routine and for each non-IEEE datatype they support. If a program invokes one of the stub routines, it is a run-time programming error. Nevertheless, a program which has references to the routines, but doesn't invoke them, must load and execute. EDITS: In the first paragraph of subclause 14.9.2 [370:8-9] Replace "for reals X and Y for which IEEE_SUPPORT_DATATYPE(X) and IEEE_SUPPORT_DATATYPE(Y) are true" with "for all reals X and Y" NOTE: The following note should be inserted at the end of the section on IEEE arithmetic in a future standard: "The standard requires that code such as if (IEEE_SUPPORT_DATATYPE(x)) then x = IEEE_SCALB(x,2) else x = x*4 endif be executable. The elemental functions in the IEEE_ARITHMETIC module (14.9.2) must exist for all real kinds supported by the processor, even if IEEE_SUPPORT_DATATYPE returns false for some kinds. However, if IEEE_SUPPORT_DATATYPE returns false for a particular kind, these functions must not be invoked with arguments of that kind. This allows a careful programmer to write programs that work on processors that do not support IEEE arithmetic for all real kinds. The processor might provide stub routines which allow the program to link and execute, but which will abort if they are invoked." SUBMITTED BY: Dick Hendrickson HISTORY: 07-312 m182 F03/0107 Submitted 07-312r2 m182 Passed by J3 meeting 08-133r2 m183 Passed letter ballot #15 08-101 08-164 m184 Passed WG5 ballot #5 N1722-N1726 08-006AT3 m185 N1730 interps for F2003 Corr 3 == N1727 ---------------------------------------------------------------------- NUMBER: F03/0108 TITLE: Is IEEE_SUPPORT_NAN consistent with the other IEEE_SUPPORT functions KEYWORDS: IEEE_SUPPORT_NAN, IEEE support functions DEFECT TYPE: Clarification STATUS: Passed by WG5 ballot QUESTION: The restriction of IEEE_IS_NAN requires that IEEE_SUPPORT_NAN returns the value true. The restrictions for the similar functions IEEE_IS_{FINITE, NEGATIVE, and NORMAL} all require that IEEE_SUPPORT_DATATYPE be true. This is a much stronger restriction. Should IEEE_SUPPORT_NAN also require that IEEE_SUPPORT_DATATYPE return true? ANSWER: No. The IEEE_SUPPORT_NAN restriction is weaker than requiring IEEE_SUPPORT_DATATYPE but IEEE_SUPPORT_NAN is sufficient. IEEE_SUPPORT_DATATYPE is used in IEEE_IS_FINITE, IEEE_IS_NEGATIVE, and IEEE_IS_NORMAL because there are no IEEE_SUPPORT_* inquiry functions to query support for finite, negative, or normal. IEEE_SUPPORT_INF asks about infinities not finites and IEEE_SUPPORT_DENORMAL only covers denormals and not the other non-finites (NaNs and Infinities). EDITS: None. SUBMITTED BY: Dick Hendrickson HISTORY: 07-328 m182 F03/0108 Submitted 07-328r2 m182 Passed by J3 meeting 08-133r2 m183 Passed letter ballot #15 08-101 08-164 m184 Passed WG5 ballot #5 N1722-N1726 08-006AT3 m185 N1730 interps for F2003 Corr 3 == N1727 ---------------------------------------------------------------------- NUMBER: F03/0109 TITLE: Referencing deferred binding via absent dummy argument KEYWORDS: Type-bound procedure, deferred binding DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot QUESTION: The intent was that it would be impossible to reference a deferred binding. However, it doesn't appear to me that this intent was achieved. Consider the following program program P type, abstract :: T contains procedure(sub), nopass, deferred :: deferred_proc end type T call sub contains subroutine Sub ( X ) class(t), optional :: X call x%deferred_proc end subroutine Sub end program P Is this a valid program? If not, what restriction of the standard does it violate? Since x%deferred_proc has the NOPASS attribute, this does not require the value of x (4.5.7) and thus is not a reference to x (2.5.6). Therefore, the first item in the second list in 12.4.1.2 (at [04-007:272:32-33]) does not prohibit this. ANSWER: This was not intended to be a valid program. A type-bound procedure shall not be invoked through an absent dummy argument. An edit is supplied to clarify this situation. The same flaw is present for procedure pointer component invocation. EDITS: Add new items to the second list in 12.4.1.6, [273:12+] "(11) It shall not be supplied as the in a . (12) It shall not be supplied as the in a ." SUBMITTED BY: Van Snyder HISTORY: 07-338 m182 F03/0109 submitted - Passed by J3 meeting 08-133r2 m183 Failed J3 letter ballot 08-136 m183 Passed by J3 meeting 08-163 m184 Passed by J3 letter ballot #16 08-141 N1770 m187 Passed WG5 ballot 6 N1764-N1765 09-006T4 m187 N1773 interps for F2003 Corr 4 == N1775 Note to Editor: The edit for bullet (12) should say "" instead of "" when applied to Fortran 2008. Compare R741 on page 157 of 08-007r2 with [143:35] of 04-007. ---------------------------------------------------------------------- NUMBER: F03/0111 TITLE: Is defined assignment to a vector subscripted array allowed? KEYWORDS: defined assignment, vector-valued subscripts, elemental DEFECT TYPE: Clarification STATUS: Passed by WG5 ballot QUESTION: Is the assignment statement in subroutine cg1018 standard conforming? It does an elemental defined assignment to an array with a vector valued subscript. Several compilers reject this assignment, claiming that an INTENT(OUT) argument can't be associated with a vector-valued actual argument. According to 142:6-7, this is a defined elemental assignment. Lines 26 to 30 of 142 are "The interpretation of a defined assignment is provided by the subroutine that defines it. If the defined assignment is an elemental assignment and the variable in the assignment is an array, the defined assignment is performed element-by-element, in any order, on corresponding elements of variable and expr." The first line looks like a general definition of defined assignment and the second line looks like a qualification for the specific case of elemental assignment. The qualification has to mean that the assignments are performed on an element-by-element basis and this surely must mean that the statement is processed as if it were expanded into something like TLA1L(7) = UDA1R(7) TLA1L(1) = UDA1R(1) TLA1L(3) = UDA1R(3) ... and then the assignment subroutine is invoked on an element-by-element basis following the rules in chapter 12. Page 140, lines 4-5 have essentially identical words for intrinsic assignment and intrinsic assignment to a vector valued array, including derived type arrays, is allowed (if not many-to-one). The processors that reject the test program apparently interpret the assignment as Call U_TO_T( TLA1L(NFV1), (UDA1R)) without doing the assignment on an element-by-element basis. If that interpretation is correct, then we have the unusual situation where TLA1L(NFV1) = TLA1L is standard conforming if the assignment is intrinsic and non-standard if the assignment is defined. MODULE c_TESTS integer, save :: nfv1(10) = [1,2,3,4,5,6,7,8,9,10] TYPE UNSEQ REAL R END TYPE UNSEQ TYPE SEQ sequence REAL R END TYPE SEQ INTERFACE ASSIGNMENT(=) MODULE PROCEDURE U_TO_T END INTERFACE ASSIGNMENT(=) CONTAINS ELEMENTAL PURE SUBROUTINE U_TO_T(T,U) TYPE(SEQ),INTENT(IN) :: U TYPE(UNSEQ), INTENT(OUT) :: T T%R = U%R END SUBROUTINE U_TO_T SUBROUTINE CG1018(TLA1L,UDA1R) TYPE(UNSEQ) TLA1L(10) TYPE(SEQ) UDA1R(10) TLA1L(NFV1) = UDA1R !??????? END SUBROUTINE END MODULE c_TESTS ANSWER: This is not standard conforming. According to [271:3-5] If the actual argument is an array section having a vector subscript, the dummy argument is not definable and shall not have the INTENT (OUT), INTENT (INOUT), VOLATILE, or ASYNCHRONOUS attributes. EDITS: None SUBMITTED BY: Dick Hendrickson HISTORY: 08-104 m183 F03/0111 submitted 08-104r1 m183 Passed by J3 meeting 08-163 m184 Passed by J3 letter ballot #16 08-141 N1770 m187 Passed WG5 ballot 6 N1764-N1765 09-006T4 m187 N1773 interps for F2003 Corr 4 == N1775 ---------------------------------------------------------------------- NUMBER: F03/0112 TITLE: Attributes allowed for dummy arguments in defined assignments KEYWORDS: defined assignment, dummy argument, attributes DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot INTRODUCTION: It seems the standard is quite loose in allowing various attributes declared for the dummy arguments used in a defined assignment (7.4.1.4). In particular, attributes such as POINTER and ALLOCATABLE can be declared for dummy arguments in the defined assignment. However the interpretations on their declarations need to be clarified. QUESTION: Consider the follow subroutines (assuming a derived type DT already defined) Q1. Are POINTER and ALLOCATABLE attributes allowed for the second dummy argument in defined assignment? interface ASSIGNMENT (=) subroutine defAssgn1 (dt1, dt2) type(DT), intent(out) :: dt1 type(DT), POINTER, intent(in) :: dt2 end subroutine end interface In 12.3.2.1.2 [263:10-12], the standard says the following "A defined assignment is treated as a reference to the subroutine, with the left-hand side as the first argument and the right-hand side enclosed in parentheses as the second argument." This statement seems to prohibit the use of subroutine defAssgn1 for defined assignment since a pointer enclosed in parentheses refers to its associated target not the pointer itself, as indicated by rules in 7.1.4.1 [123:39-124:3]. Q2. Are POINTER and ALLOCATABLE attributes allowed for the first dummy argument in defined assignment? interface ASSIGNMENT (=) subroutine defAssgn2 (dt1, dt2) type(DT), POINTER, intent(out) :: dt1 type(DT), intent(in) :: dt2 end subroutine end interface There are no rules in the standard that disallow this declaration. However the use of POINTER/ALLOCATABLE attributes on the first dummy argument is very doubtful. Since POINTER/ALLOCATABLE attributes don't disambiguate generic declarations(16.2.3), their use will prevent the normal declarations of defined assignments, wherein dt1 is declared without POINTER or ALLOCATABLE attribute. ANSWER: Yes to both questions. The interface blocks are not defective. The standard places very few restrictions on the arguments to defined assignment subroutines: [363:6...] Each of these subroutines shall have exactly two dummy arguments. Each argument shall be nonoptional. The first argument shall have INTENT (OUT) or INTENT (INOUT) and the second argument shall have INTENT (IN). ... Preventing the first argument from having the POINTER attribute violates F90. Preventing the second argument from having the ALLOCATABLE attribute would introduce a prohibition not specified by TR 15581, and might therefore be viewed as an incompatibility that ought to be announced in subclause 1.5. A program couldn't reference defAssgn1 by way of defined assignment because the right-hand side of a defined assignment is treated as an expression enclosed in parentheses which would have neither the POINTER nor the ALLOCATABLE attribute. A note is provided to draw the readers attention. EDITS: [263:13+16+] At the end of 12.3.2.1.2 insert a new NOTE 12.10+: "NOTE 12.10+ If the second argument of a procedure specified in a defined assignment interface block has the POINTER or ALLOCATABLE attribute, it cannot be accessed by defined assignment, since the right-hand side of the assignment is enclosed in parentheses before being associated as an actual argument with the second argument. This makes it an expression, which does not have the POINTER or ALLOCATABLE attribute." SUBMITTED BY: Jim Xia HISTORY: 08-120 m183 F03/0112 submitted 08-120r1 m183 Create answer 08-120r2 m183 Passed by J3 meeting 08-163 m184 Failed J3 letter ballot 08-141 08-186r1 m184 Another answer - Passed by J3 meeting 08-259 m185 Failed J3 letter ballot #17 08-213 08-263r1 m185 Revised answer - passed by J3 meeting 09-187r2 m188 Passed J3 letter ballot 09-155 - F2008 edit passed at m188 N1816 m191 Passed by WG5 ballot #7 {N1805/6} 10-006T5 m192 N1805 interps for F2003 Corr 5 == N1815 ---------------------------------------------------------------------- NUMBER: F03/0113 TITLE: Size and uniqueness considerations for ID= KEYWORDS: asynchronous I/O, ID=, size DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot QUESTION: The ID= specifier returns an identifier (or "handle") for an async i/o request. Must this fit inside the smallest integer kind supported by the processor? Consider: Integer(Selected_Int_Kind(1)) x(1000) Character(80) :: test(1000) = (/ ... /) ... Do i=1,1000 Write (17,'(a)',Asynchronous='Yes',Id=x(i)) test(i) End Do ... Do i=1,1000 Wait (17,Id=x(i)) End Do X is only guaranteed to have approximately 20 values available, and in practice will probably only have 256 such values, so we are certainly not going to have 1000 unique handles. Without loss of generality, suppose that one such duplicate value is 4. After WAIT(17,ID=4), the async i/o request with ID 4 is no longer pending. This means that the subsequent WAIT(17,ID=4) is not conforming to the standard since it requires that the ID= value is one that is pending. (1) Is the processor permitted to require a minimum size for ID= (e.g. such as default integer)? Clearly 1000 values do not fit into a 256-valued object, but apart from that, (2) Is the processor required to produce unique ID= values for each multiple asynchronous i/o operation? One might conjecture that if the processor returned ID=4 for two or more async i/o requests on the same unit, the first WAIT for ID=4 would wait for the first such async i/o request and the second one would wait for the second such async i/o request. (3) Does WAIT-ing on an ID= value wait for all async i/o operations that have that as the handle, or are these queued up? Unlike other i/o-related specifiers, there does not seem to be any constraint on the value returned for ID= (such as being non-zero or non-negative). In the case of the i/o being completed synchronously, there does not appear to be any way of returning a "non-handle" to the user program (one might have conjectured that zero was not a handle, but this is not supported by the text of the standard). (4) Was there intended to be a "non-handle" return for ID=? DISCUSSION: It is understood that resource considerations may limit the number of outstanding asynchronous i/o requests, but 19 (the limit implied by the minimum-size integer that follows the model in c13) seems awfully small; for that matter 256 seems pretty small for todays operating systems. ANSWER: (1) Yes, the standard should require the ID= specifier to be default integer or bigger. An edit is provided. (2) Yes, all pending data transfer operation identifiers on a particular unit are required to be unique. An edit is provided to clarify this. (3) ID= values are required to be unique, so this question does not arise. (4) Yes, the value zero should not be a handle but an indication the request was completed synchronously. An edit is provided to add this. EDITS: In 9.5.1 Control information list, [187:2] "ID = " -> "ID = " [187:10+] Insert new BNF rule and constraint "R913a <> C908a (R913a) The shall have a decimal range no smaller than that of default integer." {Require default integer or larger.} In 9.5.1.8 ID= specifier in a data transfer statement [190:17] Change "This value" to "If this value is zero, the data transfer operation has been completed. A nonzero value" {Zero = "it was done synchronously already" value.} [190:18] After "operation." insert "This identifier is different from the identifier of any other pending data transfer operation for this unit." {Require uniqueness.} [206:18] Before "the identifier" insert "zero or". [206:20] After "operation" insert ", if any,". {Make ID=zero do nothing in WAIT.} SUBMITTED BY: Malcolm Cohen HISTORY: 08-122 m183 F03/0113 submitted 08-122r1 m183 Draft answer 08-122r2 m183 Passed by J3 meeting 08-163 m184 Passed by J3 letter ballot #16 08-141 N1770 m187 Passed WG5 ballot 6 N1764-N1765 as revised 09-006T4 m187 N1773 interps for F2003 Corr 4 == N1775 ---------------------------------------------------------------------- NUMBER: F03/0114 TITLE: Inconsistent restrictions on i/o specifiers KEYWORDS: I/O specifier, default logical DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot QUESTION: All of the i/o specifiers that return INTEGER values permit any kind of integer to be used, even though this is likely to cause problems with small integers. But all of the i/o specifiers that return LOGICAL values require "full-size" (default) logical variables, even though every kind of LOGICAL can represent every LOGICAL value, viz .TRUE. and .FALSE.. Should these be consistent, i.e. should every kind of LOGICAL be allowed for EXIST=, NAMED=, OPENED=, and PENDING=? ANSWER: Yes, these should have been consistent. Edits are provided. EDITS: All edits are against 04-007. After the first paragraph in Clause 6, delete the BNF definition of and constraint for \si{default-logical-variable}: [103:17-18] delete R605 and C604 Replace every occurrence of \si{scalar-default-logical-variable} in clause 9 with \si{scalar-logical-variable}: [210:18] in 9.9.1 EXIST= [210:25] in 9.9.1 NAMED= [210:28] in 9.9.1 OPENED= [210:30] in 9.9.1 PENDING= [212:24] in 9.9.1.10 EXIST= [213:9 ] in 9.9.1.15 NAMED= [213:23] in 9.9.1.18 OPENED= [213:25] in 9.9.1.18 OPENED= {note: is not used in 9.9.1.20 PENDING= (page 214)] SUBMITTED BY: Malcolm Cohen HISTORY: 08-123 m183 F03/0114 submitted 08-123r1 m183 make answer YES; Passed by J3 meeting 08-163 m184 Passed by J3 letter ballot #16 08-141 N1770 m187 Passed WG5 ballot 6 N1764-N1765 as revised 09-006T4 m187 N1773 interps for F2003 Corr 4 == N1775 ---------------------------------------------------------------------- NUMBER: F03/0117 TITLE: STOP executed via function in input/output list KEYWORDS: STOP DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot QUESTION: Interpretation F90/000209 considered the 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? The answer (w.r.t. STOP), included in F95 corrigendum 2, replied 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. However, on further consideration of the reasoning behind this answer, it seems unhelpful to rule out STOP, which is often used for user signalling of error conditions, during i/o operations. For one thing, if the data transfer statement being executed is READ, the question about file state has a very straightforward answer. It might also be considered unhelpful in the WRITE case for STOP to cause the user's entire file system to be potentially reformatted instead of just making the contents of the relevant file undefined. Furthermore, the user who wants to signal an error can cause error termination via one of the "approved" methods such as DEALLOCATE of an unallocated array. It seems less than unhelpful to force the user to use such a circumlocution simply for standards conformance, and the question about file state can equally be asked of this situation. Q1. Is execution of a STOP statement during internal i/o allowed? Q2. Is execution of a STOP statement during a READ statement allowed? Q3. Is execution of a STOP statement during a WRITE statement allowed? Q4. What is the effect on the file state of executing the following code fragment during a WRITE statement to an external file: REAL,ALLOCATABLE :: array(:) DEALLOCATE(array) (And if the answer to Q3 is yes, does a STOP statement have the same effect.) ANSWER: The answer to the first three questions is yes, this should have been allowed. An edit is provided to correct the standard. The answer to Q4 is that the effects on the file currently being written by that WRITE statement are not standardised. (This was, in fact, the situation before the adoption of the previous interp answer.) A clarifying edit is provided to indicate that the contents of the file become undefined. EDITS: [195:23+] In 9.5.3 "Execution of a data transfer input/output statement", immediately before Note 9.38 insert a new paragraph "If execution of the program is terminated during execution of a WRITE or PRINT statement, the contents of the file become undefined." Delete [219:30] the last paragraph of 9.11 which currently reads "A STOP statement shall not be executed during execution of an input/output statement." SUBMITTED BY: Malcolm Cohen HISTORY: 08-173 m184 F03/0117 submitted - Passed by J3 meeting 08-259 m185 Passed as modified by J3 LB #17 08-213 N1770 m187 Passed WG5 ballot 6 N1764-N1765 09-006T4 m187 N1773 interps for F2003 Corr 4 == N1775 ---------------------------------------------------------------------- NUMBER: F03/0119 TITLE: Elemental procedures and deferred length character components KEYWORDS: deferred length, elemental DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot QUESTION: Constraint C1279 says "In the scoping unit of an elemental subprogram, an object designator with a dummy argument as the base object shall not appear in a except as the argument to one of the intrinsic functions BIT_SIZE, KIND, LEN, or the numeric inquiry functions (13.5.6)." It has been stated in previous J3 papers that the reason for this restriction is to ensure that every iteration of a single invocation of an elemental procedure will have the same stack size: and this desire was achieved in Fortran 95. However, the situation changes with deferred-length character components. Consider example 1: PROGRAM example1 TYPE t CHARACTER(:),ALLOCATABLE :: cp END TYPE TYPE(t) array(100) DO i=1,100; array(i)%cp = REPEAT('x',i); END DO CALL zap(array) ... CONTAINS ELEMENTAL SUBROUTINE zap(x) TYPE(t),INTENT(INOUT) :: x REAL work(LEN(x%cp)) ... END SUBROUTINE END PROGRAM In the invocation "CALL zap(array)", the invoked procedure will have a different size for its WORK array for every element of ARRAY. Thus the restriction no longer achieves its aim (though this aim is not actually stated in the standard). However, as stated the restriction still prohibits the very similar program example2: PROGRAM example2 INTEGER :: array(100) = (/ (i,i=1,100) /) CALL es(array) PRINT *,array CONTAINS ELEMENTAL SUBROUTINE es(x) INTEGER,INTENT(INOUT) :: x REAL work(x) ... END SUBROUTINE END PROGRAM There does not seem to be any technical reason for the prohibition of example2. A more problematic case arises for an elemental function whose result variable has a length type parameter that depends on a deferred length parameter of a dummy argument. This can occur both for intrinsic type CHARACTER and for parameterized derived types. Consider: PROGRAM example3 TYPE t1(n) INTEGER,LEN :: n INTEGER istring(n) END TYPE TYPE t2 CHARACTER(:),ALLOCATABLE :: string END TYPE PRINT *,f( [ t2('short'),t2('this is much longer') ] ) CONTAINS ELEMENTAL FUNCTION f(x) TYPE(t2),INTENT(IN) :: x TYPE(t1(x%string%len)) f INTEGER j f%istring = [ (ICHAR(x%string(j:j),j=1,f%n)) ] END FUNCTION END The invocation of F in the PRINT statement will return an array whose elements have different length type parameters, something that is supposed to be impossible. Is this restriction still correct and useful? That is, (a) was example1 intended to be standard-conforming, (b) should example2 be standard-conforming, (c) was example3 intended to be standard-conforming. ANSWER: Although there is no technical (implementation) reason for prohibiting example2 while allowing example1, doing so is not a defect in the standard. However, allowing elemental functions to produce arrays whose elements have different length type parameters would be a defect. Thus, example1 is standard-conforming as argued; example2 is not conforming, because it violates constraint C1279; example3 was intended to be prohibited: an edit is supplied to fix this defect in the standard. EDIT: In 12.7.1, constraint C1278, [287:17] After "scalar" change "and" to a comma. [288:1] At the end of the sentence insert ", and shall not have a type parameter that is defined by an expression that is not an initialization expression". SUBMITTED BY: Malcolm Cohen HISTORY: 08-258 m185 F03/0119 submitted 08-299r1 m186 Revised answer, passed by J3 meeting 09-103 m187 Revised, passed by J3 meeting + F2008 fix 09-187 m188 Passed J3 letter ballot 09-155 as modified N1816 m191 Passed by WG5 ballot #7 {N1805/6} 10-006T5 m192 N1805 interps for F2003 Corr 5 == N1815 ---------------------------------------------------------------------- NUMBER: F03/0122 TITLE: When do objects of sequence derived type have the same type? KEYWORDS: SEQUENCE type DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot QUESTION: Consider the following program: MODULE MOD TYPE, PRIVATE :: T SEQUENCE INTEGER :: I END TYPE TYPE(T) :: X, Y CONTAINS SUBROUTINE S X = Y END SUBROUTINE S END PROGRAM MAIN USE MOD CALL S X = Y END The first sentence of subclause 4.5.1.3 of the 2003 Fortran standard says the program conforms because the objects X and Y have the same type, because they are declared by reference to the same type definition. The last sentence of that subclause says they do not have the same type because the type definition is declared to be PRIVATE. Does the program conform to the 2003 Fortran standard? If not, which assignment statement causes the program not to conform? ANSWER: The program conforms to the 2003 Fortran standard. ANALYSIS: The determination that an object cannot have the same type as another one that is declared by reference to a type that is declared to be PRIVATE cannot possibly refer to an object declared in a scope where the type is not accessible. Therefore the objects must be declared in scopes where the type is accessible. It is irrelevant whether the type is "declared to be PRIVATE" in that scope, because accessibility attributes determine whether a name is accessible in a different scope. It would be absurd if the assignment statement in the module subprogram were not standard conforming. Given that it must be standard conforming, it would be absurd if the assignment statement in the main program were not standard conforming. Edits are provided to clarify this conclusion. EDITS: In subclause 4.5.1.3 [47:11], remove "declared to be PRIVATE or" from the last sentence. SUBMITTED BY: Van Snyder HISTORY: 08-270 m185 F03/0122 submitted 08-270r1 m185 Passed by J3 meeting 09-187r2 m188 Passed J3 letter ballot 09-155 - F2008 edit passed at m188 N1816 m191 Passed by WG5 ballot #7 {N1805/6} 10-006T5 m192 N1805 interps for F2003 Corr 5 == N1815 --------------------------------------------------------------------- NUMBER: F03/0125 TITLE: Definitions of EXTENDS_TYPE_OF and SAME_TYPE_AS KEYWORDS: EXTENDS_TYPE_OF SAME_TYPE_AS DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot QUESTION: The arguments of EXTENDS_TYPE_OF and SAME_TYPE_AS are required to be of extensible type. Does this restriction apply to the declared type, the dynamic type, or both? ANSWER: This restriction was intended to apply to the dynamic type; this is clear from the existing text. However, the restriction is stronger than required or useful, and so an edit is supplied to weaken it. DISCUSSION: For EXTENDS_TYPE_OF, this is clear from the Result Value paragraph which explicitly specifies the result when either the A or MOLD argument to the intrinsic is unlimited polymorphic. For SAME_TYPE_AS, this is clear from Note 13.17 which explains how to work out the result when one or both arguments is a disassociated pointer (or unallocated allocatable), including that of an unlimited polymorphic entity. However, in the case of unlimited polymorphic, it is unreasonable to require the program to somehow know that the dynamic type is extensible; these functions should return the right result whenever either argument is of extensible type, and otherwise it should be processor dependent, i.e. the restriction should be weakened. EDITS: [316:16-17] In 13.7.38, EXTENDS_TYPE_OF, arguments A and MOLD, after "of extensible" change "type" to "declared type or unlimited polymorphic", twice. [316:21] After the last "otherwise" insert "if the dynamic type of A or MOLD is extensible,". [316:22] At the end of the sentence insert "; otherwise the result is processor dependent". [347:30,348:1] In 13.7.101, SAME_TYPE_AS, arguments A and B, after "of extensible" change "type" to "declared type or unlimited polymorphic", twice. [348:3] Change "The" to "If the dynamic type of A or B is extensible, the" [348:4] Append new sentence to paragraph "If neither A nor B have extensible dynamic type, the result is processor dependent." SUBMITTED BY: John Reid HISTORY: 08-281 m186 F03/0125 submitted 08-281r2 m186 Passed by J3 meeting + F2008 fix 09-187r2 m188 Passed by J3 letter ballot #18 09-155 N1816 m191 Passed by WG5 ballot #7 {N1805/6} 10-006T5 m192 N1805 interps for F2003 Corr 5 == N1815 ---------------------------------------------------------------------- NUMBER: F03/0126 TITLE: References to VOLATILE variables in pure procedures KEYWORDS: VOLATILE, PURE DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot QUESTION: Was it intended to allow a VOLATILE variable to be referenced in a pure procedure? ANSWER: No. It was intended that the result of invoking a pure function in a FORALL assignment statement should never depend on the order in which the invocations are executed, see NOTE 12.44. The value of a variable with the VOLATILE attribute might change between invocations of the function in ways incompatible with this design. EDIT: [286:22+] In 12.6, Pure procedures, add a new constraint: "C1271a The of a variable with the VOLATILE attribute shall not appear in a pure subprogram." SUBMITTED BY: John Reid and Bill Long HISTORY: 08-284 m186 F03/0126 submitted in response to N1745 by Nick Maclaren noting the problem 08-284r1 m186 Passed by J3 meeting {F2008 fixed in 12.7 "Pure procedures" 09-007 [317:14] C1281} 09-187r2 m188 Passed J3 letter ballot #18 09-155 N1816 m191 Passed by WG5 ballot #7 {N1805/6} 10-006T5 m192 N1805 interps for F2003 Corr 5 == N1815 ---------------------------------------------------------------------- NUMBER: F03/0127 TITLE: Duration of procedure execution KEYWORDS: argument association, procedure DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot QUESTION: In the following questions, the following type definition and procedure are assumed: TYPE T INTEGER :: C = 17 END TYPE SUBROUTINE S(A,B) TYPE(T),INTENT(IN) :: A TYPE(T),INTENT(OUT) :: B ... END (1) Consider TYPE(T) X X%C = 3 CALL S(X,X) Q1. Is this valid, and if so, is A%C equal to 3 or 17? Discussion: B is default-initialized "on invocation", and A is not permitted to be changed "during execution", so this depends on whether "during execution" was intended to include the process of invocation. (2) Consider TYPE(T) X X%C = 3 CALL S(F(),X) where F is the internal function TYPE(T) FUNCTION F() F = X END FUNCTION Q2. Is this valid? If so, what is the value of B%C (3 or 17)? Discussion: The reference to procedure F is not permitted to "affect or be affected by the evaluation of any other entity within the statement" (7.1.8 paragraph 3). However, X is not being affected by "evaluation" (it is not being evaluated by becoming argument- associated with dummy argument A). A becomes defined "on invocation" of S and it is not clear whether that precedes argument evaluation or not. (3) Consider SUBROUTINE V(AA,BB) TYPE(T),VALUE :: AA TYPE(T),INTENT(OUT) :: BB ... END TYPE(T) X X%C = 3 CALL V(X,X) Q3. Is this valid? If so, what is the value of AA%C (3 or 17)? Discussion: AA gets its value by argument association, so happens at the same time as the definition of BB (which defines the actual argument). It is not clear what the semantics are here. Q4. It is similarly unclear as to what is or is not permitted during invocation of a procedure when an actual argument might be modified by some other activity, for example if it has the VOLATILE or ASYNCHRONOUS attribute. ANSWER: The standard does not unambiguously supply an interpretation of these, and therefore they are invalid by subclause 1.5, first sentence. Edits are supplied to clarify this. EDITS: [81:15] 5.1.2.7, paragraph beginning "The INTENT(IN)", change "during the execution" to "during the invocation and execution". {Makes example 1 clearly invalid, and makes it clear that INTENT(IN) variables are unchanged from the start of invocation.} [81:26] Append to the INTENT(OUT) paragraph "Any undefinition or definition implied by association of an actual argument with an INTENT(OUT) dummy argument shall not affect any other entity within the statement that invokes the procedure." {Makes examples 2 and 3 clearly invalid.} [275:2,5] Change "during the execution" To "during the invocation and execution", Twice. {Makes it clear that the anti-aliasing rules apply for the whole process of procedure invocation and execution, not just the execution part.} SUBMITTED BY: Malcolm Cohen HISTORY: 08-298r1 m186 F03/0127 submitted 08-298r2 m186 Passed by J3 meeting + F2008 edit 09-187r2 m188 Passed J3 letter ballot #18 09-155 N1816 m191 Passed by WG5 ballot #7 {N1805/6} 10-006T5 m192 N1805 interps for F2003 Corr 5 == N1815 ---------------------------------------------------------------------- NUMBER: F03/0129 TITLE: C_LOC of character substrings KEYWORDS: interoperability DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot QUESTION: Consider SUBROUTINE S(A,I,K) USE ISO_C_BINDING CHARACTER(*),TARGET :: A CHARACTER(:),ALLOCATABLE,TARGET :: B TYPE(C_PTR) P1,P2,P3,P4,P5 P1 = C_LOC(A(1:1)) ! *1 P2 = C_LOC(A(I:I)) ! *2 P3 = C_LOC(A(1:)) ! *3 P4 = C_LOC(A(I:K)) ! *4 ALLOCATE(CHARACTER(1)::B) P5 = C_LOC(B) ! *5 END SUBROUTINE C_LOC (case 1) requires of its argument that it have interoperable type and type parameters (15.1.2.5, p395). Case 2 does not apply because character type has a length type parameter. 15.2.1 states "if the type is character, interoperability also requires that the length type parameter be omitted or be specified by an initialization expression whose value is one". However, a substring does not have a declared type parameter that can be omitted or specified by an initialization expression. Even in the reference marked *1, it is the substring starting and ending positions that are specified by initialization expressions, not the substring length. In any case, if *1 satisfied the quoted requirement then *3 also has its starting and ending positions specified by by initializations "or omitted". In case *2, it must be totally obvious that the length has to be 1 since the expressions are lexically identical with no user function references, but neither are initialization expressions. If I==K, it would be reasonable to expect *4 to be interoperable but it certainly does not satisfy the stated requirements. Or, another interpretation would be that for substrings the length type parameter is by definition "omitted" since they have no syntax for its specification: in which case the question would arise as to what happens for zero-length substrings. It seems that the authors of the requirement forgot that "variables" include "substrings". Finally, case *5 is totally ambiguous because B has multiple length specifications, one which does not satisfy the requirement (the declaration) and one which does (the ALLOCATE statement). ANSWER: C_LOC should only require nonzero length, which corresponds to the requirement we make for arrays. Furthermore, the description of interoperability of intrinsic types is confusing for type CHARACTER. Edits are provided to fix the defects. EDITS: [395:8(15.1.2.5)] In the <> paragraph, Before "type parameters" insert "kind". [395:16+] Insert new sentence after list: "X shall not be a zero-length string." [396:5-7] Replace "; if ... one." with ". If the type is character, the length type parameter is interoperable if and only if its value is one." {Reword so that the type/kind can be interoperable even if the length is not.} [399:2-3(15.2.4p1)] Before "scalar" insert "named", {I think this is supposed to be talking about named variables only, not about subobjects.} Change "if" to "if and only if" {Seems to be broken...} Change the second "and" to a comma, At the end of the sentence insert ", and if it is of type character its length is not assumed or declared by an expression that is not an initialization expression". {It seems more straightforward to forbid the invalid than to require the valid.} [399:7-8(15.2.5)] Change "An array Fortran variable" to "A Fortran variable that is a named array", Change "if" to "if and only if", Change the second "and" to a comma, At the end of the sentence insert ", and if it is of type character its length is not assumed or declared by an expression that is not an initialization expression". SUBMITTED BY: Malcolm Cohen HISTORY: 09-121r1 m187 F03/0129 submitted 09-121r1 m187 Passed by J3 meeting + F2008 fix 09-187r2 m188 Passed J3 letter ballot 09-155 as modified N1816 m191 Passed by WG5 ballot #7 {N1805/6} 10-006T5 m192 N1805 interps for F2003 Corr 5 == N1815 ---------------------------------------------------------------------- NUMBER: F03-0130 TITLE: Elemental specific intrinsic procedure characteristics KEYWORDS: Elemental intrinsic, procedure pointer, dummy procedure DEFECT TYPE: Interpretation STATUS: Passed by WG5 ballot QUESTION: (1) Are the specific intrinsic procedures (listed in 13.6 and not marked with a bullet) elemental or nonelemental? (2) What rank do those specific intrinsic procedures have? (3) May one of those procedures become associated with a dummy procedure or procedure pointer with nonzero rank? (4) When one of these procedures is associated with a dummy procedure or procedure pointer, does it still have the elemental property? ANSWER: (1) Those specific intrinsic procedures are elemental. (2) They are elemental functions; thus they are scalar in themselves, but may be applied to an array in which case the reference will be an array. (3) No. As elemental procedures, by definition the dummy arguments and result have rank zero. This does not satisfy the requirements for procedure argument or procedure pointer association. (4) The specific intrinsic procedure itself retains the elemental property (so a reference using its own name can be elemental), but the dummy procedure or procedure pointer associated with it is not elemental and so cannot be used to reference the specific intrinsic procedure elementally. EDIT: None. SUBMITTED BY: Van Snyder HISTORY: 09-171r1 m188 F03/0130 submitted 09-217 m188 Revised question/answer - passed by J3 meeting 09-295 m190 Passed by J3 letter ballot #19 09-292 N1816 m191 Passed by WG5 ballot #7 {N1805/6} 10-006T5 m192 N1805 interps for F2003 Corr 5 == N1815 ---------------------------------------------------------------------- NUMBER: F03/0131 TITLE: SAVE attribute and EQUIVALENCE KEYWORDS: SAVE, EQUIVALENCE DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot QUESTION: If one object in an EQUIVALENCE set has the SAVE attribute, do all the other objects in the EQUIVALENCE set implicitly have the SAVE attribute? This can be detected by the program: SUBROUTINE s1 TYPE T SEQUENCE REAL :: C = 3.0 END TYPE TYPE(t) x,y SAVE x EQUIVALENCE(x,y) x = t(1.0) RETURN ENTRY s2 PRINT *,y ! Does this print 1.0 or 3.0? END PROGRAM show CALL s1 CALL s2 END If Y has the SAVE attribute the program will print 1.0; if not, it will print 3.0 due to the default initialization. ANSWER: Yes, the SAVE attribute propagates through EQUIVALENCE. An edit is supplied to clarify this. EDIT: [97:7+] Insert new paragraph "If any data object in an has the SAVE attribute, all other objects in the have the SAVE attribute; this may be confirmed by explicit specification." SUBMITTED BY: Malcolm Cohen HISTORY: 09-194 m188 F03/0131 submitted 09-194r1 m188 Passed by J3 meeting 09-295 m190 Passed by J3 letter ballot #19 09-292 N1816 m191 Passed by WG5 ballot #7 {N1805/6} - edit is in F2008 10-006T5 m192 N1805 interps for F2003 Corr 5 == N1815 ---------------------------------------------------------------------- NUMBER: F03/0132 TITLE: Unformatted i/o and private components KEYWORDS: UNFORMATTED, INPUT/OUTPUT, PRIVATE DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot QUESTION: Consider Module M Type T Private Real :: UDATA(100) End Type End Module ... Type(T) X ... Write (10,*) X ! Formatted Write Write (20) X ! Unformatted Write Both of the WRITE statements were not valid Fortran 95. Are either of them valid Fortran 2003? According to [193:9-12], the formatted WRITE statement is not valid. But the corresponding paragraph for unformatted WRITEs, at [193:1-5], only forbids private components when some component of T would itself be handled by user-defined derived-type input/output. That does not seem to be consistent. DISCUSSION: The "shall not be pointers or allocatables" part of the [193-:1-5] paragraph is repeated later, at [193:13-15]. This makes no mention of accessibility. ANSWER: Both cases were intended to be invalid. An edit is supplied to repair the requirements for unformatted i/o. EDIT: [193:13-15] Replace paragraph "If a derived-type list item is not processed by a user-defined derived-type input/output procedure and is not treated as a list of its individual components, all the subcomponents of that list item shall be accessible in the scoping unit containing the input/output statement and shall not be pointers or allocatable". SUBMITTED BY: Malcolm Cohen HISTORY: 09-195 m188 F03/0132 submitted - passed by J3 meeting 09-295 m190 Passed by J3 letter ballot #19 09-292 N1816 m191 Passed by WG5 ballot #7 {N1805/6} - edit is in F2008 10-006T5 m192 N1805 interps for F2003 Corr 5 == N1815 ---------------------------------------------------------------------- NUMBER: F03/0133 TITLE: Is unlimited polymorphic allowed in COMMON? KEYWORDS: Unlimited polymorphic, CLASS(*), COMMON DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot QUESTION: For a pointer to a derived type to be storable in COMMON, it must be of sequence type. However, there does not seem to be any prohibition against a CLASS(*) pointer in COMMON. Is this allowed? ANSWER: This was inadvertently allowed in the Fortran 2003 standard as published. An edit is supplied to correct this error. EDIT: [98:22] After "BIND attribute," insert "an unlimited polymorphic pointer," SUBMITTED BY: Malcolm Cohen HISTORY: 09-204 m188 F03/0133 submitted - passed by J3 meeting 09-295 m190 Passed by J3 letter ballot #19 09-292 N1816 m191 Passed by WG5 ballot #7 {N1805/6} - edit is in F2008 10-006T5 m192 N1805 interps for F2003 Corr 5 == N1815 ---------------------------------------------------------------------- NUMBER: F03/0134 TITLE: Implicit typing of procedure pointers KEYWORDS: procedure pointer, implicit type DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot QUESTION: Q1. Are procedure pointer components implicitly typed? That is, considering PROGRAM implicitppc EXTERNAL proc TYPE t PROCEDURE(),POINTER,NOPASS :: ptr END TYPE t TYPE(t) :: i i%ptr => proc PRINT *,i%ptr() END PROGRAM is this program standard-conforming and if so, what is the type of the procedure pointer component PTR? In J3/04-007 one finds (p. 93, ll. 8-11) 5.3 "Any data entity that is not explicitly declared by a type declaration statement, is not an intrinsic function, and is not made accessible by use association or host association is declared implicitly to be of the type (and type parameters) mapped from the first letter of its name, provided the mapping is not null." Q2. Are ambiguous procedure pointers allowed? That is, considering SUBROUTINE ppOne(do_the_subroutine) LOGICAL :: do_the_subroutine EXTERNAL some_subroutine, some_function PROCEDURE(), POINTER :: proc_pointer IF (do_the_subroutine) THEN proc_pointer => some_subroutine CALL proc_pointer(5) ELSE proc_pointer => some_function y = proc_pointer(7) END IF END SUBROUTINE (a) Does the subroutine ppOne conform to the Fortran standard? (b) If yes, does a subroutine with the "if"/"else"/"end if" lines removed conforms to the standard? In J3/04-007 one finds (p. 145, ll. 2-4) 7.4.2.2 "If proc-pointer-object has an implicit interface and is explicitly typed or referenced as a function, proc-target shall be a function. If proc-pointer-object has an implicit interface and is referenced as a subroutine, proc-target shall be a subroutine." Q3. If ambiguously-typed procedure pointers are allowed, are they still allowed with IMPLICIT NONE? That is, considering IMPLICIT NONE ! p is not implicitly typeable REAL, EXTERNAL :: func PROCEDURE(), POINTER :: p1 PROCEDURE(REAL),POINTER :: p2 REAL y p1 => func ! A p2 => p1 ! B y = p2() END PROGRAM are the procedure pointer assignments A and B standard-conforming? In J3/04-007 one finds (p.146, ll. 36-38; p. 145, ll. 2-6) 7.4.2.2 Procedure pointer assignment "If the proc-target is not a pointer, proc-pointer-object becomes pointer associated with proc-target. Otherwise, the pointer association status of proc-pointer-object becomes that of proc-target; if proc-target is associated with a procedure, proc-pointer-object becomes associated with the same procedure. [...] If proc-pointer-object has an implicit interface and is explicitly typed or referenced as a function, proc-target shall be a function. If proc-pointer-object has an implicit interface and is referenced as a subroutine, proc-target shall be a subroutine. If proc-target and proc-pointer-object are functions, they shall have the same type; corresponding type parameters shall either both be deferred or both have the same value." ANSWER: (1) No, procedure pointer components are never implicitly typed. The quoted text from the standard does not apply to components; if it did apply to components, data components would also be implicitly typed and that would be a contradiction. A clarifying edit is provided. (2) Yes, ambiguous procedure pointers are allowed. However, a procedure pointer is only ambiguous if it is neither referenced as a subroutine nor as a function. Therefore, as the quoted text from the standard indicates, the example is not conforming. (3) No, a procedure pointer with no type can only be ambiguous if there is a valid implicit type mapping for the initial letter of its name. Therefore, with IMPLICIT NONE, PROCEDURE() declares a subroutine with an implicit interface, the same as EXTERNAL. EDITS: [93:9] After "function," insert "is not a component,". {Components are never implicitly typed.} SUBMITTED BY: Tobias Burnus HISTORY: 09-236 m189 F03/0134 submitted 09-236r1 m189 Passed by J3 meeting 09-295 m190 Passed by J3 letter ballot #19 09-292 N1816 m191 Passed by WG5 ballot #7 {N1805/6} - F2008 edit in 10-131 passed at m191 10-006T5 m192 N1805 interps for F2003 Corr 5 == N1815 ---------------------------------------------------------------------- NUMBER: F03/0135 TITLE: Interaction between RESULT, recursion, and host generic KEYWORDS: RESULT, generic, recursion DEFECT TYPE: Interpretation STATUS: Passed by WG5 ballot QUESTION: Consider MODULE example INTERFACE f MODULE PROCEDURE f0,f END INTERFACE CONTAINS INTEGER FUNCTION f0(n) RESULT(y) y = n + 1 END FUNCTION INTEGER FUNCTION f(n1,n2) RESULT(y2) y2 = f(n1+n2) END FUNCTION END MODULE Q1. Does the reference to F in the assignment to Y2 refer to the generic F (and is thus a valid reference to F0) or to the specific F (and is thus an invalid recursive reference to itself with the wrong number of arguments)? Section 12.5.2.1 (Function subprogram, at lines 31-33 on page 296) states: "If RESULT is specified, [...] all occurrences of the function name in execution-part statements in the scoping unit refer to the function itself." That would appear to indicate that it is a reference to the specific F itself, and thus invalid. How should the rules in 12.4.4 for resolving named procedure references be applied to this? In particular, for the reference to F from within F, Q2. Is F established to be generic by rule (1)(d)? If so, that should mean that the reference to F within itself is a valid reference to the generic F (then resolved to F0). Q3. Is F established to be specific by rule (2)(e)? Even if F is not established to be generic, if it is established to be specific then the subsequent rule (6) in 12.4.4.2 means the reference is valid, being resolved via host association to the generic F (then resolved to F0). Q4. If F is not established, then rule (3) in 12.4.4.3 indicates the reference would be to the external procedure F. That does not seem to make sense. Consider the case where F instead looks like this: RECURSIVE INTEGER FUNCTION f(n1,n2) RESULT(y2) IF (n1>1 .AND. n2>1) THEN y2 = f(n1-1,n2-1) ELSE y2 = MAX(n1,n2) END IF END FUNCTION This would appear to be a valid subprogram using the interpretation in 12.5.2.1 (that F is a reference to itself), but if F is not established then it would not be valid. Q5. Is this example conforming? ANSWER: (1) The analysis is correct, the use of F within the function F is, as stated, a reference to F itself (and thus the example is invalid). (2) F is not established to be generic: it contains a declaration of F (the FUNCTION statement itself) so the generic in the host in the rule (1)(d) does not apply. (3) According to the rules as they are now, F is not established to be specific: rule (2)(e) is inapplicable because the FUNCTION statement is a declaration of F. This is an error in the standard. (4) You are correct, that would not make sense. This is an error in the standard. (5) You are correct, these rules are contradictory. The intent was that this example should be conforming. Edits are supplied to correct the rules in 12.4.4 to account for recursive self-references to functions with RESULT clauses. The function F should be established to be specific, and the reference should be to itself. EDITS: [276:36+] Insert new case "(a2) if that scoping unit is of a subprogram that defines a procedure with that name;" {Establish the name to be (only) specific.} [278:15+] Insert new case "(3a) If the scoping unit is of a subprogram that defines a procedure with that name, the reference is to that procedure." {Resolve to the procedure.} SUBMITTED BY: Tobias Burnus HISTORY: 09-237 m189 F03/0135 submitted 09-237r1 m189 Passed by J3 meeting 09-295 m190 Passed by J3 letter ballot #19 09-292 N1816 m191 Passed as amended by WG5 ballot #7 {N1805/6} - F2008 edit in 10-132r1 passed at m191 10-006T5 m192 N1805 interps for F2003 Corr 5 == N1815 ---------------------------------------------------------------------- NUMBER: F03/0136 TITLE: Are subroutines distinguishable from arrays? KEYWORDS: Generic resolution, subroutine, array DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot QUESTION: Can a subroutine be used as a disambiguator in a generic reference? A subroutine cannot reliably be distinguished from a scalar function because of implicit typing. However, it can always be distinguished from an array function, because an array function needs to have an explicit interface that provides its rank (and type, but rank is the important consideration for this question). For generic resolution, the Fortran 95 standard allowed a dummy argument to be a "disambiguator" if it had a different data type, kind type parameter, or rank (14.1.2.3, page 277). There is no clear definition of what the rank of a subroutine is, but many have assumed that the rank of a subroutine is zero; thus allowing "subroutine vs. array" to be used to disambiguate generic references. However, this text was changed in Fortran 2003 to forbid a subroutine from ever being used as a disambiguator (16.2.3, page 407). Here is an example: Module example Interface gen Module Procedure invoke,aprint End Interface Contains Subroutine invoke(s) External s Call s ! We know this is a subroutine. End Subroutine Subroutine aprint(a) Real a(:) Print *,'[',a,']' End Subroutine End Module It is clear that if the Call s statement were changed to Print *,s() then the module would be standard-conforming. It seems inconsistent to allow scalar functions to disambiguate with arrays but to disallow subroutines from disambiguating with arrays. DISCUSSION: In Fortran 2008, procedureness is a potential disambiguator which would make the above simple example conforming, but there is still a problem with Module example Interface gen Module Procedure invoke,aprint End Interface Contains Subroutine invoke(s,n) External s Call s(n) ! We know this is a subroutine. End Subroutine Subroutine aprint(af,n) Interface Function af(n) Real af(n) End Function End Interface Print *,'[',af(n),']' End Subroutine End Module Again, changing "Call s(n)" to "Print *,s(n)" would make the example conform to the standard as written. ANSWER: This inconsistency was inadvertant. Edits are supplied to correct this oversight. EDITS: [407:28] After "distinguishable if" insert "one is a subroutine and the other is an array, or if". SUBMITTED BY: Malcolm Cohen. HISTORY: 09-264 m189 F03/0136 submitted - Passed by J3 meeting 09-295 m190 Passed as amended by J3 letter ballot #19 09-292 N1816 m191 Passed by WG5 ballot #7 {N1805/6} - F2008 edit in 10-136 passed at m191 10-006T5 m192 N1805 interps for F2003 Corr 5 == N1815 ---------------------------------------------------------------------- NUMBER: F03/0137 TITLE: Dummy procedure type compatibility KEYWORDS: Dummy function, implicit interface DEFECT TYPE: Interpretation STATUS: Passed by WG5 ballot QUESTION: Consider PROGRAM EXAMPLE REAL,EXTERNAL :: F CALL S(F) END SUBROUTINE S(A) INTEGER,EXTERNAL :: A PRINT *,A() END SUBROUTINE REAL FUNCTION F() F = HUGE(0.0) END FUNCTION Subclause 12.4.1.3 (pages 271-272) appear to require that the actual argument corresponding to a procedure dummy argument must be a function if the dummy procedure is referenced as a function, but there seems to be no visible requirement for it to have the same type and type parameters. That would seem to make the above program standard conforming. Is there intended to be such a requirement? ANSWER: Yes, there should be such a requirement. An edit is supplied to correct this oversight. EDIT: [271:28] Append new sentences to the end of paragraph 5 of 12.4.1.3 "If both the actual argument and dummy argument are known to be functions, they shall have the same type and type parameters. If only the dummy argument is known to be a function, the function that would be invoked by a reference to the dummy argument shall have the same type and type parameters, \obs{except that an external function with assumed character length may be associated with a dummy argument with explicit character length}.". {The second sentence is there to catch an argument association chain, and this case needs to allow the obsolescent assumed-length character function. In the case in the first sentence, the actual argument already is prevented from having assumed length by our other rules.} SUBMITTED BY: Malcolm Cohen HISTORY: 09-267 m189 F03/0137 submitted - Passed by J3 meeting 09-295 m190 Passed by J3 letter ballot #19 09-292 N1816 m191 Passed by WG5 ballot #7 {N1805/6} F2008 edit in 10-133 passed at m191 10-006T5 m192 N1805 interps for F2003 Corr 5 == N1815 ---------------------------------------------------------------------- NUMBER: F03/0138 TITLE: External as KEYWORDS: procedure name, procedure pointer, procedure pointer assignmant DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot QUESTION: 7.4.2 C727 says a " [that is a ] shall be the name of an external ... procedure...." To be passed as an actual argument, a procedure needs to have the EXTERNAL attribute, but there appears to be no such requirement for being a target in a procedure pointer assignment. (1) Is the following example standard-conforming? PROGRAM example1 PROCEDURE(),POINTER :: p PROCEDURE(REAL),POINTER :: q p => x CALL x q => y PRINT *,y(5) CALL p PRINT *,q(5) END SUBROUTINE x PRINT *,'ok so far' END FUNCTION y(n) y = SQRT(REAL(n)) END (2) If example1 is standard-conforming, is this example conforming? MODULE exmod PROCEDURE(),POINTER :: p CONTAINS SUBROUTINE test CALL p END SUBROUTINE END PROGRAM example2 USE exmod p => x CALL test END SUBROUTINE x PRINT *,'ok' END ANSWER: (1) Yes, this example is conforming. As correctly noted, there is no requirement for the EXTERNAL attribute in a procedure pointer assignment, and both X and Y are known within the main program to be external procedures. (2) This example was not intended to be conforming. An edit is provided to clarify this. EDIT: [144:5-6] In 7.4.2 Pointer assignment, constraint C727, Change "an external, module," to "a module", Change "or a procedure pointer" to "a procedure pointer, or an external procedure that is accessed by use or host association and is referenced in the scoping unit as a procedure, or that has the EXTERNAL attribute". This makes the revised constraint "C727 (R742) A shall be the name of a module or dummy procedure, a specific intrinsic function listed in 13.6 and not marked with a bullet ($\bullet$), a procedure pointer, or an external procedure that is accessed by use or host association and is referenced in the scoping unit as a procedure, or that has the EXTERNAL attribute." SUBMITTED BY: Van Snyder HISTORY: 09-281 m189 F03/0138 submitted - Passed by J3 meeting 09-295 m190 Passed by J3 letter ballot #19 09-292 N1816 m191 Passed as amended by WG5 ballot #7 {N1805/6} - F2008 edit in 10-134r1 passed at m191 10-006T5 m192 N1805 interps for F2003 Corr 5 == N1815 ---------------------------------------------------------------------- NUMBER: F03/0140 TITLE: Type of nested construct entities. KEYWORDS: ASSOCIATE, DATA, FORALL, SELECT TYPE DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot QUESTION: Consider the example: PROGRAM bad REAL x INTEGER i,y(10) ASSOCIATE (x=>i) ! B DATA (y(x),x=1,10)/10*1/ ! A DO x=1,10 ! B y(x) = SQRT(y(x)) ! B END DO ! B FORALL(x=1:10) y(x) = y(x)**2 ! C END ASSOCIATE ! B x = SUM(y) END PROGRAM Is this program conforming? That is: Within the ASSOCIATE construct, is X of type INTEGER? It certainly is in the statements marked with "! B". But according to 16.3 paragraph 2 [409:18-20], in the statement marked "! A", X has the type it has in the scoping unit, which would have to be REAL. And according to 16.3 paragraph 3 [409:25-27], in the statement marked "! C", X has the type it has in the scoping unit, which would have to be REAL. If X is type REAL for DATA and FORALL, the program would not be conforming, but it would be if X were of type INTEGER. ANSWER: Within the scope of a construct entity name, it was intended that a data-implied-do index or a FORALL index name should have the type and type parameters of the construct entity name. Edits are provided to clarify this. EDITS: [409:19] 16.3 Statement and construct entities, para 2, sentence 2, Before "scoping unit" insert "innermost executable construct or". {Makes a difference for DATA in ASSOCIATE and SELECT TYPE only.} [409:26] 16.3, paragraph 3, sentence 2, Before "scoping unit" insert "innermost executable construct or". {Makes a difference for FORALL in ASSOCIATE and SELECT TYPE only.} SUBMITTED BY: Malcolm Cohen HISTORY: 09-301 m190 F03/0140 submitted - Passed by J3 meeting 10-105 m191 Passed by J3 letter ballot #20 09-307 N1816 m191 Passed by WG5 ballot #7 {N1805/6} - F2008 edit in 10-136 passed at m191 10-006T5 m192 N1805 interps for F2003 Corr 5 == N1815 ---------------------------------------------------------------------- NUMBER: F03/0141 TITLE: More than one specific interface for a procedure KEYWORDS: Specific interface DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot QUESTION: Consider the example: module A contains subroutine S ( X ) real :: X end subroutine S end module A module B use A, only: T => S end module B module C use A, only: U => S end module C program P use B ! Access the procedure name T use C ! Access the procedure name U ! T and U are different names for the same procedure. end program P Is this program conforming? The procedure S defined in the module A has two explicit specific interfaces in program P. The sixth paragraph after constraint C1211 in subclause 12.3.2.1 says "A procedure shall not have more than one explicit specific interface in a given scoping unit." ANSWER: It was intended that this program be conforming. An edit is provided to correct this. EDITS: [260:2] After "scoping unit" insert ", except that if the interface is accessed by use association, there may be more than one local name for the procedure". {Yes, here we really do want "may", because we are giving permission.} Append a sentence at the end of the paragraph: "If a procedure is accessed by use association, each access shall be to the same procedure declaration or definition." SUBMITTED BY: Van Snyder HISTORY: 09-304 m190 F03/0141 submitted - Passed by J3 meeting 10-105 m191 Passed by J3 letter ballot #20 09-307 N1816 m191 Passed as amended by WG5 ballot #7 {N1805/6} - F2008 edit in 10-137r1 passed at m191 10-006T5 m192 N1805 interps for F2003 Corr 5 == N1815 ----------------------------------------------------------------------