J3/04-006Ar1 Outstanding Fortran Interpretations, April 29, 2005 Stan Whitlock for /interp > includes the results of J3 letter ballot #10 05-101/146 of Dec-2004 > includes the results of WG5 ballot N1612/1617 of Nov-2004 > includes the results of J3 letter ballot #11 05-167/170 of Mar-2005 > does not include the results of WG5 ballot N1622 of Apr-2005 [keep this text document to 70 characters per line] Table of Contents Part 0 contains the summary status of all of the Fortran interpretations Part 1 contains the interpretation processing rules from 00-142 Part 2 contains F95 interpretation 000000e (typographical interps), interpretations 1-32 and 66-103 Part 3 contains the remaining F90 interpretations left over, with their F90 interp numbers (prefixed with "F90/") Exceptions: 000200 was already subsumed by 000202 and so does not appear. 000202 was replaced by F95/000012 at meeting 143. Note: F90/000202 history added to F95/000012 history. Note: Additionally to those noted in 00-126, F90 interps 000206-000212 are included All of these are being interpreted against F95. Part 4 contains the Japanese interpretations with their Japanese numbers (JP-4 etc.). These are F95 interpretations. Part 5 contains F2003 interpretations 0001-0055 (prefixed with "F03") ---------------------------------------------------------------------- ====================================================================== Part 0: Summary Status of these Fortran Interpretations ====================================================================== 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 corrigendum 1 (see N1422) C2 Included in corrigendum 2 (see N1473) X Excluded for the reasons given S T number title - - ------ ----- P I 000000e Rejected Minor edits and corrections C1 I 000001 Visibility of a data object with statement scope C2 I 000002 Free source form requirement for blank in PRINT statement C1 I 000003 Ability to overload the character operator // W I 000004 Value returned by MAXVAL/MINVAL C1 I 000005 Value returned by SELECTED_REAL_KIND W I 000006 Character length specification of a function result C2 I 000007 Optional intrinsic function arguments W I 000008 Optional arguments to MAX/MIN C2 I 000009 INTENT of MOLD argument to TRANSFER C2 E 000010 Meaning of embedded blanks in namelist input name C2 E 000011 G editing typo C2 E 000012 Evaluation of Intrinsic Procedures X 000013 Format of zero in list-directed and namelist output {removed completely - questions duplicated in 000067 in C2} C2 000014 Format of complex numbers in list-directed and namelist output C2 000015 Commas in list-directed output X 000016 Completely removed - duplicate of 000071 W I 000017 Characteristics of an array function result C2 E 000018 ELEMENTAL procedures with no arguments C2 E 000019 Result of NULL intrinsic associated with CHARACTER(*) dummy argument C2 E 000020 Execution of a WHERE statement within a WHERE construct C2 E 000021 Restrictions on on END INTERFACE C2 E 000022 Use of NULL() as initialization W I 000023 Termination of the previous record by a WRITE statement C2 E 000024 Termination of a partial record by a CLOSE, BACKSPACE, ENDFILE, or REWIND statement C2 E 000025 List-directed input: types of variables corresponding to repeated values C2 I 000026 List-directed input: types of variables corresponding to repeated values C2 C 000027 Sequential formatted I/O: position of the left tab C2 C 000028 Implicitly Typed Statement Function Character Dummy C2 C 000029 Association of a pointer actual argument with a dummy argument W E 000030 Ordering requirements on definition of specification functions X 000031 Association of pointer function result with INTENT(OUT) dummy argument (subsumed by 000074) C2 000032 Is the TRANSFER function result undefined? C2 E 000066 Errors in processing data transfer statements C2 E 000067 Writing zeros W I 000068 Asterisks as I/O units C1 E 000069 What is a numeric character? C1 E 000070 Asymmetry between constant specification and initialization expressions C2 E 000071 Character array constructors C1 E 000072 Resolving generic procedure references C2 000073 Is padding allowed in storage sequences? P I 000074 TARGET dummy arguments and POINTER expressions C2 000075 Defined assignment and INTENT(IN) dummy arguments in PURE procedures C1 E 000076 INTENT(IN) dummy arguments and implied DO loops C1 E 000077 INTENT(IN) dummy arguments and NULLIFY W E 000078 Resolving generic procedure references C1 E 000079 Pointer Assignment and Allocatable Arrays C1 E 000080 Host association and the EXTERNAL attribute C2 E 000081 Definition status of derived-type objects with pointer components C1 E 000082 Usage of BOZ literal constants C1 E 000083 Scope of array-constructor implied-DO variable C1 E 000084 Events that cause variables to be defined C2 E 000085 Public components of private types C2 E 000086 Definition status requirements for defined operations C2 E 000087 MOD and MODULO intrinsic functions with zero divisor C2 E 000088 INTRINSIC statement and attribute C2 C 000089 Rules allowing duplicate names C2 E 000090 What do `Prior Specification' and `defined previously' mean? C2 E 000091 Definition of "present" is defective C2 E 000092 Values of the PAD= Specifier in the INQUIRE Statement C2 E 000093 Allocatable arrays as actual arguments C2 E 000094 NULL intrinsic in initialization expressions C2 E 000095 Names of functions, results and entry points W E 000096 End-of-record and PAD C2 E 000097 Open Scratch File Example P 000098 Are dummy functions returning assumed-length character legal? W E 000099 STAT= variable requirements in ALLOCATE W E 000100 TARGET attribute and structure components W E 000101 Generic resolution P E 000102 mask-expr evaluated only once W E 000103 Derived type name DOUBLEPRECISION W I 000104 Representation method of result of REAL W I F90/000049 Characteristics of function results W E F90/000070 Characteristics specified by interface bodies W I F90/000096 Definition of "Declaration" C1 I F90/000100 ASSOCIATED intrinsic and zero-sized objects W I F90/000140 TARGET attribute for a derived-type object with a pointer component P E F90/000145 Expressions in of a FUNCTION statement C2 C F90/000164 Use of ONLY with multipart definitions C1 I F90/000179 DO variable with POINTER attribute W I F90/000180 Unambiguous generic references C1 I F90/000185 What is the allocation status of an array after an allocation failure? C2 I F90/000190 Subobjects of constants in a DATA statement C2 I F90/000191 Interaction of SEQUENCE derived types and rename C1 I F90/000194 Statements between SELECT CASE and CASE C2 C F90/000196 Inaccessibility of intrinsic procedures C2 F90/000197 Relationship of NEAREST and SPACING C2 E F90/000204 Meaning of "same variable" description of MVBITS C2 E F90/000205 Restrictions on EXTERNAL W I F90/000206 Collating sequence inconsistencies W E F90/000207 Integer bit-model inconsistency W I F90/000208 nonadvancing output followed by list directed output C2 E F90/000209 STOP|PAUSE in I/O statement W I F90/000210 nonadvancing write followed by list directed write C2 E F90/000211 Multiple MODULE PROCEDURE specs C2 C F90/000212 EQUIVALENCE of Data Objects of Different Types or Kinds C2 E JP-04 Construction of derived-type values C2 I JP-05 Construction of array values C2 E JP-06 Type declaration statements C2 E JP-08 Type declaration statements C2 JP-12 Bounds of each dimension of an array pointer C2 E JP-16 Multiple occurrence of namelist-group-name in NAMELIST statement W I JP-17 Multiple occurrence of namelist group object in namelist group W E JP-24 The bnf term shared-term-do-construct C2 E JP-31 Signs of literal constants X JP-39 Withdrawn by submitter W I F03/0001 Generic type-bound procedures W I F03/0002 Component value for pointer components P F03/0003 Referencing deferred bindings P E F03/0004 Type-bound procedures and undefined association status W E F03/0005 Argument association and the TARGET attribute W E F03/0006 Intrinsic assignment and allocatable components W E F03/0007 Finalization of structure constructors in specifications B E F03/0008 Pointer assignment and arrays W E F03/0009 VALUE attribute for passed-object dummy arguments W E F03/0010 Unlimited polymorphic pointer/allocatable dummy arguments W E F03/0011 Allocating objects of abstract types B E F03/0012 Procedure pointers and the EXTERNAL attribute W E F03/0013 VALUE attribute for polymorphic dummy arguments W E F03/0014 Automatic arrays in interface bodies W E F03/0015 TARGET attribute for associate names W E F03/0016 Invoking type-bound procedures via array objects M E F03/0017 Dummy procedure pointers and PRESENT B C F03/0018 Multiple identical specific procedures in type-bound generic interfaces B E F03/0019 Multiple identical specific procedures in generic interface blocks B E F03/0020 Kinds of intrinsic type parameters M E F03/0021 What kind of token is a stop code? M I F03/0022 Coexistence of IEEE and non-IEEE kinds B E F03/0023 IEEE_SET/GET_UNDERFLOW_MODE M I F03/0024 DEALLOCATE and array pointers B E F03/0025 Abstract types in CLASS IS type guard statements B E F03/0026 Intrinsic types in CLASS IS type guard statements B E F03/0027 Assumed character length in type guard statements M E F03/0028 Commas in complex namelist output B E F03/0029 Negative zero and intrinsic functions B E F03/0030 IEEE divide by zero B I F03/0031 IEEE invalid B I F03/0032 Sign bit of IEEE NaN B I F03/0033 IEEE_VALUE() B E F03/0034 IEEE_LOGB() B I F03/0035 IEEE_NEXT_AFTER() B I F03/0036 IEEE_REM() B I F03/0037 IEEE_RINT() B I F03/0038 IEEE_SCALB() B E F03/0039 HYPOT() B I F03/0040 2.0+2.0 and IEEE B I F03/0041 IEEE halting and exceptions P E F03/0042 IEEE funny values and Standard real generic instrinsic procedures B E F03/0043 Passed-object arguments and procedure pointer components B E F03/0044 Implicit interfaces and conflicting references B E F03/0045 Finalization and assumed- arguments with INTENT(OUT) B E F03/0046 Unlimited polymorphic pointers in common blocks B E F03/0047 Polymorphic arguments to intrinsic procedures P I F03/0048 Control edit descriptors in UDDTIO P I F03/0049 Separators in list-directed output involving UDDTIO P I F003/0050 Questions about internal files P I F03/0051 Repeat specifiers and UDDTIO B I F03/0052 ADVANCE= specifier in child data transfer statements B E F03/0053 The BIND attribute for C_PTR and C_FUNPTR B E F03/0054 Denormal inputs to EXPONENT, FRACTION, and SET_EXPONENT B E F03/0055 Denormal inputs to SPACING and RRSPACING ====================================================================== Part 1: Interpretation Processing Rules ====================================================================== 0. All interpretations are listed in J3 standing document 006. 1. Interpretations are processed by the J3/interp group and given a number. The interpretation is marked "J3 consideration in progress". An answer is formulated and presented to J3 in a meeting paper. 2. J3 votes on the answer at a J3 meeting; a simple majority vote marks the answer as "passed by J3 meeting". 3. Between J3 meetings the chair of /interp sends a J3 letter ballot to J3 to approve interp answers that have been "passed by J3 meeting". The letter ballot runs for 30 days. Not voting on three of four consecutive J3 letter ballots is grounds to terminate J3 membership. An interp answer passes by a 2/3rds vote; a no vote must be accompanied by an explanation of the changes necessary to change the member's vote to yes. J3/interp reserves the right to recall an interp answer for more study even if the answer passes. 4. The chair of J3/interp gathers all interp answers that are marked "passed by J3 letter ballot" and forwards them to the WG5 convenor. The WG5 convenor holds a ballot of individual members; a no vote must be accompanied by an explanation of the changes necessary to change the member's vote to yes. The answers that pass this ballot become "WG5 approved". J3/interp reserves the right to recall an interp answer for more study even if the answer passes. 5. "WG5 approved" answers are processed into a corrigendum document by taking the edits from the interp answers and putting them in the format required by ISO. A WG5 vote is made on forwarding the corrigendum to SC22. Interps so forwarded are marked "Corrigendum". 6. J3/interp creates a edit for the next Fortran Standard if one is needed for all interps marked "Corrigendum". ---------------------------------------------------------------------- ====================================================================== Part 2: Correctly numbered F95 interpretations ====================================================================== NUMBER: 00000e TITLE: Rejected Minor edits and corrections KEYWORDS: typographical errors DEFECT TYPE: Interpretation STATUS: J3 consideration in progress QUESTION: Should the following be added to the list of edits? 8. In 13.13.85 RANGE change 'Returns the decimal exponent range in the model ...' to 'Returns the upper bound of the decimal exponent range of the model ...' [228:20] Rationale(1): a range has two values; RANGE returns only one. Rationale(2): there is not a decimal range in the model, see 13.7.1, but a decimal range can be calculated. Thus the change from 'in' to 'of'. 9. In 13.13.79 PRECISION change 'Returns the decimal precision in the model ...' to '............................. of .............' at [226:4] Rationale: same as for RANGE, above. ANSWER: This item collects failed "minor edits and corrections" so that the reasons for failing them can be recorded for historical purposes. No further voting is needed for items in this list. No, 8 and 9 should not be added. The use of 'range' is consistent with other uses in the standard and is meant to convey an entire range of values not just 2. The change from 'in' to 'of' is too small a change to be included at this time and would best be addressed in a future standard. EDITS: None SUBMITTED BY: HISTORY: 94-028 m128 additional items 8-9 ---------------------------------------------------------------------- NUMBER: 000004 TITLE: Value returned by MAXVAL/MINVAL KEYWORDS: MAXVAL, MINVAL DEFECT TYPE: Interpretation STATUS: Passed by WG5 ballot QUESTION: The Result Value section of the MAXVAL intrinsic function description uses the phrasing: or has the value of the negative number of the largest magnitude supported by the processor for numbers of the type and kind type parameter of ARRAY if ARRAY has size zero This phrasing has generated at least the two following views on the return value: * If the machine supports the IEEE standard then the implementation should return -inf. * For portability, the implementation should return -HUGE(ARRAY). These views lead to the following questions: 1. Is the intent of the standard to describe the result in terms of machine values rather than model values? 2. If the answer to 1 is "yes", how are programmers expected to use this intrinsic function portably? ANSWER: 1. Yes. Processors may support values that are not present in the model of 13.7.1. IEEE -inf is an example of such a number and this may be returned on a machine that supports the IEEE standard. If the negative number of the largest magnitude in the model had been intended, the model would have been mentioned as, for example, in the definition of HUGE (13.14.39). 2. A simple example of its use is to test whether a set of numbers SET1 has a value greater than any value in the set SET2. Consider the expression MAXVAL (SET1) > MAXVAL (SET2). If SET1 is empty and SET2 is not, this value is correctly false even if all of the values are outside the model with values less than -HUGE (SET1). All of the reduction functions (e.g., MAXVAL, SUM) return values when the arguments are zero-sized arrays that may be the same as the values returned for some non-zero-sized arguments. NOTE: The NO votes in 00-254 were concerned that IEEE Infinities are not model numbers and are therefore not valid results for MINVAL and MAXVAL. The IEEE 754 standard is neither integrated into nor required by Fortran 95. However concessions were made to allow some IEEE exceptional values to be used by standard-conforming processors, like limited support for -0.0. EDITS: None. SUBMITTED BY: Larry Rolison HISTORY: 97-240 m143 submitted 00-160r2 m153 Passed 7-5 00-254 m154 Failed J3 letter ballot 04-298r1 m168 Passed J3 meeting vote 04-417r1 m170 Passed J3 letter ballot #8 05-180 m172 Passed by WG5 ballot N1617 ------------------------------------------------------------ NUMBER: 000006 TITLE: Character length specification of a function result KEYWORDS: character, function result DEFECT TYPE: Interpretation STATUS: Passed by WG5 ballot QUESTION: Consider the following program: PROGRAM main CHARACTER(8) arg, func EXTERNAL func CALL sub(arg, func) END PROGRAM SUBROUTINE sub(arg, func) CHARACTER(*) arg, func CHARACTER(8) str str = func(arg) ... END SUBROUTINE CHARACTER(8) FUNCTION func(arg) CHARACTER(*) arg ... END FUNCTION Some implementations reject the reference to FUNC in subroutine SUB and some do not. The implementations that do not reject the reference to FUNC use essentially the following as the argument for allowing the reference: The rules for when an asterisk can be used to specify character length are specified in section 5.1.1.5 (middle of page 51 of the Fortran 95 standard). * The first rule states that an asterisk may be used to declare a dummy argument of a procedure. It is clear that FUNC is a dummy argument of SUB. * The third rule says that in an external function, the length of the result may be specified within the function itself with an asterisk but if the result length is so specified, any invoker of the function must specify the character length of the function result as something other than an asterisk. But the function that is being invoked in the above example does not declare its result length using the asterisk, so this rule does not apply. Is the above sample program a standard conforming program with respect to the concept of declaring the function result length in the invoking program as an asterisk? ANSWER: Yes. When item (1) on page 51 is applied to the argument func of sub, it tells us that its length is 8 for the call from the main program. NOTE: The NO votes in 01-380 raised the concern that this answer introduced a binary incompatibility with FORTRAN 77. FORTRAN 77 features continue to work in Fortran 95; Fortran 95 features may not always work in FORTRAN 77. EDITS: None SUBMITTED BY: Larry Rolison HISTORY: J3/97-242 m143 submitted WG5-N1456 Draft answer 01-305r1 m158 Passed by J3 meeting 01-380 m159 Failed J3 letter ballot 04-299r1 m168 Passed J3 meeting vote 04-417r1 m170 Passed by J3 letter ballot #8 05-180 m172 Passed by WG5 ballot N1617 ---------------------------------------------------------------------- NUMBER: 000008 TITLE: Optional arguments to MAX/MIN KEYWORDS: intrinsic function, MAX, MIN, optional, argument DEFECT TYPE: Interpretation STATUS: Passed by WG5 ballot QUESTION: It appears that there is a missing "optional" in the description of the optional arguments [, A3, ...] in the MAX and MIN functions. In the Fortran 90 standard, the MAX/MIN descriptions said "optional arguments. A3, ...", but those words do not appear 13.14.64 of the Fortran 95 standard. Section 13.3 of Fortran 95 [217:27+] states ...optional arguments... are identified by the notation "optional" in the argument descriptions. and goes on to describe another notation for the arguments that are listed as optional. But it doesn't say anything about arguments given in [...] and NOT also listed as optional. Suggested change to the argument descriptions for MAX and MIN: Arguments. A1, A2 shall both have the same type which shall be integer or real and they shall both have the same kind type parameter. A3, ... (optional) shall have the same type and kind type parameter as A1. ANSWER: There is an anomaly in the presentation of MAX and MIN but the intent is clear, ie, dummy arguments A3 and beyond are optional. EDITS: None NOTE: The same descriptive form reported here in Fortran 95 appears in Fortran 2003 for MAX and MIN. SUBMITTED BY: Larry Rolison / Dick Hendrickson HISTORY: 97-245 m143 submitted 04-300r1 m168 Passed J3 meeting vote 04-417r1 m170 Passed by J3 letter ballot #8 05-180 m172 Passed by WG5 ballot N1617 ---------------------------------------------------------------------- NUMBER: 000017 TITLE: Characteristics of an array function result KEYWORDS: Characteristics, function DEFECT TYPE: Interpretation STATUS: Passed by WG5 ballot Sections 12.2.1.1 and 12.2.2 of the Fortran 95 standard define rules for dummy arguments and function returns in the presence of explicit interfaces that allow array bounds expressions to be evaluated on either the calling side or the called side of a call. The interpretation provided for RFI 000049 on the X3J3 website clarifies and reinforces the conditions that permit evaluation on either side of the call. The erratum published in the same file for RFI 000070 changes the semantics of dummy arguments. The erratum does not explicitly mention function results, but it might be considered to imply a similar change to the semantics of function results. The erratum provided for RFI 000070 refers to altered text for the interpretation provided for RFI 000049. The version of the interpretation that appears in the file on the X3J3 website does not contain the altered text. The definition of characteristics of function results as stated in Section 12.2.2 of the Fortran 95 standard permits more efficient implementation of array-valued functions, at least for some architectures, than the definition implied by the erratum provided for RFI 000070. For Sun, it is more efficient for the calling routines to allocate space for array results than to have the called routines allocate the space. In order for the calling routine to allocate space for an array result, it must know the size of the array. To determine the size of the array, it must evaluate the array bounds expressions given in the explicit interface for the function. Section 12.2.2 of the Fortran 95 standard requires the values of the nonconstant bounds expressions given in an explicit interface to be the same as the values of the bounds expressions given in the corresponding function definition. Thus, the values of the nonconstant bounds expressions used to determine the size of the array result can be passed to the called routine, avoiding any need for the called routine to re-evaluate those expressions. Because Fortran 95 allows user-defined routines to appear in bounds expressions, evaluating the bounds expressions more than once per call could prove inefficient and confusing. The change implied by the erratum provided for RFI 000070 would remove the nonconstant bounds expressions from the characteristics of function results. The shape would still be a characteristic, but the same shape can be produced by many different values of the bounds expressions. Thus, the values of the nonconstant bounds expressions used in the called routine may differ from the values of the corresponding expressions in the explicit interface. For example, consider the explicit interface INTERFACE FUNCTION FOO(F, G, H) INTERFACE PURE INTEGER FUNCTION F() END FUNCTION PURE INTEGER FUNCTION G() END FUNCTION PURE INTEGER FUNCTION H() END FUNCTION END INTERFACE CHARACTER*(F()) FOO(G():H()) END FUNCTION END INTERFACE The definition given in Section 12.2.2 of the Fortran 95 standard requires the values of the length and bounds expressions in the interface to be the same as the values of the corresponding length and bounds expressions in the function definition. Under the definition implied by the erratum provided for RFI 000070, the shapes must match, but the values of the nonconstant bounds expressions need not. Thus, the function definition might be FUNCTION FOO(F, G, H) INTERFACE PURE INTEGER FUNCTION F() END FUNCTION PURE INTEGER FUNCTION G() END FUNCTION PURE INTEGER FUNCTION H() END FUNCTION END INTERFACE CHARACTER*(F()) FOO(G()-1:H()-1) . . . END FUNCTION In this case, the values of the bounds expressions used in the called routine must be the values of the expressions specified in the function definition, not the values of the expressions specified in the interface block. QUESTION: If a bound of a function result array is not a constant expression, is the exact dependence on the entities in the expression a characteristic of the function result? ANSWER: No. According to Corrigendum 1, the correct statement is now: "If a bound of a function result array is not an initialization expression, the exact dependence on the entities in the expression is a characteristic of the function result." EDITS: None REFERENCES: 95-006a, F90/000027, F90/000049 & F90/000070, 04-295, N1416 (Corrigendum 1). SUBMITTED BY: Robert Paul Corbett HISTORY: 98-114 submitted 04-313 m168 Passed J3 meeting vote 04-417r1 m170 Passed by J3 letter ballot #8 05-180 m172 Passed by WG5 ballot N1617 ---------------------------------------------------------------------- NUMBER: 000023 TITLE: Termination of the previous record by a WRITE statement KEYWORDS: Nonadvancing, Record termination, WRITE DEFECT TYPE: Interpretation STATUS: Passed by WG5 ballot QUESTION: Suppose a sequential formatted file is positioned within a record as a result of a nonadvancing READ. 1. If the next operation performed on the file is a WRITE, can the current record be terminated at its current position before the next record is written? Section 9.2.1.3.2 appears to preclude the record from being terminated, but at least one Fortran 90 implementation does the record in such an instance. 2. If next operation is a nonadvancing WRITE and the number of characters written does not extend to the end of the current record, are the remaining characters at the end of the record preserved? ANSWER: 1. No. If the current record were to be terminated, the file position would be changed. Section 9.2.1.3.2 of Fortran 95 [136:37-39] states: "For sequential access on input, if there is a current record, the file position is not changed. Otherwise, the file is positioned at the beginning of the next record and this record becomes the current record." 2. Yes. The remaining characters in the record are preserved. Consider the following different, but related, example: program write_write write (10,"(a,t1,a,a)") "XXXXXXXXX", "ABC", "DEF" write (10,"(a,t1,a)",advance='no') "XXXXXXXXX", "ABC" write (10,"(a)") "DEF" end The output from this program is ABCDEFXXX ABCDEFXXX From the description of Position editing (10.6.1) it is clear that the output following the tab does not cause the deletion of the final XXX characters from the record. The fact that the second output record is created by a non-advancing write followed by an advancing write is not operationally different from the single advancing write that created the first record. The fundamental difference between this example and the question considered in the interp is the mechanism by which the current location in the record is established prior to the final advancing write statement. It would be inconsistent to have one case preserve previously existing characters in the record and the other case to require the opposite. To avoid this inconsistency, the answer to Question 2 is Yes. EDITS: None SUBMITTED BY: Robert Corbett HISTORY: 98-155 m145 Submitted (part 1) WG5/N1410 Draft answer 01-151r1 m156 Passed unanimously by J3 meeting 01-224r1 m157 Failed J3 letter ballot 04-301 m168 Passed J3 meeting vote 04-417r1 m170 Passed by J3 letter ballot #8 05-180 m172 Passed by WG5 ballot N1617 ---------------------------------------------------------------------- NUMBER: 000030 TITLE: Ordering requirements on definition of specification functions KEYWORDS: Specification expressions, specification functions DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot 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.14: 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.16: 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 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 ---------------------------------------------------------------------- NUMBER: 000031 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 #74 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 tothe standard. See the answer to F95 interpretation #000074. EDITS: None SUBMITTED BY: Henry Zongaro HISTORY: 98-177 m146 Submitted WG5/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 ---------------------------------------------------------------------- NUMBER: 000068 TITLE: Asterisks as I/O units KEYWORDS: Asterisk, I/O, unit DEFECT TYPE: Interpretation STATUS: Passed by WG5 ballot Question: 1. Does the Fortran 95 standard require the external unit corresponding to the I/O unit identified by an asterisk for input or output to be the same as the external unit identified by some fixed nonnegative integer value? 2. Can the I/O unit identified by an asterisk for input or output correspond to more than one external unit? 3. If the external unit identified by an integer value that corresponds to the I/O unit identified by an asterisk for input or output is closed, does that cause the I/O unit identified by an asterisk to become disconnected? ANSWER: 1. No. 2. No. 3. Not addressed by Fortran 95. DISCUSSION: The submitter states: At least one Fortran 95 implementation uses -1 as the value of the I/O unit identified by an asterisk. A carefully constructed INQUIRE statement can expose this value to the user. Many users expect I/O to the units identified by asterisks to continue to work even after the corresponding units identified by integer values have been closed. 1. There is no requirement in the standard that the asterisk correspond to an external-file-unit; it is, however, permissible. 2. For the units identified by the asterisk, the text of section 9.3.2 does not allow two or more units to be connected simultaneously to the same file [139:8-9]. 3. Fortran 95 does not specify the behavior in this instance. REFERENCES: ISO/IEC 1539-1:1997(E), Sections 9.3 and 9.4.4.2 EDITS: None SUBMITTED BY: Robert Corbett HISTORY: 99-192 m150 Submitted 99-215r1 m150 approved uc 00-208 m153 passed by J3 letter ballot 00-268 m154 Failed WG5 letter ballot (N1395 & N1403) WG5/N1452 Suggested revision (expanded discussion) 01-296r1 m158 Passed by J3 meeting 01-380 m159 Failed J3 letter ballot 04-306r1 m168 Passed by J3 meeting vote 04-417r1 m170 Passed by J3 letter ballot #8 05-180 m172 Passed by WG5 ballot N1617 ---------------------------------------------------------------------- NUMBER: 000074 TITLE: TARGET dummy arguments and POINTER expressions KEYWORDS: TARGET, POINTER, dummy arguments DEFECT TYPE: Interpretation STATUS: J3 consideration in progress 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: 1. The call to s1 is not standard conforming. 12.5.2.1 says: 'A dummy data object whose intent is not specified is subject to the limitations of the data entity that is the associated actual argument. That is, a reference to the dummy data object may occur if the actual argument is defined and the dummy data object may be defined if the actual argument is definable.' Here the actual argument is a function result, which is not definable. For example, it is not permitted on the left-hand side of an assignment statement, since it is not a variable. (Being "defined" or "undefined" is fundamentally a concept that applies only to variables.) 2. The call to s2 is not standard conforming. 12.4.1.1 says: 'If a dummy argument has INTENT(OUT) or INTENT(INOUT), the actual argument shall be definable.' Again the actual argument is a function result, 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.1, which says [200:38-42]: 'If the dummy argument has the TARGET attribute and is either scalar or is an assumed-shape array, and the corresponding actual argument has the TARGET attribute but is not an array section with a vector subscript (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 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 ---------------------------------------------------------------------- NUMBER: 000078 TITLE: Resolving generic procedure references KEYWORDS: INTENT(IN), NULLIFY DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot 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: [279:36+] 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 04-296r1 m168 Passed J3 meeting vote 04-417r1 m170 Passed by J3 letter ballot #8 05-180 m172 Passed by WG5 ballot N1617 ---------------------------------------------------------------------- NUMBER: 000096 TITLE: End-of-record and PAD KEYWORDS: End-of-record, PAD DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot 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: 97-007r2 [150:15] Replace "corresponding data edit descriptor" by "its corresponding data edit descriptors". [153:13-14] Replace "corresponding data edit descriptor" by "corresponding data edit descriptors". SUBMITTED BY: Van Snyder HISTORY: 01-340 m158 submitted 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 ---------------------------------------------------------------------- NUMBER: 000098 TITLE: Are dummy functions returning assumed-length character legal? KEYWORDS: DUMMY FUNCTION, ASSUMED-LENGTH CHARACTER DEFECT TYPE: Interpretation STATUS: J3 consideration in progress QUESTION: Are dummy functions returning assumed-length character legal? Consider the following program: character*5 f external f call ss3(f) end subroutine ss3(ff) character*(*) ff, a*10 external ff a = ff()//'99999999' print *, '<', a, '>' end function f() character*(*) f f = '123' end The issue is the call to the dummy function 'ff' in subroutine 'ss3'. Some compilers issue an error message. Others print the result: <123 99999> There appear to be two relevant, contradictory passages in the F95 standard. Refer to section 5.1.1.5. <> means italics, [] means obsolescent font. The third constraint says "A function name shall not be declared with an asterisk [unless it is the name of the result of an external function or the name of a dummy function.] Before note 5.6 on the next page, the third bullet says: (3) [In an external function, the name of the function result may be specified with a character length parameter value of *; in this case, any scoping unit invoking the function shall declare the function name with a character length parameter value other than * or access such a definition by host or use association. When the function is invoked, the length of the result variable in the function is assumed from the value of this type parameter.] According to the standard, the use in the example program is legal, because 'ff' is the name of a dummy function. But it seems clear that the standard intended that the length of the variable returned by a character function be known at compile time; it is not known in the case where the function is a dummy function. ANSWER: EDITS: SUBMITTED BY: Larry Meadows HISTORY: 02-157 m160 Submitted 04-417r1 m170 Duplicate of interp #6 05-180 m172 Failed WG5 ballot N1617 - not a duplicate of F95 interp 000006 ---------------------------------------------------------------------- NUMBER: 000099 TITLE: STAT= variable requirements in ALLOCATE KEYWORDS: ALLOCATE, STAT= DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot QUESTION: [79:40-41] says "The shall not appear in a bound in the same ALLOCATE statement." This requirement appears, on the face of it, to apply to the syntax, not to whichever actual variable is identified by the syntax. Question 1: Given INTEGER :: A(10) = (/ (i,i=1,10) /) POINTER P(:) READ *,I,J ALLOCATE(P(A(I)),STAT=A(J)) Is the ALLOCATE standard-conforming, or does it depend on the relative values of I and J? From the quoted text, it would appear that it is always conforming, even when I==J. Question 2: Similarly, given: EQUIVALENCE(I,J) POINTER P(:) I = 5 ALLOCATE(P(I),STAT=J) is the ALLOCATE conforming? Question 3: Similarly, given: POINTER P(:) INTRINSIC DIGITS I = 5 ALLOCATE(P(DIGITS(I)),STAT=I) is the ALLOCATE conforming? From the quoted text, it would appear not to be conforming, despite the non-dependence of the array bound on the value of the STAT= variable. ANSWER: The intent was that the restriction should apply to the actual variable being used for the STAT= variable, not to the syntax. Thus, (1) The ALLOCATE statement is only standard-conforming if I and J are not equal. (2) The ALLOCATE statement is not standard-conforming. (3) The ALLOCATE statement is standard-conforming. Edits to the standard are supplied to clarify this. EDITS: [79:40-41] Delete "The ... statement." [80:6] Append to paragraph "No array bound in an ALLOCATE statement shall depend on the value of the ." SUBMITTED BY: Malcolm Cohen HISTORY: 02-232 m162 Submitted 02-232r1 m162 Revised, passed by J3 meeting 03-197 m165 Passed by J3 letter ballot #7 03-218 m165 Passed by WG5 ballot ---------------------------------------------------------------------- NUMBER: 000100 TITLE: TARGET attribute and structure components KEYWORDS: TARGET, POINTER DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot QUESTION: The standard says ([110:43-44]), of R737 , "Constraint: The shall have the TARGET attribute or be a subobject of an object with the TARGET attribute, or it shall have the POINTER attribute." It also says ([75:22-23]), of structure components "A structure component has the ... TARGET ... attribute if the parent object has the attribute." The <> is defined ([75:16]) as "the data object whose name is the leftmost part name". Consider: TYPE t REAL x END TYPE TYPE(t),POINTER :: p REAL,POINTER :: q ALLOCATE(p) q => p%x Q1. Is this standard-conforming? If the answer to Q1 is Yes, this still appears to leave unspecified the case of A%B%C where A does not have the TARGET attribute and B has the POINTER attribute. The parent object of A%B%C is just A, and A does not have the TARGET attribute. Therefore the conclusion is that A%B%C does not have the TARGET attribute. Note: Although the standard says that "Allocation of a pointer creates an object that implicitly has the TARGET attribute" [81:47-48], is it not entirely sure that this shows that A%B%C has the attribute for two reasons: (1) Allocation is not the only way of establishing pointer associations. (2) According to the quoted text, whether A%B refers to an object with the TARGET attribute is immaterial; the only question is whether A itself has the TARGET attribute. Q2. Does this A%B%C have the TARGET attribute? Note: the following example may be relevant: TYPE t TYPE(t2),POINTER :: p END TYPE TYPE t2 REAL x END TYPE TYPE(t) v TYPE(t2),POINTER :: z REAL,POINTER :: q ALLOCATE(v%p) ! ! (a) ! z => v%p q => z%x ! ! (b) ! q => v%p%x The pointer assignments following (a) are clearly valid: the first assigns one pointer to another, and if the answer to Q1 is Yes, the second one follows from that. But the (a) statements have the same effect as the (b) statement, so it would be inconsistent to disallow (b). Q3. Apparently, substrings never have the INTENT, TARGET or PARAMETER attribute. Is this a deliberate omission? ANSWER: Q1: Yes. P points to an object with the TARGET attribute, and X is a subobject of this object. Therefore, "Q => P%X" is conforming. Q2: The standard leaves this case unspecified, but the intent is that any part of an object with the TARGET attribute should itself have the attribute. An edit is supplied to remedy this omission in the standard. Q3: No, this omission was inadvertant. An edit is supplied to fix this. EDITS: [74:33] Append to paragraph "A substring has the INTENT, TARGET, or PARAMETER attribute if its parent has the attribute, but it never has the POINTER attribute." {Fix omission. Text parallels that for array elements and sections.} [75:22] Delete ", TARGET,". [75:23] After "." insert "A structure component has the TARGET attribute if the parent object has the attribute or if any except the rightmost has the POINTER attribute." [110:43-44] Delete "be a subobject of an object with the TARGET attribute or it shall have". {Now that propagation of TARGET is fixed, we don't need the weasel words.} SUBMITTED BY: Malcolm Cohen HISTORY: 02-233 m162 Submitted 02-233r1 m162 Revised, passed by J3 meeting 03-197 m165 Passed by J3 letter ballot #7 03-218 m165 Passed by WG5 ballot ---------------------------------------------------------------------- NUMBER: 000101 TITLE: Generic resolution KEYWORDS: generic, argument DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot QUESTION: Consider: INTERFACE g SUBROUTINE s1(p) INTERFACE SUBROUTINE p END END INTERFACE END SUBROUTINE s2(p) INTERFACE REAL FUNCTION p() END END INTERFACE END END INTERFACE EXTERNAL procedure CALL g(procedure) The generic interface block seems to satisfy the requirements of 14.1.2.3, in that s2 has more arguments of type REAL than has s1, but since the data type of "procedure" is not known (it may be a default REAL function, or it may be a subroutine), the CALL appears to be ambiguous. Is this code standard-conforming? ANSWER: No, this was not intended to be standard-conforming. An edit is supplied to correct this oversight. EDITS: [277:21-23] Change "arguments" to "data objects" three times. SUBMITTED BY: Malcolm Cohen. HISTORY: 02-251 m162 Submitted, passed by J3 meeting 03-197 m165 Passed by J3 letter ballot #7 03-218 m165 Passed by WG5 ballot ---------------------------------------------------------------------- NUMBER: 000102 TITLE: mask-expr evaluated only once KEYWORDS: WHERE DEFECT TYPE: Erratum STATUS: J3 consideration in progress 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: No, it is not required to evaluate the mask-expr in a WHERE. An edit is supplied to correct this oversight. EDITS: [112:30-31] Change "only once" to "at most once" [112:38] Change "only once" to "at most once" SUBMITTED BY: Matthijs van Waveren HISTORY: 03-239 m165 Passed by J3 meeting vote 04-417r1 m170 Passed by J3 letter ballot #8 05-180 m172 Failed WG5 ballot N1617 ---------------------------------------------------------------------- NUMBER: 000103 TITLE: Derived type name DOUBLEPRECISION KEYWORDS: Derived type DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot QUESTION: Consider: TYPE doubleprecision REAL x END TYPE According to 4.4.1, the name of a derived type "shall not be the same as the name of any intrinsic type defined in this standard" ([38:34-35]). However, the intrinsic types are only "integer", "real", "complex", "logical" and "character" (4.3, [31:2-4]). Therefore this derived type definition would appear to be allowed. Was it intended to allow a derived type to be named DOUBLEPRECISION? ANSWER: No, this was not intended. An edit is provided to correct this inadvertent omission. EDITS: [38:34] Before "the same" insert "DOUBLEPRECISION or". SUBMITTED BY: Malcolm Cohen HISTORY: 03-242 m165 Passed by J3 meeting vote 04-417r1 m170 Passed by J3 letter ballot #8 05-180 m172 Passed by WG5 ballot N1617 ---------------------------------------------------------------------- NUMBER: 000104 TITLE: Representation method of result of REAL KEYWORDS: "Representation method" KIND REAL DEFECT TYPE: Interpretation STATUS: Passed by WG5 ballot QUESTIONS: Subclause numbers refer to 97-007r2. The second and third sentences of subclause 4.3.1.2 are A processor shall provide two or more approximation methods that define sets of values for data of type real. Each such method has a representation method and is characterized by a value for a type parameter called the kind type parameter. 1. Does this imply that there is a one-to-one correspondence between kind type parameter values and representation methods? Since the second quoted sentence says "a value," not "some values," assume the answer to this question is "yes." Subclause 7.1.4.2 specifies the type and kind type paramter value for the result of an operation. 2. Is a processor allowed to use a representation method that corresponds to a different kind type parameter value of the same type, or no kind type parameter value, at least if neither the precision nor exponent range of the different representation method is less than the one specified in 7.1.4.2? Subclause 7.1.4.1 specifies the type and kind type paramter value for a variable. 3. Is a processor allowed to use a representation method that corresponds to a different kind type parameter value of the same type, or no kind type parameter value, at least if neither the precision nor exponent range of the different representation method is less than the one specified in 7.1.4.1? Subclause 7.1.4.1 specifies the type and kind type parameter value for a result of a function. 4. Is a processor allowed to use a representation method that corresponds to a different kind type parameter value of the same type, or no kind type parameter value, at least if neither the precision nor exponent range of the different representation method is less than the one specified in 7.1.4.1? Subclause 13.14.28 specifies that the result of DBLE is the same as the result of REAL with a KIND argument having the value KIND(0.0d0). Subclause 13.14.88 specifies that the kind type parameter value of the result of REAL is that specified by the KIND argument. 5. Is a processor allowed to use a representation method for the result that corresponds to a different kind type parameter value of the same type, or no kind type parameter value, at least if neither the precision nor exponent range of the different representation method is less than the one specified in 13.14.88? ANSWER: The answer to question 1 is yes, since each valid real kind type parameter value characterizes a representation method for an approximation method (4.3.1.2). Clause 1.4 says 'This standard does not specify ... (6) The physical properties of the representation of quantities and the method of rounding, approximating, or computing numeric values on a particular processor, ...' The processor is therefore free to use different precision for intermediate real calculations, which answers all the other questions. EDITS: None SUBMITTED BY: Van Snyder HISTORY: 04-283 m168 submitted 04-307 m168 Passed by J3 meeting vote 04-417r1 m170 Passed by J3 letter ballot #8 05-180 m172 Passed by WG5 ballot N1617 ---------------------------------------------------------------------- ====================================================================== Part 3: Unfinished F90 interpretations with their F90 interp number. ====================================================================== NUMBER: F90/000049 TITLE: Characteristics of function results KEYWORDS: characteristics, function result, ENTRY statement, exact dependence, association - partial, association - entry DEFECT TYPE: Interpretation STATUS: Passed by WG5 ballot QUESTION: Given a character function with an ENTRY statement, both results must have the same characteristics or be scalars without the POINTER attribute and have identical length. Therefore: FUNCTION FUN(M,N) CHARACTER (LEN=M+N)::FUN,ENT ... ENTRY ENT(M,N) ... END FUNCTION is standard conforming. Question 1: FUNCTION FUN(M,N) CHARACTER (LEN=M+N)::FUN CHARACTER (LEN=M+N)::ENT ... ENTRY ENT(M,N) ... END FUNCTION Is the code above standard conforming? Question 2: FUNCTION FUN(M,N) CHARACTER (LEN=M+N)::FUN CHARACTER (LEN=N+M)::ENT ... ENTRY ENT(M,N) ... END Is the code above standard conforming? Question 3: FUNCTION FUN(M) CHARACTER (LEN=M+M)::FUN CHARACTER (LEN=M*2)::ENT ... ENTRY ENT(M) ... END Is the code above standard conforming? Question 4: What is the meaning of the phrase "the exact dependence on the entities" in section 12.2.2? ANSWER: Answer 1. Yes Answer 2. Yes Answer 3. Yes Answer 4. The sentence containing the phrase "the exact dependence on the entities" in section 12.2.2 is intended to convey that in those cases where the shape or character length type parameter is not constant, the corresponding characteristic of the function result is not a value but the way the value is determined when the procedure is invoked. Discussion: Only the mapping from program state to value is significant, not the particular form in which that mapping is expressed. In question 3, for example, it is a characteristic of FUN and ENT that their lengths are twice the value of M. It is not required that the expressions of this mapping be identical, only that they yield the same results. Thus, twice the value of M could be expressed as M+M for FUN and as M*2 for ENT. The phrase "the exact dependence on the entities in the expression is a characteristic" is used to give the processor the freedom to evaluate lengths and bounds in any convenient manner. Since the characteristics must be the same, the phrase implies, as a minimum, that the expressions be algebraically equivalent and use the same variables. In an example such as: FUNCTION FUN(M) CHARACTER (LEN=M)::FUN CHARACTER (LEN=M + 0*K)::ENT ... ENTRY ENT(M, K) ... END FUN and ENT do not have the same characteristics since their dependence on "K" is different. Indeed, if on entry to FUN the length of FUN or ENT were evaluated using the expression for the length of ENT the evaluation would fail since K is not associated with a value. Clearly, it can be extremely difficult to determine on a static basis whether two expressions of a mapping are consistent, and there is no requirement in the standard that this be done. It would be possible to check during execution that the values expressed are identical each time such a procedure is invoked, but it is expected that a more typical application of this requirement would be to assume that it has been met and use one expression of this mapping as the basis for computing attributes of all of the result variables. REFERENCES: ISO/IEC 1539:1991 (E) section 12.2.2 & 14.6.3.3 EDITS: None SUBMITTED BY: Y. Yoshida, X3J3/92-051 (121-ADT-11) pp.-13 HISTORY: 92-109A m121 Approved 19-0 92-313 m123 response to ballot comments and approved by uc 93-105 Revised in response to ballot comments 93-152 m125 New edit, rejected 94-059 m128 New edit, 94-252 m130 New response without edits, approved u.c. 94-306 m131 X3J3 ballot approved 18-1 95-044 m132 WG5 ballot failed 006Ar1 m168 Passed by J3 meeting vote as in 02-006Ar1 04-417r1 m170 Passed by J3 letter ballot #8 05-180 m172 Passed by WG5 ballot N1617 ---------------------------------------------------------------------- NUMBER: F90/000070 TITLE: Characteristics specified by interface bodies KEYWORDS: characteristics, array bounds, array shape, function result DEFECT TYPE: Interpretation STATUS: Passed by WG5 ballot QUESTION: Section 12.3.2.2 indicates that an interface body specifies all of a procedure's characteristics and that the characteristics must be consistent with those in the procedure definition. Are the following code fragments standard conforming? (a) PROGRAM FRED INTERFACE SUBROUTINE SUB (ARR,J) INTEGER ARR(1:) END SUBROUTINE END INTERFACE INTEGER ARR(10) CALL SUB(ARR,2) END PROGRAM SUBROUTINE SUB(ARR, J) INTEGER ARR(J:) ... END SUBROUTINE SUB (b) FUNCTION C1( ) CHARACTER(*) C1 ... END FUNCTION C1 FUNCTION C2(N) CHARACTER(N) C2 ... END FUNCTION C2 SUBROUTINE CALLER( ) INTERFACE FUNCTION C1( ) CHARACTER(*) C1 END FUNCTION FUNCTION C2(N) CHARACTER(2) C2 END FUNCTION END INTERFACE CHARACTER(5) CC CC=C1( )//C2(2) ANSWER: (a) This example is standard conforming. (b) This example is not standard conforming. Discussion: (a) 12.2.1.1 states that the characteristics of a dummy data object include its shape, and that if the shape is assumed then that is a characteristic. Section 2.4.5 states that the shape of an array is determined by its rank and extent in each dimension (but not by its bounds, 5.1.2.4.2). Both the interface block for SUB and the definition of SUB describe the shape of ARR as assumed, so they are describing the same shape, and the program is standard conforming. (b) Section 12.2.2 states that the characteristics of a function include whether or not the function result value is a character of assumed length. So the interface body for function C1 must indicate that C1 is of assumed length. However, item (3) in 5.1.1.5 indicates that scoping units that invoke an external character function of assumed length must have access to a declaration of the function name with a length type parameter value other than *. This is explained in Note 5.6, (which has been removed in Fortran 2003). In addition, the interface for C2 does not conform to the standard as the length of C2 specified as 2 is not consistent with the length specified as N within the function definition. REFERENCES: ISO/IEC 1539:1991 (E) sections 2.4.5, 5.1.1.5, 5.1.2.4.2, 12.2.1.1, and 12.2.2. EDITS: None SUBMITTED BY: Graham Barber (a), Janice Shepherd (b) HISTORY: 92-264 Question (a) originally posed 92-46 Question (b) originally posed in e-mail ui 48 (jw note) 92-283 Response proposed m123 Approved by unanimous consent 93-018 Response questioned by John Reid in 93-103 Revised response proposed m124 Approved by unanimous consent 93-111 m125 ballot, return to subgroup, Leonard comment, coordinate with 0000049? 94-060 m128 New edit in F90/000049 referenced 04-295 m168 Passed by J3 meeting vote 04-417r1 m170 Passed by J3 letter ballot #8 05-180 m172 Passed by WG5 ballot N1617 ---------------------------------------------------------------------- NUMBER: F90/000096 TITLE: Definition of "Declaration" KEYWORDS: declaration, specification DEFECT TYPE: Interpretation STATUS: Passed by WG5 ballot QUESTION: "Declaration" is a significant concept of Fortran 90. Section 5 is titled "Data object declarations and specifications" and what were in FORTRAN 77 "type statements" are now "type declaration statements". 5.1.1 states "A type specifier specifies the type of all entities declared in an entity declaration list." Nowhere, though, is there a definition of "declaration". What does it mean, in Fortran 90, to "declare" something? ANSWER: That is correct, the standard does not define the term "declaration". It is used both in the sense of explicit specification, and of implicit declaration via usage or context. Both of these meanings fall within the normal English meaning of the term. The suggestion that the standard should define the term "declaration" may be considered for a future revision of the standard. EDITS: None. SUBMITTED BY: Dick Weaver HISTORY: 92-232 Submitted 92-232r Draft response, withdrawn 93-144 m125 unanimous consent 93-255r1 m127 ballot failed 16-7 94-103 m128 revised response, approved uc 94-116 m129 X3J3 ballot failed 16-7 94-223 m130 revised response 94-335 m131 alternate response proposed, withdrawn 04-309 m168 Passed by J3 meeting vote 04-417r1 m170 Passed by J3 letter ballot #8 05-180 m172 Passed by WG5 ballot N1617 ---------------------------------------------------------------------- NUMBER: F90/000140 TITLE: TARGET attribute for a derived-type object with a pointer component KEYWORDS: POINTER attribute, TARGET attribute, structure, structure component DEFECT TYPE: Interpretation STATUS: Passed by WG5 ballot QUESTION: Section 6.1.2 (page 63) states: "A structure component has the INTENT, TARGET, or PARAMETER attribute if the parent object has the attribute." A constraint following R505 (page 40) states: "Constraint: If the POINTER attribute is specified, the TARGET, INTENT, EXTERNAL, or INTRINSIC attribute must not be specified." This would seem to imply that a derived-type object with a pointer component could not have the TARGET attribute. Though it is informative, Annex C.4.6 (page 267) contains the following example: "TYPE CELL INTEGER :: VAL TYPE (CELL), POINTER :: NEXT_CELL END TYPE CELL TYPE (CELL), TARGET :: HEAD TYPE (CELL), POINTER :: CURRENT ... CURRENT => HEAD" which allows the static head of a linked list or tree. Does the structure component HEAD % NEXT_CELL contradict the text cited above from section 6.1.2 or the cited constraint following R505? ANSWER: No, the component reference does not contradict either the constraint or the cited text from 6.1.2. The cited text from 6.1.2 has been clarified by F95 interpretation 000100. Discussion: The constraints that follow a syntax rule, or a set of syntax rules, are syntactic constraints and apply only to the syntax rules they immediately follow. Thus, the constraints that follow rules R501 through R505 at the beginning of section 5 apply only to those rules. This means they apply only to type declaration statements. Since a derived type component is part of a derived type definition (which is not a type declaration statement), the constraints do not apply to derived type components. The rule that prevents an entity from having conflicting attributes when applied by multiple specification statements is found in 5.2: "The combination of attributes that may be specified for a particular entity is subject to the same restrictions as for type declaration statements regardless of the method of specification." EDITS: None. SUBMITTED BY: J. Martin in response to email May 7, 1993 from Yukimasa Yoshida HISTORY: 93-179 m125 canceled, interp number then reassigned 93-181 m125 Response, Withdrawn to remove suggested edit. 93-223r m126 Response proposed, approved uc 93-255r1 m127 ballot failed 18-5 94-339 m131 Revised response proposed, approved 14-2 95-034r1 m132 X3J3 ballot failed 8-12 95-033 m132 Revised response, straw vote on intent 5-2-7 95-092 m132 Revised discussion, approved u.c. 95-101 m133 X3J3 ballot failed 11-7 04-310 m168 Passed by J3 meeting vote 04-417r1 m170 Passed by J3 letter ballot #8 05-180 m172 Passed by WG5 ballot N1617 ---------------------------------------------------------------------- NUMBER: F90/000145 TITLE: Expressions in of a FUNCTION statement KEYWORDS: expression - specification, expression - initialization, FUNCTION statement, host association, use association DEFECT TYPE: Erratum STATUS: J3 consideration in progress QUESTION: The syntax rule R1217 shows that the type and type parameters of a function can be specified in the FUNCTION statement (12.5.2.2). (a) If a appears in a FUNCTION statement, can the initialization and specification expressions of that involve names of entities that are declared within the function or are accessible there by host or use association? (b) Section 5.1 states: "The (7.1.6.2) of a (5.1.1.5) or an (5.1.2.4) may be a nonconstant expression provided the specification expression is in an interface body (12.3.2.1) or in the specification part of a subprogram." As a FUNCTION statement is not part of the specification part of a subprogram, this text in the standard appears to distinguish between FUNCTION statements that are in interface blocks and ones that are not. This text seems to prohibit such examples as: INTEGER I ... CONTAINS CHARACTER*(I+1) FUNCTION F() ... COMMON // I ... where it can be confusing as to which I is being referenced in the FUNCTION statement. While host association does not apply to interface bodies, for consistency should the text quoted from Section 5.1 have been "... is in the specification part of an interface body (12.3.2.1) or in the specification part of a subprogram."? (c) Section 7.1.6.1 states: "If an initialization expression includes a reference to an inquiry function for a type parameter or an array bound of an object specified in the same , the type parameter or array bound must be specified in a prior specification of the ." Was this text intended to apply to FUNCTION statements even though they are not part of any , thus disallowing fragments such as: INTEGER (KIND=KIND(X)) FUNCTION F() INTEGER(KIND=KIND(0)) X ... Similar text appears in Section 7.1.6.2. ANSWER: (a) A specification expression in the of a FUNCTION statement may involve names of entities that are declared within the function or are accessible there by host or use association, but an initialization expression in such a may only involve names that are accessible by host or use association. (b) No. It was not the intent of the standard to distinguish between the two types of FUNCTION statements cited. As elaborated in the discussion of part (a), the standard intended to allow the expression of a FUNCTION statement to be a nonconstant expression. The sentence cited is corrected with a supplied edit. (c) Yes, the text cited from 7.1.6.1 was intended to apply to FUNCTION statements. The sentence quoted and the corresponding sentence in 7.1.6.2 are corrected with supplied edits. The code fragment is not standard conforming. Discussion: (a) An initialization expression is a constant expression with an additional rule relating to exponentiation (7.1.6.1). Since it is a constant expression, the only names it can contain are the names of named constants, structure constructors, intrinsic procedures, and variables whose type parameters or bounds are inquired about. * Named constant Section 5.1.2.1 states: "A named constant must not be referenced in any ... context unless it has been defined in a prior PARAMETER statement or type declaration statement using the PARAMETER attribute, or made accessible by use association or host association." Since the FUNCTION statement is the first statement of the scoping unit, there can be no prior PARAMETER statement or type declaration statement using the PARAMETER attribute, so the first clause does not apply. A named constant can appear in a of a function statement if it is accessible within the function by host or use association. * Structure constructor Rule R502 shows that the only opportunities for expressions to appear in s are in a or in a . However, a structure constructor can not appear in a because rule R505 shows that a must be an integer expression. Similarly, R506 shows that any initialization expression in a must be type integer. Therefore, a structure constructor can not appear in an initialization expression in the of a FUNCTION statement. * Intrinsic procedure The intrinsic procedure names or classes of intrinsic procedures that may appear in an initialization expression are given in 7.1.6.1. * Variables whose type parameters or bounds are inquired about The text from section 7.1.6.1 as cited in question (c) was intended to apply to initialization expressions in the of a FUNCTION statement. With the correction supplied, this means that if a variable appears as the argument to an inquiry intrinsic in the of a FUNCTION statement, the function must be a module procedure or an internal procedure, and the variable must exist in (be accessible from) the host scoping unit. Rule R502 defines . The only opportunity for a to contain a is when the data type is character ( may be a ). Section 7.1.6.2 states that a specification expression is a restricted expression that is scalar, of type integer, and each operation must be intrinsic. In addition, rule (2) of 7.1.6.2 states that a primary of a specification expression can be a dummy argument that has neither the OPTIONAL nor INTENT(OUT) attribute. The following code fragment demonstrates a use of such a dummy argument: CHARACTER*(N+1) FUNCTION S(N) INTEGER, INTENT(IN) :: N Rule (2) also states that the primary can be a subobject of such a dummy argument. Section 6.1.2 indicates that a structure component must not be referenced or defined before the declaration of the parent object. Similar rules are needed to prevent a substring from being referenced ahead of the declaration of its parent, and an array element or array section from being referenced ahead of the declaration of the array. Edits are provided to supply these rules. Since a subobject can not be referenced before its parent object is declared and the FUNCTION statement is the first statement of the subprogram, the parent's declaration could not have occurred. Thus a subobject must not be referenced in the on a FUNCTION statement for objects declared within the function. Rule (3) states that a primary can be a variable that is in a common block. The following code fragment demonstrates a use of such a common block member: CHARACTER*(N+1) FUNCTION S() ... COMMON N As in rule (2), rule (3) allows a subobject of such a variable but for the same reasons as above, such a subobject designator can not appear in the expression of a FUNCTION statement. Rule (4) states that a primary may be a variable that is accessible by use association or host association. The following code fragments demonstrate uses of such variables: PROGRAM MAIN INTEGER :: N = 21 ... CONTAINS CHARACTER(LEN = 2*N) FUNCTION SS(K) ! N is host ... ! associated. END FUNCTION END PROGRAM and MODULE MOD INTEGER K DATA K /20/ END MODULE CHARACTER*(K*2) FUNCTION CHECK(STR) ! K is use ! associated. USE MOD ... END FUNCTION Rule (4) also states that the primary can be a subobject of such a use or host associated variable. A structure constructor can not appear in a FUNCTION specification expression because the expression must be of type integer and any operations (which might yield an integer value from one or more structure constructors) must be intrinsic. Other rules of 7.1.6.2 state which intrinsic procedure names or classes of intrinsic procedures may appear in a specification expression. Section 7.1.6.2 also states: A variable in a specification expression must have its type and type parameters, if any, specified by a previous declaration in the same scoping unit, or by the implicit type rules currently in effect for the scoping unit, or by host or use association. The discussion above regarding specification expressions has already ruled out "previous declarations" so the first clause of the cited sentence does not apply. The other clauses apply equally to a FUNCTION statement and to type declaration statements inside the function. (b) When the discussion for part (a) is applied to the code fragment provided, it means that the 'I' referenced in the of the FUNCTION statement is the common block member. EDITS: 1. Section 5.1, in the first sentence of the paragraph that starts "The (7.1.6.2)" [40:39-41], change "in an interface body (12.3.2.1) or in the specification part of a subprogram" to "contained in an interface body (12.3.2.1), is contained in the specification part of a subprogram, or is in the of a FUNCTION statement (12.5.2.2)" 2. Section 6.1.1, add to the end of the paragraph before the examples [62:29] "A substring must not be referenced or defined before the declaration of the type and type parameters of the parent string, unless the type and type parameters are determined by the implicit typing rules of the scope." 3. Section 6.2.2, add after the sentence "An array section is an array." [64:16] "An array element or array section must not be referenced or defined before the declaration of the array bounds." 4. Section 7.1.6.1, in the paragraph after the constraints [78:21-22] change "object specified in the same , the type parameter or array bound must be specified in a prior specification of the ." to "object declared in the same scoping unit, the type parameter or array bound must be specified in a specification prior to the initialization expression." 5. Section 7.1.6.2, in the 2nd paragraph after the constraint [79:28-29] change "entity specified in the same , the type parameter or array bound must be specified in a prior specification of the ." to "entity declared in the same scoping unit, the type parameter or array bound must be specified in a specification prior to the specification expression." SUBMITTED BY: Janice C. Shepherd HISTORY: 93-193 m126 submitted 94-023r1 m128 response, approved uc 94-116r1 m129 X3J3 ballot failed 22-1 94-336 m131 revised response, approved u.c 95-034r1 m132 X3J3 ballot failed 15-5 95-281 m135 revised response, reworded edit 3, WG5 approved (N1161) 96- m136 X3J3 ballot failed 15-1, WG5 approval removed. ---------------------------------------------------------------------- NUMBER: F90/000180 TITLE: Unambiguous generic references KEYWORDS: host association, generic name DEFECT TYPE: Interpretation STATUS: Passed by WG5 ballot QUESTION: Consider the following example: SUBROUTINE S() INTERFACE GEN1 FUNCTION F1(I) END FUNCTION FUNCTION F2(I,J) END FUNCTION END INTERFACE INTERFACE GEN2 FUNCTION G1() END FUNCTION FUNCTION G2(I) END FUNCTION END INTERFACE CALL SS() CONTAINS SUBROUTINE SS() INTERFACE GEN1 FUNCTION F3(I,J,K) END FUNCTION FUNCTION F4(II) END FUNCTION END INTERFACE INTERFACE GEN2 SUBROUTINE G3() END SUBROUTINE END INTERFACE A = GEN1(1,2,3) ! CALL TO F3 A = GEN1(1,2) ! CALL TO F2 A = GEN1(1) ! CALL TO F4 CALL GEN2() ! CALL TO G3 END SUBROUTINE END There are rules in section 14.1.2.3 that determine within a scoping unit what procedures can have the same generic specification. These rules directly mention access of a generic procedure via use association, but they make no mention of generic names accessed via host association. There is evidence that the rules in section 14.1.2.3 were not intended to apply to generic interfaces accessed by host association. Section 14.1.2.4.1 indicates that a call to a generic name can be resolved to a generic name in the host if the scoping unit and the host scoping unit both agree that the generic name is the name of a function or a subroutine. This indicates that in the example above, the definition of 'GEN2' is valid, even though 'G1' and 'G2' are functions while 'G3' is a subroutine. If the rules set out in 14.1.2.3 were to apply then the definition of 'GEN2' would be invalid. Do the rules in 14.1.2.3 apply to generic procedures accessed via host association? ANSWER: Yes. [277:12-14] in Fortran 95 explains that the rules apply for all accessible generic interfaces, including those accessible by host association. The example program is not valid. EDITS: None. SUBMITTED BY: Janice C. Shepherd HISTORY: 94-239r3 m130 submitted with suggested answer 94-306 m131 X3J3 ballot, failed 15-4 04-308r1 m168 Passed by J3 meeting vote 04-417r1 m170 Passed by J3 letter ballot #8 05-180 m172 Passed by WG5 ballot N1617 ---------------------------------------------------------------------- NUMBER: F90/000206 TITLE: Collating sequence inconsistencies KEYWORDS: Collating sequence, ACHAR, CHAR, ICHAR DEFECT TYPE: interpretation STATUS: Passed by WG5 ballot [F95 36:28+] says that "A <> is a one-to-one mapping of the characters into the nonnegative integers such that each character corresponds to a different nonnegative integer." QUESTION 1: Does this definition imply that the one-to-one mapping is dense? That is, is there a requirement that if the default CHARACTER type has characters, the corresponding collating sequence maps to 0..-1 ? QUESTION 2: If the answer to question 1 is NO: is it correct that the restriction 0 <= i <= -1 on argument I of the intrinsic procedure CHAR (13.14.19) is inappropriate? QUESTION 3: If the answer to question 1 is NO: is it correct that the description of the << Result Value>> of the intrinsic procedure ICHAR (13.14.45), 0 <= ICHAR(C) <= -1 is inappropriate? QUESTION 4: Shouldn't argument I of the intrinsic procedure ACHAR (13.14.2) be restricted to the nonnegative integers? ANSWERS: (1) Yes. In the context of Fortran the character collating sequence is an ordered list of the characters in the character set associated with a list of integers denoting the position of each corresponding character in the ordered list of characters. The position number 0 is associated with the first character in the list. As position numbers, the list of integer values is necessarily dense. These position numbers are referenced in the descriptions of the CHAR and ICHAR intrinsic functions. The position numbers may be, but are not necessarily, equivalent to the bit patterns used to represent the associated characters in the computer hardware. (2) Moot because the answer to (1) is Yes. (3) Moot because the answer to (1) is Yes. (4) No. For characters that are not part of the ASCII character set, IACHAR returns a processor-dependent value that need not be in the ASCII collating sequence. ACHAR, being the inverse of IACHAR, should accept such values. EDITS: None. SUBMITTED BY: Michael Hennecke (hennecke@rz.uni-karlsruhe.de) HISTORY: submitted Feb. 17, 1996 (first appeared in 96-006r2) WG5/N1404 Draft answer 00-260 m154 Passed by J3 meeting 00-329 m155 Failed J3 letter ballot 04-304 m168 Passed by J3 meeting vote 04-417r1 m170 Passed by J3 letter ballot #8 05-180 m172 Passed by WG5 ballot N1617 ---------------------------------------------------------------------- NUMBER: F90/000207 TITLE: Integer bit-model inconsistency KEYWORDS: Bit manipulation procedures, models for integer data DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot 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: [219:22-24] Remove the sentence beginning "In particular..." SUBMITTED BY: Michael Hennecke HISTORY: submitted Mar. 12, 1996 (first appeared 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 ---------------------------------------------------------------------- NUMBER: F90/000208 TITLE: nonadvancing output followed by list directed output KEYWORDS: Nonadvancing, list directed DEFECT TYPE: Interpretation STATUS: Passed by WG5 ballot QUESTION: Section 10.8.2, last sentence. If nonadvancing output is followed by list-directed output, is a blank required before the first character written? (I assume that if the first character of the current record is not a blank, list-directed output is not required, though possibly permitted, to replace that character with a blank.) ANSWER: No. DISCUSSION: Following the non-advancing output operation, the location for the start of the next output operation is within the current record. The list-directed output operation begins at this location. List-directed output is an advancing output operation. Following the list-directed output the file position is after the just-written record. If the location for the start of the list-directed output operation is at the beginning of the record, a blank is written to the first location. Otherwise, no characters are inserted between the end of the non-advancing output and the start of the list-directed output. EDITS: None. SUBMITTED BY: Robert Paul Corbett (robert.corbett@Eng.sun.com) HISTORY: submitted Mar. 13, 1996 (first appeared in 96-006r2) WG5/N1404 Draft answer 00-260 m154 Passed by J3 meeting 00-329 m155 Failed J3 letter ballot 04-314 m168 Passed by J3 meeting vote 04-417r1 m170 Passed by J3 letter ballot #8 05-180 m172 Passed by WG5 ballot N1617 ---------------------------------------------------------------------- NUMBER: F90/000210 TITLE: nonadvancing write followed by list directed write KEYWORDS: Nonadvancing, list directed DEFECT TYPE: Interpretation STATUS: Passed by WG5 ballot QUESTION: If a program does a nonadvancing WRITE followed by a list-directed WRITE, must the list-directed WRITE write to the current record or may it start a new record? ANSWER: The list-directed WRITE is not required to start a new record. DISCUSSION: Following the non-advancing output operation, the location for the start of the next output operation is within the current record. The list-directed output operation begins at this location. New records may be created during processing of the list-directed output statement. EDITS: None. SUBMITTED BY: Robert Paul Corbett HISTORY: submitted Mar. 13, 1996 (first appeared in 96-006r2) WG5/N1404 Draft answer 00-260 m154 Passed by J3 meeting 00-329 m155 Failed J3 letter ballot 04-315 m168 Passed by J3 meeting vote 04-417r1 m170 Passed by J3 letter ballot #8 05-180 m172 Passed by WG5 ballot N1617 ---------------------------------------------------------------------- ====================================================================== Part 4: Interpretation Requests of Japan ====================================================================== NUMBER: JP-17 TITLE: Multiple occurrence of namelist group object in namelist group KEYWORDS: NAMELIST DEFECT TYPE: Interpretation STATUS: Passed by WG5 ballot QUESTION: JP-17) 5.4 3rd paragraph after R545 and constraints states that: "A namelist group object may be a member of more than one namelist group." Can a namelist group object occur more than once in one namelist group? Is the following NAMELIST statement standard conforming? NAMELIST /NLIST/A,B,A ANSWER: Yes. DISCUSSION: Sections 5.4 "NAMELIST Statement" and 10.9 "Namelist Formatting" in Fortran 95 do not disallow multiple occurrences of a namelist group object in a namelist group. This is also true in Fortran 90. Therefore the multiple occurrences are standard conforming. EDITS: None. SUBMITTED BY: Japan HISTORY: 99-208 Submitted 99-221 Classed as Fortran 95 Interpretation. WG5-N1411 Draft answer 00-260 m154 Passed by J3 meeting 00-329 m155 Failed J3 letter ballot 01-300 m158 Passed by J3 meeting 01-380 m158 Passed by J3 letter ballot WG5/N1470 Failed WG5 ballot 02-130 m160 Change "no" to "yes": Passed by J3 meeting 03-197 m165 Passed by J3 letter ballot #7 03-218 m165 Passed by WG5 ballot ---------------------------------------------------------------------- NUMBER: JP-24 TITLE: The bnf term shared-term-do-construct KEYWORDS: DO, BNF DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot QUESTION: JP-24) In 8.1.4.2, second constraint below R833 states that: "The do-term-shared-stmt shall be identified with a label and all of the label-do-stmts of the shared-term-do-construct shall refer to the same label." This implies a label-do-stmts of the outer-most outer-shared- do-construct will permit not to refer to the same label, because shared-term-do-construct does not include outer-most outer- shared-do-construct. So the term "shared-term-do-construct" should be changed to "inner-share-do-construct and outer-shared-do-construct." DISCUSSION: There is a typographical error in the question - "8.1.4.2" should read "8.1.4.1.2". The following amplification of the question was provided at the August 2000 WG5 meeting: The present BNF does not preclude the following as a single construct: do 10 i=1,5 ! outer do 20 j=1,5 ! outer do 20 k=1,5 ! outer do 20 l=1,5 ! inner ... 20 continue ! shared ANSWER: Agreed. EDITS: [127:29.5] Replace "" by " and ". {The intention is to alter the second line of the second constraint following R833. The line numbering is awry in the F95 copy being used.} SUBMITTED BY: Japan HISTORY: 99-208 m150 Submitted 99-221 m150 Classified as Fortran 95 interpretation WG5-N1411 Aug-2000 Draft answer 02-131r1 m160 Passed unanimously by J3 meeting 03-197 m165 Passed by J3 letter ballot WG5-N1561 Request from WG5 to reconsider 03-238 m165 Passed by J3 meeting 04-417r1 m170 Passed by J3 letter ballot #8 05-180 m172 Passed by WG5 ballot N1617 ---------------------------------------------------------------------- ====================================================================== Part 5: Fortran 2003 Interpretation Requests ====================================================================== NUMBER: F03/0001 TITLE: Generic type-bound procedures KEYWORDS: generic, type-bound DEFECT TYPE: Interpretation STATUS: Passed by WG5 ballot 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 04-320r1 m169 Passed by J3 meeting 04-418r1 m170 Passed J3 letter ballot #9 05-180 m172 Passed by WG5 ballot N1617 ---------------------------------------------------------------------- NUMBER: F03/0002 TITLE: Component value for pointer components KEYWORDS: component, value, pointer DEFECT TYPE: Interpretation STATUS: Passed by WG5 ballot 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 04-321r1 m169 Passed by J3 meeting 04-418r1 m170 Passed J3 letter ballot #9 05-180 m172 Passed by WG5 ballot N1617 ---------------------------------------------------------------------- NUMBER: F03/0003 TITLE: Referencing deferred bindings KEYWORDS: Type-bound procedure, deferred binding DEFECT TYPE: Erratum STATUS: Edit subsumed by interp F03/0004 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 :: 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. An edit is supplied to clarify this situation. EDITS: See the edit in F03/0004. SUBMITTED BY: Richard Maine HISTORY: 04-322 m169 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 ---------------------------------------------------------------------- NUMBER: F03/0004 TITLE: Type-bound procedures and undefined association status KEYWORDS: Type-bound procedure, dynamic type DEFECT TYPE: Erratum STATUS: J3 consideration in progress 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. [266:24+] Insert new constraint "C1224a (R1219) If is a pointer, it shall be associated. If is allocatable, it shall be allocated." SUBMITTED BY: Richard Maine HISTORY: 04-323 m169 Submitted 04-323r1 m169 Passed by J3 meeting 04-418r1 m170 Passed J3 letter ballot #9 05-180 m172 Failed WG5 ballot N1617 ---------------------------------------------------------------------- NUMBER: F03/0005 TITLE: Argument association and the TARGET attribute KEYWORDS: argument, association, target, pointer DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot 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 04-330r1 m169 Passed by J3 meeting 04-418r1 m170 Passed J3 letter ballot #9 05-180 m172 Passed by WG5 ballot N1617 ---------------------------------------------------------------------- NUMBER: F03/0006 TITLE: Intrinsic assignment and allocatable components KEYWORDS: assignment, allocatable DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot 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 04-331r1 m169 Passed by J3 meeting 04-418r1 m170 Passed J3 letter ballot #9 05-180 m172 Passed by WG5 ballot N1617 ---------------------------------------------------------------------- NUMBER: F03/0007 TITLE: Finalization of structure constructors in specifications KEYWORDS: finalization, structure constructor, specification expression DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot 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; Passed by J3 meeting 04-418r1 m170 Passed J3 letter ballot #9 05-180 m172 Passed by WG5 ballot N1617 ---------------------------------------------------------------------- NUMBER: F03/0008 TITLE: Pointer assignment and arrays KEYWORDS: pointer assignment, array, data-ref DEFECT TYPE: Erratum STATUS: Passed by J3 letter 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 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 ---------------------------------------------------------------------- NUMBER: F03/0009 TITLE: VALUE attribute for passed-object dummy arguments KEYWORDS: VALUE, passed-object, dummy argument DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot 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 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 ---------------------------------------------------------------------- NUMBER: F03/0010 TITLE: Unlimited polymorphic pointer/allocatable dummy arguments KEYWORDS: polymorphism, POINTER, ALLOCATABLE, argument DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot 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; Passed by J3 meeting 04-418r1 m170 Passed J3 letter ballot #9 05-180 m172 Passed by WG5 ballot N1617 ---------------------------------------------------------------------- NUMBER: F03/0011 TITLE: Allocating objects of abstract types KEYWORDS: ALLOCATE, ABSTRACT DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot 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 04-336r2 m169 Passed by J3 meeting 04-418r1 m170 Passed J3 letter ballot #9 05-180 m172 Passed by WG5 ballot N1617 ---------------------------------------------------------------------- NUMBER: F03/0012 TITLE: Procedure pointers and the EXTERNAL attribute KEYWORDS: Procedure pointers, EXTERNAL DEFECT TYPE: Erratum STATUS: Passed by J3 letter 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 [7: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 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 ---------------------------------------------------------------------- NUMBER: F03/0013 TITLE: VALUE attribute for polymorphic dummy arguments KEYWORDS: VALUE, CLASS DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot 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; Passed by J3 meeting 04-418r1 m170 Passed J3 letter ballot #9 05-180 m172 Passed by WG5 ballot N1617 ---------------------------------------------------------------------- NUMBER: F03/0014 TITLE: Automatic arrays in interface bodies KEYWORDS: automatic array, interface body DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot 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; Passed by J3 meeting 04-418r1 m170 Passed by J3 letter ballot #9 with comment 05-180 m172 Passed by WG5 ballot N1617 ---------------------------------------------------------------------- NUMBER: F03/0015 TITLE: TARGET attribute for associate names KEYWORDS: TARGET, POINTER, ASSOCIATE DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot 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 04-366r1 m169 Passed by J3 meeting 04-418r1 m170 Passed by J3 letter ballot #9 05-180 m172 Passed by WG5 ballot N1617 ---------------------------------------------------------------------- NUMBER: F03/0016 TITLE: Invoking type-bound procedures via array objects KEYWORDS: elemental, type-bound procedure, NOPASS attribute DEFECT TYPE:Erratum STATUS: Passed by WG5 ballot 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; Passed by J3 meeting 04-418r1 m170 Passed by J3 letter ballot #9 05-180 m172 Passed by WG5 ballot N1617 ---------------------------------------------------------------------- NUMBER: F03/0017 TITLE: Dummy procedure pointers and PRESENT KEYWORDS: Dummy procedure pointers, PRESENT DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTION: Does the following program conform to the 2003 standard? procedure(real), pointer :: F => null() call s ( f ) contains subroutine S ( F ) procedure(real), optional, pointer :: F print *, present(f) end subroutine S end ANALYSIS: The second paragraph of 12.4.1.3 requires that if the dummy argument does not have the POINTER attribute and the actual argument does, the actual argument shall be associated. It is not clear in 13.7.91 whether the argument of PRESENT has or has not the POINTER attribute. ANSWER: The program conforms to the 2003 standard. An edit is supplied to remove any possibility of a contradictory reading of the relation between 12.4.1.3 and 13.7.91. EDITS: In the second paragraph of 12.4.1.3 [271:16] replace "an associated" by "a". At the end of that paragraph, insert a new sentence: "Except in references to intrinsic inquiry functions, if the actual argument is a pointer it shall be associated." SUBMITTED BY: Van Snyder HISTORY: 04-402 m170 Submitted 04-402r2 m170 Passed J3 meeting 05-146 m171 Failed J3 letter ballot #10 ---------------------------------------------------------------------- NUMBER: F03/0018 TITLE: Multiple identical specific procedures in type-bound generic interfaces KEYWORDS: Type-bound generics DEFECT TYPE: Clarification STATUS: Passed by J3 letter ballot QUESTION 1: Does the following program unit conform to the 2003 standard? module M type T contains procedure MyAdd generic :: operator(+) => myAdd end type T type X contains procedure, pass(b) :: MyAdd generic :: operator(+) => myAdd end type X contains integer function MyAdd ( A, B ) type(t), intent(in) :: A type(x), intent(in) :: B end function MyAdd end module M QUESTION 2: Does the following program unit conform to the 2003 standard? module M interface operator(+) procedure MyAdd end interface type T contains procedure MyAdd generic :: operator(+) => myAdd end type T contains integer function MyAdd ( A, B ) type(t), intent(in) :: A real, intent(in) :: B end function MyAdd end module M QUESTION 3: If the interface block and type definition are exchanged in QUESTION 2, does the program unit conform to the 2003 standard? ANALYSIS: The OPERATOR(+) bindings to the types T and X construct a single generic OPERATOR(+) interface that is a local entity of module M. They do not construct separate OPERATOR(+) generic interfaces that are separate local entities of the types. 16.2.3 (Restrictions on generic declarations) specifies that it "contains the rules that shall be satisfied by every pair of specific procedures that have the same generic identifier within a scoping unit." It is clear that if different functions with identical interfaces were bound to the types that they would be a "pair of specific procedures" and the resulting OPERATOR(+) interface would therefore be prohibited by 16.2.3. It is not clear whether the generic bindings bind separate specific procedures to the OPERATOR(+) generic, or only redundantly bind the same procedure. If the former, the program units are not standard conforming because they violate the provisions of 16.2.3. If the latter, they appear to be standard conforming. C1209 (in 12.3.2.1) prohibits a procedure to be bound to a generic interface more than once in a scoping unit, but only by way of a PROCEDURE statement in a generic interface block. There is nothing obviously equivalent in 4.5.4, nor anything that specifies that C1209 applies to generic bindings to types. It also does not apply between a generic interface block and a generic interface previously specified by a generic binding to a type (question 3), since the latter specific binding is accomplished by a conspiracy of a and a , not by a . ANSWER: The program units conform to the 2003 standard. Multiple bindings of the same procedure to a generic identifier using a in a type definition or by a type definition and a generic interface block do not bind a "pair of specific procedures" to the generic interface. Indeed, the following type definition is legal: type Z contains procedure :: MyAdd generic :: operator(+) => myAdd, operator(+) => myAdd end type Z EDITS: None. SUBMITTED BY: Van Snyder HISTORY: 04-405 m170 Submitted 04-405r1 m170 Passed by J3 meeting 05-146 m171 Passed J3 letter ballot #10 ---------------------------------------------------------------------- NUMBER: F03/0019 TITLE: Multiple identical specific procedures in generic interface blocks KEYWORDS: Type-bound generics DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION 1: Does the following program conform to the 2003 standard? program P interface X subroutine S ( A ) integer :: A end subroutine S procedure S end interface X end program P ANALYSIS: 16.2.3 (Restrictions on generic declarations) specifies that it "contains the rules that shall be satisfied by every pair of specific procedures that have the same generic identifier within a scoping unit." It is not clear whether the interface body and the procedure statement bind separate specific procedures to the generic identifier, or only redundantly bind the same procedure. If the former, the program is not standard conforming because it violates the provisions of 16.2.3. If the latter, it appears to be standard conforming. C1209 (in 12.3.2.1) prohibits a procedure to be bound to a generic interface more than once in a scoping unit, but only by way of a PROCEDURE statement in a generic interface block. There is a general rule that nothing shall be declared more than once. It appears that a procedure statement within an interface block is not a declaration: 5.1.2.6 (External attribute) specifies that the external attribute may be specified by an EXTERNAL statement, a or an interface body that is not in an abstract interface block. A procedure statement in an interface block apparently does not specify the external attribute. The procedure specified by the PROCEDURE statement in the above example is clearly an external procedure with an explicit interface, so it satisfies the requirements of C1207. ANSWER: The program conforms to the 2003 standard. Multiple bindings of the same procedure to a generic identifier using an interface body and a procedure statement do not bind a "pair of specific procedures" to the generic interface. Enforcing C1209 is more bother for processors than simply allowing multiple bindings of a particular specific procedure to a generic interface. It is unhelpful to users, and can be hurtful if the multiple bindings are specified by independent generic interfaces and brought into a scoping unit by use association from different modules. There was no equivalent constraint in Fortran 90, although something like it was added by interp F90/000007. The constraint added there applied only to a single specification part. It's not clear whether that meant "declared in the same specification part" or "accessible in the same specification part." When it was put into Fortran 95, it clearly applied to all accessible generic interfaces with a particular . Given the multitude of new ways to bring specific procedures into a generic interface in Fortran 2003, and that many of those ways allow a specific procedure to be bound to a generic identifier more than once, this conspicuously lonely constraint should be removed. Edits are supplied to correct this oversight. EDITS: Remove C1209 from 12.3.2.1. SUBMITTED BY: Van Snyder HISTORY: 04-406 m170 Submitted 04-406r1 m170 Passed J3 meeting 05-146 m171 Passed J3 letter ballot #10 ---------------------------------------------------------------------- NUMBER: F03/0020 TITLE: Kinds of intrinsic type parameters KEYWORDS: type parameter, kind, intrinsic type DEFECT TYPE: Erratum STATUS: Passed by J3 letter 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 Submitted 04-408r1 m170 Passed by J3 meeting 05-146 m171 Passed J3 letter ballot #10 ---------------------------------------------------------------------- NUMBER: F03/0021 TITLE: What kind of token is a stop code? KEYWORDS: STOP, token DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTION: The , when it is a string of s, does not appear to be specified by the standard to be any particular kind of token. Or indeed whether it is one token per or one per . The answer to these questions determines whether blanks are allowed, disallowed, or optional, in the middle of a STOP statement in free form. Consider the following statements: (1) STOP 123 (2) STOP123 (3) STOP 1 2 3 Which, if any, of these statements are standard-conforming? ANSWER: Only statement (1) was intended to be standard-conforming. Edits are supplied to clarify the situation. EDITS: [170:23] Replace with "<> " [170:24+] Insert new constraint "C834a (R850) The shall not have a and shall not have more than 5 s." [170:27] After "significant" insert "and all stop codes are permissible even if not representable in the default integer type" SUBMITTED BY: Malcolm Cohen HISTORY: 04-416 m170 Submitted - Passed by J3 meeting 05-146 m171 Failed J3 letter ballot #10 ---------------------------------------------------------------------- NUMBER: F03/0022 TITLE: Coexistence of IEEE and non-IEEE kinds KEYWORDS: IEEE, kind DEFECT TYPE: Interpretation STATUS: Passed by J3 meeting 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. The requirement that IEEE_OVERFLOW and IEEE_DIVIDE_BY_ZERO be supported for all kinds of real and complex data within that scoping unit was intentional. Support of these two flags means that the exceptions can be detected, either by a subsequent use of IEEE_GET_FLAG or by program termination (this is not under program control unless IEEE_SUPPORT_HALTING is true for those flags). Whether the flags are supported outside of a routine which uses IEEE_EXCEPTIONS or IEEE_ARITHMETIC is processor dependent. EDITS: None. SUBMITTED BY: Richard Maine HISTORY: 04-419 m170 Submitted 04-419r1 m170 Passed by J3 meeting 05-146 m171 Failed J3 letter ballot #10 ---------------------------------------------------------------------- NUMBER: F03/0023 TITLE: IEEE_SET/GET_UNDERFLOW_MODE KEYWORDS: IEEE, underflow mode DEFECT TYPE: Erratum STATUS: Passed by J3 letter 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 Submitted - Passed by J3 meeting 05-146 m171 Passed J3 letter ballot #10 ---------------------------------------------------------------------- NUMBER: F03/0024 TITLE: DEALLOCATE and array pointers KEYWORDS: DEALLOCATE, array pointers DEFECT TYPE: Interpretation STATUS: Passed by J3 meeting QUESTION: We currently say that one can deallocate an array pointer if it points to the "whole of an object that was created by allocation". What exactly does "whole" mean in this rule? Specifically, is the following allowed: REAL, DIMENSION(:), POINTER :: a, b ALLOCATE(a(1:10)) b=>a(1:10) DEALLOCATE(b) ANSWER: Yes, this is allowed, since "whole" means that b is ASSOCIATED with all elements of an array that was ALLOCATEd. In the given example, ASSOCIATED(a,b) is .TRUE., therefore either a or b can be used to DEALLOCATE the memory. EDITS: None SUBMITTED BY: Aleksandar Donev HISTORY: 04-378 m170 Submitted 04-378r1 m170 Passed by J3 meeting 05-146 m171 Failed J3 letter ballot #10 ---------------------------------------------------------------------- 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 J3 letter 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 Submitted 04-411r1 m170 Passed by J3 meeting 05-146 m171 Passed J3 letter ballot #10 ---------------------------------------------------------------------- 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 J3 letter 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 Submitted 04-412r1 m170 Passed by J3 meeting 05-146 m171 Passed J3 letter ballot #10 ---------------------------------------------------------------------- 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 J3 letter 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. [41:9] Remove "or". [41:9+] Add a new list item: "(3.5) in the 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 Submitted 04-413r1 m170 Passed by J3 meeting 05-146 m171 Passed J3 letter ballot #10 ---------------------------------------------------------------------- NUMBER: F03/0028 TITLE: Commas in complex namelist output KEYWORDS: Namelist, complex formatting, comma, semicolon DEFECT TYPE: Erratum STATUS: Passed by J3 meeting 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, or semicolon if the decimal edit mode is decimal," [244:29] Replace "comma" with "separator". [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 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 ---------------------------------------------------------------------- NUMBER: F03/0029 TITLE: Negative zero and intrinsic functions KEYWORDS: Negative zero, IEEE, intrinsic functions DEFECT TYPE: Erratum STATUS: Passed by J3 letter 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 Submitted - Passed by J3 meeting 05-146 m171 Passed J3 letter ballot #10 ---------------------------------------------------------------------- NUMBER: F03/0030 TITLE: IEEE divide by zero KEYWORDS: IEEE-754, divide-by-zero DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Is infinity / 0.0 a divide by zero exception? Is NaN / 0.0 a divide by zero exception? Fortran 2003 defines (in 14.2) infinity / zero and NaN / zero cases as IEEE_DIVIDE_BY_ZERO. IEEE-754 defines (in 6.1 and 6.2) those two as unexceptional. ANSWER: On an IEEE-conformant processor, these cases do not raise exceptions (see clauses 6.1 and 6.2 of IEEE-754). The definitions in 14.2 were intended to describe IEEE exceptions with sufficient latitude to allow use on near-IEEE and non-IEEE machines. However, the definition of IEEE_DIVIDE_BY_ZERO is not consistent with the IEEE International Standard. Furthermore, the definition of the IEEE_OVERFLOW flag is also not consistent with the IEEE standard, because this exception is not raised for operations on infinite operands. Edits are provided to fix these inconsistencies. EDITS: Page and line numbers refer to 04-007. [365:13-15] Clause 14.2, lines 3 and 5. After "assignment" add "with finite operands", twice. [365:18] Clause 14.2, line 8. Change "nonzero numerator" to "finite nonzero numerator". SUBMITTED BY: Fred Tydeman HISTORY: 05-109 m171 Submitted 05-109r1 m171 Revised to include IEEE_OVERFLOW, Passed by J3 meeting 05-170 m172 Passed J3 letter ballot #11 ---------------------------------------------------------------------- NUMBER: F03/0031 TITLE: IEEE invalid KEYWORDS: IEEE-754, invalid exception DEFECT TYPE: Interpretation STATUS: Passed by J3 letter ballot 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 05-110r1 m171 Passed by J3 meeting 05-170 m172 Passed J3 letter ballot #11 ---------------------------------------------------------------------- NUMBER: F03/0032 TITLE: Sign bit of IEEE NaN KEYWORDS: IEEE-754, NaN, sign bit, negative DEFECT TYPE: Interpretation STATUS: Passed by J3 letter ballot 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 05-111r1 m171 Passed by J3 meeting 05-170 m172 Passed J3 letter ballot #11 ---------------------------------------------------------------------- NUMBER: F03/0033 TITLE: IEEE_VALUE() KEYWORDS: IEEE-754, IEEE_VALUE DEFECT TYPE: Interpretation STATUS: Passed by J3 letter ballot 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 05-112r1 m171 Passed by J3 meeting 05-170 m172 Passed J3 letter ballot #11 ---------------------------------------------------------------------- NUMBER: F03/0034 TITLE: IEEE_LOGB() KEYWORDS: IEEE-754, logb() DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: What is logb(denormal)? Is it of the hardware representation, or is it as if the hardware had an unbounded exponent range? What is logb(NaN)? logb(-INF)? logb(+INF)? logb() should be defined as if the hardware representation had an unbounded exponent range. logb(NaN) should be the same NaN; shall be a NaN. logb(-INF) shall be +INF logb(+INF) shall be +INF 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." Case (i) of 14.10.12 correctly specifies that if the value of X is denormal, its unbiased exponent is returned; however, the note there is wrong in this case. An edit is supplied. For consistency with the IEEE International Standard, an edit is also supplied for the case where X is infinite. EDITS: Page and line numbers refer to 04-007. [376:15]. Subclause 14.10.12, Result Value, line 2. After "Note:" add "if X is normal,". [376:17+]. Subclause 14.10.12, Result Value. Add extra case: "Case (iii) If IEEE_SUPPORT_INF(X) is true and X is infinite, the result is +infinity." . SUBMITTED BY: Fred Tydeman HISTORY: 05-113 m171 Submitted 05-113r1 m171 Passed by J3 meeting 05-170 m172 Passed J3 letter ballot #11 ---------------------------------------------------------------------- NUMBER: F03/0035 TITLE: IEEE_NEXT_AFTER() KEYWORDS: IEEE-754, nextafter() DEFECT TYPE: Interpretation STATUS: Passed by J3 letter ballot 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 05-114r1 m171 Passed by J3 meeting 05-170 m172 Passed J3 letter ballot #11 ---------------------------------------------------------------------- NUMBER: F03/0036 TITLE: IEEE_REM() KEYWORDS: IEEE-754, remainder() DEFECT TYPE: Interpretation STATUS: Passed by J3 letter ballot 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 05-115r1 m171 Passed by J3 meeting 05-170 m172 Passed J3 letter ballot #11 ---------------------------------------------------------------------- NUMBER: F03/0037 TITLE: IEEE_RINT() KEYWORDS: IEEE-754, rint() DEFECT TYPE: Interpretation STATUS: Passed by J3 letter ballot 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 05-116r1 m171 Passed by J3 meeting 05-170 m172 Passed J3 letter ballot #11 ---------------------------------------------------------------------- NUMBER: F03/0038 TITLE: IEEE_SCALB() KEYWORDS: IEEE-754, scalb() DEFECT TYPE: Interpretation STATUS: Passed by J3 letter ballot 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 05-117r1 m171 Passed by J3 meeting 05-170 m172 Passed J3 letter ballot #11 ---------------------------------------------------------------------- NUMBER: F03/0039 TITLE: HYPOT() KEYWORDS: IEEE-754, hypot() DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: 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. We did not consider what would happen if one of the arguments is a NaN and have therefore edited the text slightly. DISCUSSION: In fact, if either X or Y is a NaN, the first executable statement will set HYPOT to a NaN without signaling an exception. The slower code in the IF construct will therefore not be executed and a NaN will be returned, which is consistent with the way NaNs are handled by intrinsic operators, see paragraph 3 of section 6.2 of the IEEE International Standard. EDITS: Page and line numbers refer to 04-007. [389:12]. Subclause 14.11, Note 14.17, final paragraph, line 2. Before "exception" add "overflow or underflow". [389:16+]. Subclause 14.11, Note 14.17, at the end of the final paragraph, add "This HYPOT function does not handle infinite arguments in the same way that the hypot function in the C International Standard does." SUBMITTED BY: Fred Tydeman HISTORY: 05-118 m171 Submitted 05-118r3 m171 Passed by J3 meeting 05-170 m172 Passed J3 letter ballot #11 ---------------------------------------------------------------------- NUMBER: F03/0040 TITLE: 2.0+2.0 and IEEE KEYWORDS: IEEE-754, accuracy, transformation DEFECT TYPE: Interpretation STATUS: Passed by J3 letter ballot 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 05-119r1 m171 Passed by J3 meeting 05-170 m172 Passed J3 letter ballot #11 ---------------------------------------------------------------------- NUMBER: F03/0041 TITLE: IEEE halting and exceptions KEYWORDS: IEEE-754, trapping, exception DEFECT TYPE: Interpretation STATUS: Passed by J3 letter ballot 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 05-120r1 m171 Passed by J3 meeting 05-170 m172 Passed J3 letter ballot #11 ---------------------------------------------------------------------- NUMBER: F03/0042 TITLE: IEEE funny values and Standard real generic instrinsic procedures KEYWORDS: IEEE-754, real math library DEFECT TYPE: Erratum STATUS: For consideration QUESTION: Is an infinite result from an infinite argument to a real math function exceptional (raises an exception)? Is a NaN result from a NaN argument to a real math function exceptional (raises an exception)? What are the results (value and exceptions) for the following (section 13.7.*) real math library functions [suggested results for most are included; no exception happens unless specified]: ABS(-0.0) returns +0.0 ABS(+/-infinity) returns +infinity ABS(NaN) returns a NaN ACOS(x), where |x|>1, returns a NaN and raises invalid ACOS(NaN) returns a NaN AINT(-0.0) returns -0.0 AINT(NaN) returns a NaN AINT(+infinity) returns +infinity AINT(-infinity) returns -infinity ANINT(-0.0) returns -0.0 ANINT(NaN) returns a NaN ANINT(+infinity) returns +infinity ANINT(-infinity) returns -infinity ASIN(x), where |x|>1, returns a NaN and raises invalid ASIN(NaN) returns a NaN ATAN(-0.0) returns -0.0 ATAN(+infinity) returns +pi/2 ATAN(-infinity) returns -pi/2 ATAN(NaN) returns a NaN ATAN2(NaN,x) returns a NaN ATAN2(y,NaN) returns a NaN ATAN2(+/-0.0, -0.0) returns +/-pi (and not raise invalid) ATAN2(+/-0.0, +0.0) returns +/-0.0 (and not raise invalid) ATAN2(+/-0.0, x) returns +/-pi for x < 0.0 ATAN2(+/-0.0, x) returns +/-0.0 for x > 0.0 ATAN2(y, +/-0.0) returns -pi/2 for y < 0.0 (and not raise divide by zero) ATAN2(y, +/-0.0) returns +pi/2 for y > 0.0 (and not raise divide by zero) ATAN2(+/-y, -infinity) returns +/-pi for finite y > 0.0 ATAN2(+/-y, +infinity) returns +/-0.0 for finite y < 0.0 ATAN2(+/-infinity, x) returns +/-pi/2 for finite x ATAN2(+/-infinity, -infinity) returns +/-3pi/4 (and not raise invalid) ATAN2(+/-infinity, +infinity) returns +/-pi/4 (and not raise invalid) CEILING(+/-infinity) returns +/-infinity CEILING(-0.0) returns -0.0 CEILING(NaN) returns a NaN COS(+/-0.0) returns 1 COS(NaN) returns a NaN COS(+/-infinity) returns a NaN and raises invalid COSH(+/-0.0) returns 1 COSH(NaN) returns a NaN COSH(+/-infinity) returns a +infinity DIM(NaN,y) returns a NaN DIM(x,NaN) returns a NaN DIM(+/-0.0, +/-0.0) returns a +0.0 DIM(+infinity, -infinity) returns a NaN and raises invalid DIM(+infinity, +infinity) returns +0.0 DIM(-infinity, -infinity) returns +0.0 DIM(-infinity, +infinity) returns +0.0 DPROD(NaN,y) returns a NaN DPROD(x,NaN) returns a NaN DPROD(+/-0.0, +/-infinity) returns a NaN and raises invalid DPROD(+/-infinity, +/-0.0) returns a NaN and raises invalid DPROD(+/-infinity, +/-infinity) returns an infinity with its sign being the XOR of the arguments, and raises no exceptions. DPROD(+/-0.0, +/-0.0) returns a zero with its sign being the XOR of the arguments, and raises no exceptions. EXP(NaN) returns a NaN EXP(+/-0.0) returns 1 EXP(-infinity) returns +0.0 EXP(+infinity) returns +infinity EXPONENT(+/-0.0) returns 0 [should be -HUGE(0)] and raises invalid EXPONENT(NaN) returns HUGE(0) and raises invalid EXPONENT(+/-INF) returns HUGE(0) and raises invalid EXPONENT(denormal) returns the value as if the number were normalized and the exponent range were unbounded If /e/ is not representable as a default integer, invalid is raised and sign(/e/)*HUGE(0) should be returned. FLOOR(NaN) returns a NaN FLOOR(-0.0) returns -0.0 FLOOR(+/-infinity) returns +/- infinity FRACTION(-0.0) returns -0.0 FRACTION(NaN) returns a NaN FRACTION(denormal) returns the value as if the number were normalized and the exponent range were unbounded FRACTION(+/-infinity) returns +/- infinity INT(NaN) returns an unspecified value and raises invalid INT(+/-infinity) returns an unspecified value and raises invalid INT(+/-large), where large cannot be represented as an integer, returns an unspecified value and raises invalid LOG(+/-0.0) returns -infinity and raises divide-by-zero LOG(NaN) returns a NaN LOG(1.0) returns +0.0 LOG(x), for x < 0, returns a NaN and raises invalid LOB(+infinity) returns +infinity LOG10(+/-0.0) returns -infinity and raises divide-by-zero LOG10(NaN) returns a NaN LOG10(1.0) returns +0.0 LOG10(x), for x < 0, returns a NaN and raises invalid LOG10(+infinity) returns +infinity MAX(NaN,NaN) returns a NaN MAX(NaN,y) returns y [some say it should be NaN] MAX(x,NaN) returns x [some say it should be NaN] MAX(-0.0,+0.0) returns +0.0 MAX(-0.0,-0.0) returns -0.0 MAX(+infinity,y) returns +infinity MAX(-infinity,y) returns y MIN(NaN,NaN) returns a NaN MIN(NaN,y) returns y [some say it should be NaN] MIN(x,NaN) returns x [some say it should be NaN] MIN(-0.0,+0.0) returns -0.0 MIN(-0.0,-0.0) returns -0.0 MIN(-infinity,y) returns -infinity MIN(+infinity,y) returns y MOD(NaN,y) returns a NaN MOD(x,NaN) returns a NaN MOD(+/-infinity,y) returns a NaN and raises invalid MOD(+/-infinity,+/-infinity) returns a NaN and raises invalid MOD(x,+/-0.0) returns a NaN and raises invalid MOD(+/-0.0,+/-0.0) returns a NaN and raises invalid MODULO(NaN,y) returns a NaN MODULO(x,NaN) returns a NaN MODULO(+/-infinity,y) returns a NaN and raises invalid MODULO(+/-infinity,+/-infinity) returns a NaN and raises invalid MODULO(x,+/-0.0) returns a NaN and raises invalid MODULO(+/-0.0,+/-0.0) returns a NaN and raises invalid NEAREST(NaN,y) returns a NaN NEAREST(x,NaN) returns a NaN NEAREST(x,+/-0.0) returns a NaN and raises invalid [why???] NEAREST(+infinity,+num) returns +infinity ??? NEAREST(+infinity,-num) returns +maximum finite number NEAREST(-infinity,+num) returns -maximum finite number NEAREST(-infinity,-num) returns -infinity ??? NINT(NaN) returns an unspecified value and raises invalid NINT(+/-infinity) returns an unspecified value and raises invalid NINT(+/-large), where large cannot be represented as an integer, returns an unspecified value and raises invalid RRSPACING(NaN) returns a NaN RRSPACING(+/-infinity) returns +/-infinity [differs from current F2003] RRSPACING(+/-0.0) returns +0.0 RRSPACING(+/-denormal) returns ??? SCALE(NaN,y) returns a NaN SCALE(+/-infinity,y) returns +/-infinity SCALE(-0.0,y) returns -0.0 SET_EXPONENT(NaN,y) returns a NaN SET_EXPONENT(+/-infinity,y) returns +/-infinity SET_EXPONENT(-0.0,y) returns -0.0 SET_EXPONENT(denormal,y) returns ??? SIGN(NaN,y), where 0 < y, returns the same NaN, but with the sign bit cleared. SIGN(NaN,y), where y < 0, returns the same NaN, but with the sign bit set. SIN(NaN) returns a NaN SIN(+/-infinity) returns a NaN and raises invalid SIN(-0.0) returns -0.0 SINH(NaN) returns a NaN SINH(+/-infinity) returns +/- infinity SINH(-0.0) returns -0.0 SPACING(NaN) returns a NaN SPACING(+/-infinity) returns +infinity SPACING(-0.0) returns TINY(+0.0) SPACING(denormal) returns TINY(+0.0) ??? SQRT(NaN) returns a NaN SQRT(+infinity) returns +infinity SQRT(-0.0) returns -0.0 SQRT(x), where x < 0.0, returns a NaN and raises invalid TAN(NaN) returns a NaN TAN(+/-infinity) returns a NaN and raises invalid TAN(-0.0) returns -0.0 TANH(NaN) returns a NaN TANH(+/-infinity) returns +/-1.0 TANH(-0.0) returns -0.0 13.7 [300:13-15] incorrectly requires an infinite result or a NaN result to always signal some IEEE exception. Consider changing [300:13] "infinite result" to "infinite result (from finite arguments)". Reason: IEEE-754 mathematical operations on infinity that produce an infinity are unexceptional. Consider changing [300:14] "NaN result" to "NaN result (from non-NaN arguments)". Reason: IEEE-754 mathematical operations on quiet NaN operands that produce a quiet NaN result are unexceptional. Consider adding to 13.7 [300:15+] something along the lines of: "Unless specified otherwise, a math function with NaN argument(s) shall return a NaN, which should be one of the NaN arguments." This allows not having to specify the results for each specific math function. Consider adding the above suggested cases to each of the 13.7.* functions, perhaps, with a bold face IEEE sub-heading. ANSWER: The penultimate sentences of 13.7 was intended for the case where all arguments on entry have normal or denormal values and edits are supplied to correct this. To specify the results of all the intrinsics for non-normal values is beyond the scope of an interpretation. Perhaps this should be considered for an extension that is adopted for the next revision of the standard. Meanwhile, guidance is provided by the second and third paragraphs of 14.8, which 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. " EDITS: Page and line numbers refer to 04-007. [300:13&14] Subclause 13.7. In the penultimate sentence, replace "If" by "If the values of all input arguments are normal or denormal and" and replace "if" by "if the values of all input arguments are normal or denormal and" SUBMITTED BY: Fred Tydeman HISTORY: 05-121 m171 Submitted ---------------------------------------------------------------------- NUMBER: F03/0043 TITLE: Passed-object arguments and procedure pointer components KEYWORDS: DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot 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" SUBMITTED BY: Bill Long HISTORY: 05-106 m171 Submitted, passed by J3 meeting 05-170 m172 Passed J3 letter ballot #11 ---------------------------------------------------------------------- NUMBER: F03/0044 TITLE: Implicit interfaces and conflicting references KEYWORDS: implicit interface, procedure pointer, dummy procedure, procedure reference DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot 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 05-127r3 m171 Passed by J3 meeting 05-170 m172 Passed J3 letter ballot #11 ---------------------------------------------------------------------- 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 J3 letter 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. EDITS: All edits refer to 04-007. [80:9] Before "a type", insert "a finalizable type or". SUBMITTED BY: Rob James HISTORY: 05-136 m171 Submitted, passed by J3 meeting 05-170 m172 Passed J3 letter ballot #11 ---------------------------------------------------------------------- NUMBER: F03/0046 TITLE: Unlimited polymorphic pointers in common blocks KEYWORDS: Unlimited polymorphic pointer, common block DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Consider the following program: PROGRAM foo COMMON /blk1/ x CLASS(*), POINTER :: x CALL sub END PROGRAM SUBROUTINE sub COMMON /blk1/ x CLASS(*), POINTER :: x END SUBROUTINE There appears to be nothing prohibiting an unlimited polymorphic pointer from appearing in a common block, but the following appears in Fortran 2003 at [100:10]: A data pointer shall be storage associated only with data pointers of the same type and rank. And at [75:23-25]: 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. It appears that it is not standard conforming to have an unlimited polymorphic pointer that is storage associated with anything else, including another unlimited polymorphic pointer. So, while it is apparently standard-conforming to have an unlimited polymorphic pointer in a common block, a common block with the same name cannot be accessed in any other scoping unit. This interpretation also seems to be supported by parts of section 16 of the standard. At [416:7-24]: In a storage association context ... (8) A pointer occupies a single unspecified storage unit that is different from that of any nonpointer object and is different for each combination of type, type parameters, and rank. At [417:12-13]: All scoping units that access named common blocks with the same name shall specify an identical sequence of storage units. And at [417:14-17]: For any two blank common blocks, the initial sequence of storage units of the longer blank common block shall be identical to the sequence of storage units of the shorter common block. If two blank common blocks are the same length, they shall have the same sequence of storage units. Was it intended that an unlimited polymorphic pointer should be allowed in a common block? If yes, then was it intended that such a common block should be accessible in more than one scoping unit? ANSWER: No. An edit is provided to correct this oversight. EDITS: All edits refer to 04-007. [98:20] Before "an allocatable variable", insert "a polymorphic pointer,". SUBMITTED BY: Rob James HISTORY: 05-137 m171 Submitted, passed by J3 meeting 05-170 m172 Passed J3 letter ballot #11 ---------------------------------------------------------------------- NUMBER: F03/0047 TITLE: Polymorphic arguments to intrinsic procedures KEYWORDS: polymorphism, intrinsic procedures DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: The descriptions of the intrinsic procedures often use the term "type" without qualification. It is unclear whether they mean "declared type" or "dynamic type". If they mean "dynamic type", then this would appear to allow unlimited polymorphic arguments to intrinsic procedures like ABS and SIN. Resolution of generic intrinsic procedures in this case would create an undue (and likely unintended) burden on the processor, and the declared type of the result of such a function call would be unclear as well. Question 1: Are the arguments of the intrinsic functions ALLOCATED, ASSOCIATED, LBOUND, SHAPE, SIZE, and UBOUND permitted to be polymorphic? Question 2: (a) Is the ARRAY argument of the intrinsic function CSHIFT permitted to be polymorphic? If so: (b) If the argument is polymorphic, is the result polymorphic? What are the declared and dynamic types of the result? Question 3: (a) Are the ARRAY and BOUNDARY arguments of the intrinsic function EOSHIFT permitted to be polymorphic? If so: (b) If one of these arguments is polymorphic, then must the other be polymorphic? (c) Do the requirements on their types refer to their declared types or dynamic types? (d) If either argument is polymorphic, is the result polymorphic? What are the declared and dynamic types of the result? Question 4: (a) Are the A and MOLD arguments of the intrinsic function EXTENDS_TYPE_OF permitted to be polymorphic? If so: (b) If one of these arguments is polymorphic, must the other be polymorphic? (c) Do the requirements on their types refer to their declared types or dynamic types? Question 5: (a) Are the TSOURCE and FSOURCE arguments of the intrinsic function MERGE permitted to be polymorphic? If so: (b) If one of these arguments is polymorphic, must the other be polymorphic? (c) Do the requirements on the types of the arguments refer to their declared types or dynamic types? (d) If either argument is polymorphic, is the result polymorphic? What are the declared and dynamic types of the result? Question 6: Are the FROM and TO arguments of the intrinsic function MOVE_ALLOC permitted to be polymorphic? Question 7: (a) Are the ARRAY and VECTOR arguments of the intrinsic function PACK permitted to be polymorphic? If so: (b) If one of these arguments is polymorphic, must the other be polymorphic? (c) Do the requirements on the types of the arguments refer to their declared types or dynamic types? (d) If either argument is polymorphic, is the result polymorphic? What are the declared and dynamic types of the result? Question 8: (a) Are the SOURCE and PAD arguments of the intrinsic function RESHAPE permitted to be polymorphic? If so: (b) If one of these arguments is polymorphic, must the other be polymorphic? (c) Do the requirements on the types of the arguments refer to their declared types or dynamic types? (d) If either argument is polymorphic, is the result polymorphic? What are the declared and dynamic types of the result? Question 9: (a) Are the A and B arguments of the intrinsic function SAME_TYPE_AS permitted to be polymorphic? If so: (b) If one of these arguments is polymorphic, must the other be polymorphic? (c) Do the requirements on their types refer to their declared types or dynamic types? Question 10: (a) Is the SOURCE argument of the intrinsic function SPREAD permitted to be polymorphic? If so: (b) If the argument is polymorphic, is the result polymorphic? What are the declared and dynamic types of the result? Question 11: (a) Is the SOURCE argument of the intrinsic function TRANSFER permitted to be polymorphic? (b) Is the MOLD argument of the intrinsic function TRANSFER permitted to be polymorphic? If the answer to (b) is yes: (c) If the MOLD argument is polymorphic, is the result polymorphic? What are the declared and dynamic types of the result? Question 12: (a) Is the MATRIX argument of the intrinsic function TRANSPOSE permitted to be polymorphic? If so: (b) If the argument is polymorphic, is the result polymorphic? What are the declared and dynamic types of the result? Question 13: (a) Are the VECTOR and FIELD arguments of the intrinsic function UNPACK permitted to be polymorphic? If so: (b) If one of these arguments is polymorphic, must the other be polymorphic? (c) Do the requirements on the types of the arguments refer to their declared types or dynamic types? (d) If either argument is polymorphic, is the result polymorphic? What are the declared and dynamic types of the result? Question 14: Are any of the other arguments of any intrinsic procedure permitted to be polymorphic? ANSWER: Answer 1: Yes. Answer 2: (a) Yes. (b) In this case, the result is polymorphic. If the argument is unlimited polymorphic, then the result is unlimited polymorphic and its dynamic type is the same as that of the argument. Otherwise, the declared and dynamic types of the result are the same as those of the argument. Answer 3: (a) Yes. (b) Yes. (c) The requirements apply to both the declared type and the dynamic type. (d) In this case, the result is polymorphic. If the arguments are unlimited polymorphic, then the result is unlimited polymorphic and its dynamic type is the same as that of the arguments. Otherwise, the declared and dynamic types of the result are the same as those of the arguments. Answer 4: (a) Yes. (b) No. (c) The requirements refer to the dynamic type. Answer 5: (a) Yes. (b) Yes. (c) The requirements refer to both the declared type and the dynamic type. (d) In this case, the result is polymorphic. If the arguments are unlimited polymorphic, then the result is unlimited polymorphic and its dynamic type is the same as that of the arguments. Otherwise, the declared and dynamic types of the result are the same as those of the arguments. Answer 6: Yes. Answer 7: (a) Yes. (b) Yes. (c) The requirements refer to both the declared type and the dynamic type. (d) In this case, the result is polymorphic. If the arguments are unlimited polymorphic, then the result is unlimited polymorphic and its dynamic type is the same as that of the arguments. Otherwise, the declared and dynamic types of the result are the same as those of the arguments. Answer 8: (a) Yes. (b) Yes. (c) The requirements refer to both the declared type and the dynamic type. (d) In this case, the result is polymorphic. If the arguments are unlimited polymorphic, then the result is unlimited polymorphic and its dynamic type is the same as that of the arguments. Otherwise, the declared and dynamic types of the result are the same as those of the arguments. Answer 9: (a) Yes. (b) No. (c) The requirements refer to the dynamic type. Answer 10: (a) Yes. (b) In this case, the result is polymorphic. If the argument is unlimited polymorphic, then the result is unlimited polymorphic and its dynamic type is the same as that of the argument. Otherwise, the declared and dynamic types of the result are the same as those of the argument. Answer 11: (a) Yes. (b) No. (c) N/A. Answer 12: (a) Yes. (b) In this case, the result is polymorphic. If the argument is unlimited polymorphic, then the result is unlimited polymorphic and its dynamic type is the same as that of the argument. Otherwise, the declared and dynamic types of the result are the same as those of the argument. Answer 13: (a) Yes. (b) Yes. (c) The requirements refer to both the declared type and the dynamic type. (d) In this case, the result is polymorphic. If the arguments are unlimited polymorphic, then the result is unlimited polymorphic and its dynamic type is the same as that of the arguments. Otherwise, the declared and dynamic types of the result are the same as those of the arguments. Answer 14: No. EDITS: [292:18+] Insert a new subclause 13.2 and re-number subsequent subclauses: 13.2 Polymorphic intrinsic function arguments and results Table 13.1 specifies the intrinsic functions that are allowed to have polymorphic arguments, and the arguments that are allowed to be polymorphic. Table 13.1: Polymorphic intrinsic function arguments --------------------------------------------------------------- | Function name | Arguments permitted to be polymorphic | =============================================================== | ALLOCATED | ARRAY, SCALAR | | ASSOCIATED | POINTER, TARGET | | CSHIFT | ARRAY | | EOSHIFT | ARRAY, BOUNDARY | | EXTENDS_TYPE_OF | A, MOLD | | LBOUND | ARRAY | | MERGE | TSOURCE, FSOURCE | | MOVE_ALLOC | FROM, TO | | PACK | ARRAY, VECTOR | | RESHAPE | SOURCE, PAD | | SAME_TYPE_AS | A, B | | SHAPE | SOURCE | | SIZE | ARRAY | | SPREAD | SOURCE | | TRANSFER | SOURCE | | TRANSPOSE | MATRIX | | UBOUND | ARRAY | | UNPACK | VECTOR, FIELD | =============================================================== The intrinsic functions shown in table 13.2 have a polymorphic result if and only if the specified argument is polymorphic. Where the result is specified to have the same type and type parameters as the argument specified in table 13.2, the result has the same dynamic type as the specified argument. If the specified argument is unlimited polymorphic the result is unlimited polymorphic; otherwise it has the same declared type as the specified argument. If another argument is required to have the same type as the specified argument, it shall be polymorphic if and only if the specified argument is polymorphic, and have the same dynamic type as the specified argument. If the specified argument is unlimited polymorphic, the other argument shall also be unlimited polymorphic; otherwise, it shall have the same declared type as the specified argument. Table 13.2: Polymorphic intrinsic function results ------------------------------------------------ | Function name | Argument that determines | | | result characteristics | ------------------------------------------------ | CSHIFT | ARRAY | | EOSHIFT | ARRAY | | MERGE | TSOURCE | | PACK | ARRAY | | RESHAPE | SOURCE | | SPREAD | SOURCE | | TRANSPOSE | MATRIX | | UNPACK | VECTOR | ================================================ SUBMITTED BY: Rob James HISTORY: 05-138 m171 Submitted - contained the questions/answers 05-138r1 m171 Contained the edits, passed by J3 meeting 05-170 m172 Passed J3 letter ballot #11 ---------------------------------------------------------------------- NUMBER: F03/0048 TITLE: Control edit descriptors in UDDTIO KEYWORDS: Control edit descriptor DEFECT TYPE: Interpretation STATUS: Passed by J3 meeting QUESTION: Consider the following program: MODULE m TYPE t INTEGER :: i = 0 CONTAINS PROCEDURE, PRIVATE :: pwf GENERIC :: WRITE(FORMATTED) => pwf END TYPE CONTAINS RECURSIVE SUBROUTINE pwf(dtv, unit, iotype, vlist, iostat, iomsg) CLASS(t), 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 WRITE(unit, '(i1, /)') dtv%i WRITE(unit, '(t1, a2)') 'AB' END SUBROUTINE pwf END MODULE PROGRAM foo USE m IMPLICIT NONE TYPE(t) :: a a%i = 3 PRINT *, 'xyz', a end program 9.5.3.7.2 states: A record positioning edit descriptor, such as TL and TR, used on unit by a child data transfer statement shall not cause the record position to be positioned before the record position at the time the user-defined derived-type input/output procedure was invoked. The term "record position" is used, but it doesn't appear to be defined anywhere. Depending on the interpretation, the above program might be standard-conforming, or it might not be. If "record position" is taken to mean "the position within the current record", regardless of which record is the current record, then the record position at the beginning of the UDDTIO procedure is before the fourth character of the record. The first child data transfer statement begins a new record, and the second child data transfer statement writes to the first character of the new record. This would be before the "record position" at the time the UDDTIO procedure was invoked, and the program would not be standard-conforming. If "record position" is taken to mean a combination of the record and the position within that record (essentially making it mean the same thing as "file position"), then the above program is standard- conforming, since the control edit descriptor doesn't cause the file to be positioned before the record position when the UDDTIO procedure was invoked. What is the meaning of "record position", and is the above program standard-conforming? ANSWER: The term "record position" means the same as the term "file position". The program is standard-conforming. The PRINT statement prints xyz.3 AB where the first record starts with a space and the "." represents 0 or more spaces. EDITS: None SUBMITTED BY: Rob James HISTORY: 05-139 m171 Submitted 05-139r1 m171 Passed by J3 meeting 05-170 m172 Failed J3 letter ballot #11 ---------------------------------------------------------------------- NUMBER: F03/0049 TITLE: Separators in list-directed output involving UDDTIO KEYWORDS: list-directed output, separators, UDDTIO DEFECT TYPE: Interpretation STATUS: Passed by J3 meeting 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? ANSWER: 1) No. It is the intent of the standard 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 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 I/O, 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. EDITS: None SUBMITTED BY: Rob James HISTORY: 05-140 m171 Submitted 05-140r1 m171 Passed by J3 meeting 05-170 m172 Failed J3 letter ballot #11 ---------------------------------------------------------------------- NUMBER: F03/0050 TITLE: Questions about internal files KEYWORDS: internal file, data transfer DEFECT TYPE: Interpretation STATUS: J3 consideration in progress QUESTION: Question 1: Fortran 2003 does not seem to prohibit this kind of recursive internal I/O. 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 I/O. 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: TBD. EDITS: TBD. SUBMITTED BY: Rob James HISTORY: 05-141 m171 Submitted ---------------------------------------------------------------------- NUMBER: F03/0051 TITLE: Repeat specifiers and UDDTIO KEYWORDS: repeat specifier, POS=, UDDTIO DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTION: Consider the following program: MODULE m TYPE t INTEGER :: i INTEGER :: j END TYPE INTEGER :: ipos INTERFACE READ(FORMATTED) MODULE PROCEDURE formattedReadT END INTERFACE CONTAINS SUBROUTINE formattedReadT (dtv, unit, iotype, vlist, iostat, iomsg) CLASS(T), INTENT(INOUT) :: dtv INTEGER, INTENT(IN) :: unit CHARACTER(*), INTENT(IN) :: iotype INTEGER, INTENT(IN) :: vlist(:) INTEGER, INTENT(OUT) :: iostat CHARACTER(*), INTENT(INOUT) :: iomsg READ(unit, *) dtv%i INQUIRE(unit, POS=ipos) READ(unit, *) dtv%j END SUBROUTINE END MODULE PROGRAM foo USE m TYPE(t) :: a OPEN(10, FILE='file.txt', ACCESS='stream', FORM='formatted') WRITE(10, '(A)') '2*3 5' REWIND(10) READ(10, *) a PRINT *, a%i, a%j, ipos END PROGRAM 10.9 of Fortran 2003 states that the r*c form of list-directed input is equivalent to r occurrences of c. So, when the read is performed, it is as if the input record contains two occurrences of the number 3. The first child read statement reads the first 3, and does not advance the file position to the next record (because it is a child data transfer statement). It appears that the second read statement should read the second 3. But the file position between the child read statements is unclear. What does the above program print? ANSWER: The standard does not specify the behavior of a processor when a list directed input record contains a r*c constant, and that entire set of input values is not completely consumed by one list directed input statement. In particular, the file position for such an input file when the processor is in the middle of consuming an r*c value, and a child input statement is invoked, is not defined. This was an oversight. Edits are supplied to prohibit r*c constants is this case. EDITS: [239:18] insert this paragraph before the paragraph that starts on [239:18] (just after note 10.28) "When a list item in a list directed input statement consumes the first value of an constant, that input statement shall consume all values of that constant before causing any child input statement to be invoked and before terminating if a parent input statement is active." SUBMITTED BY: Rob James HISTORY: 05-142 m171 Submitted 05-142r2 m171 Passed by J3 meeting 05-170 m172 Failed J3 letter ballot #11 ---------------------------------------------------------------------- NUMBER: F03/0052 TITLE: ADVANCE= specifier in child data transfer statements KEYWORDS: ADVANCE=, UDDTIO, data transfer DEFECT TYPE: Interpretation STATUS: Passed by J3 letter ballot 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 05-143r1 m171 Passed by J3 meeting 05-170 m172 Passed J3 letter ballot #11 ---------------------------------------------------------------------- NUMBER: F03/0053 TITLE: The BIND attribute for C_PTR and C_FUNPTR KEYWORDS: BIND attribute, C_PTR, C_FUNPTR, private components DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: 1. Do the derived types C_PTR and C_FUNPTR have the BIND attribute? This affects whether an object of one of these types is permitted directly in COMMON. C589, p. 98 states "If a common-block-object is of a derived type, it shall be a sequence type (4.5.1) or a type with the BIND attribute and it shall have no default initialization." It also affects whether the types are extensible. 4.5.6 states "A nonsequence derived type that does not have the BIND attribute is an extensible type." 2. 15.2.2 states that C_PTR and C_FUNPTR are derived types with private components. Are user-defined derived types with the BIND attribute permitted to have private components? ANSWER: 1. Yes, it was intended that these types have the BIND attribute. An edit makes this clear. 2. A user-defined derived type with the BIND attribute is permitted to have private components. DISCUSSION: 1. It was intended that the behaviour of these types be similar to that of user-declared derived types in all respects except that they interoperate with C pointer types rather than C struct types. As well as the two cases cited in the question, there are special conditions in a pointer assignment statement (7.4.2) if either the pointer or the target has the BIND attribute. Also, there is a restriction on types with the BIND attribute in a SELECT TYPE statement (8.1.5). 2. The rules for the interoperability of a C struct type with a Fortran derived type are less restrictive than the rules in 4.5.1.3 that determine whether two separately declared Fortran types, both with the BIND attribute, are the same. For the types to be the same, the names of corresponding components must agree and all components must be public. It follows that two types may be different although they both interoperate with the same C struct type. EDITS: Page and line numbers refer to 04-007. [397:3] Subclause 15.2.2. At the end of the first paragraph add "Each has the BIND attribute but is not interoperable with any C struct type." SUBMITTED BY: John Reid HISTORY: 05-151 m171 Passed by J3 meeting 05-170 m172 Passed J3 letter ballot #11 ---------------------------------------------------------------------- NUMBER: F03/0054 TITLE: Denormal inputs to EXPONENT, FRACTION, and SET_EXPONENT KEYWORDS: denormal, intrinsic, EXPONENT, FRACTION, SET_EXPONENT DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot 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 Passed by J3 meeting 05-170 m172 Passed J3 letter ballot #11 ---------------------------------------------------------------------- NUMBER: F03/0055 TITLE: Denormal inputs to SPACING and RRSPACING KEYWORDS: denormal, intrinsic, SPACING, RRSPACING DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot 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 Passed by J3 meeting 05-170 m172 Passed J3 letter ballot #11 ----------------------------------------------------------------------