ISO/IEC JTC1/SC22/WG5 N1722 WG5 letter ballot 5 on Fortran 2003 interpretations John Reid, 6 March 2008 This is the fifth set of draft interpretations for Fortran 2003. They have all been approved in a J3 letter ballot. The rules we operate on say: 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. The following Fortran 2003 interpretations are being balloted: Yes No Number Title --- --- F03/0003 Referencing deferred bindings --- --- F03/0004 Type-bound procedures and undefined association status --- --- F03/0079 Value of decimal exponent for a real zero value --- --- F03/0080 Formatted output of a negative real zero value --- --- F03/0100 Error in field width for special cases of signed INFINITY output --- --- F03/0104 Deallocation and finalization of bounds-remapped pointers --- --- F03/0106 Inquire by unit inconsistencies --- --- F03/0107 Are the IEEE_* elemental routines required --- --- F03/0108 Is IEEE_SUPPORT_NAN consistent with the other IEEE_SUPPORT functions The text of these interpretations is attached. Each interpretation starts with a row of "-"s. Please mark the above -Y- in the Yes column for "yes", -C- in the Yes column for "yes with comment", or -N- in the No column for a "no" answer {be sure to include your reasons with "no"} and send only the above text {not this entire mail mail message} to sc22wg5@open-std.org by 8 a.m (UK time) on Monday, 7 April 2008, in order to be counted. Thanks, John. ====================================================================== ---------------------------------------------------------------------- NUMBER: F03/0003 TITLE: Referencing deferred bindings KEYWORDS: Type-bound procedure, deferred binding DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: I thought that the intent was that it would be impossible to reference a deferred binding. However, it doesn't appear to me that this intent was achieved. Consider the following program (Sorry, but I don't have any compilers up to syntax-checking this). module defer type, abstract :: t contains procedure (sub), nopass, deferred :: deferred_proc end type t type, extends(t) :: t2 contains procedure, nopass :: deferred_proc => sub2 end type t2 contains subroutine sub write (*,*) 'Hello.' end subroutine sub subroutine sub2 write (*,*) 'Goodbye.' end subroutine sub2 end module defer program p use defer class(t), pointer :: x nullify(x) call x%deferred_proc end program p Is this a valid program? If not, what restriction of the standard does it violate? Note that x%deferred_proc does not require the value of x (4.5.7) and thus is not a reference to x (2.5.6). Therefore, [83:23-24] does not prohibit this. Nor is it clear that there is an intent to prohibit invocation of type-bound procedures for disassociated pointer objects; except in the case of deferred bindings, this seems well-defined and potentially useful. Because x is disassociated, its dynamic type is the same as its declared type, thus making the interpretation of x%nondeferred_proc reasonably clear. ANSWER: No, this was not intended to be a valid program. A type-bound procedure may not be invoked through an undefined pointer, a disassociated pointer, or an unallocated allocatable variable. An edit is supplied to clarify this situation. The same answer and edit also apply to F03/0004. EDITS: Insert after [04-007: 266: 24] ([07-007r3: 309: 11]): "The shall not be an undefined pointer, a disassociated pointer, or an unallocated allocatable variable." Note: this is the same edit as interp F03/0004. SUBMITTED BY: Richard Maine HISTORY: 04-322 m169 F03/0003 Submitted 04-322r1 m169 Passed by J3 meeting 04-418r1 m170 Subsumed by interp F03/0004 05-180 m172 Failed WG5 ballot N1617 - the edit is subsumed by F03/0004 07-280 m182 Revised 07-280r1 m182 Passed by J3 meeting 08-133r2 m183 Passed by letter ballot #15 08-101 ---------------------------------------------------------------------- NUMBER: F03/0004 TITLE: Type-bound procedures and undefined association status KEYWORDS: Type-bound procedure, dynamic type DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: It appears that the dynamic type is undefined for a pointer with undefined association status. This impacts type-bound procedures. Consider the following program. module undefined type :: t contains procedure, nopass :: nondeferred_proc => sub end type t type, extends(t) :: t2 contains procedure, nopass :: nondeferred_proc => sub2 end type t2 contains subroutine sub write (*,*) 'Hello.' end subroutine sub subroutine sub2 write (*,*) 'Goodbye.' end subroutine sub2 end module undefined program p use undefined class(t), pointer :: x call x%nondeferred_proc end program p Is this a valid program? If not, what restriction of the standard does it violate? If so, what does it print. Note that x%nondeferred_proc does not require the value of x (4.5.7) and thus is not a reference to x (2.5.6). Therefore, [83:23-24] does not prohibit this. If x were disassociated, its dynamic type would be t and the interpretation of this would be reasonably clear. However, the standard does not appear to specify the dynamic type of x when its association status is undefined. Nor can I find any prohibition that applies to this case. ANSWER: No, the program is not valid, because the standard does not establish an interpretation of it. An edit is supplied to clarify this. Furthermore, the case with a disassociated pointer was not intended to be valid. An edit is supplied to correct this oversight. DISCUSSION: Access to object-bound procedures (a.k.a. procedure pointer components) always require there to be an object. Access to type-bound procedures of an object was intended to require this too, but the effect of the NOPASS attribute on this was overlooked. EDITS: All edits refer to 04-007. Insert after [266:24]: "The shall not be an undefined pointer, a disassociated pointer, or an unallocated allocatable variable." Note: this is the same edit as interp F03/0003. SUBMITTED BY: Richard Maine HISTORY: 04-323 m169 F03/0004 Submitted 04-323r1 m169 Passed by J3 meeting 04-418r1 m170 Passed J3 letter ballot #9 05-180 m172 Failed WG5 ballot N1617 07-337 m182 Passed by J3 meeting 08-133r2 m183 Passed by letter ballot #15 08-101 ---------------------------------------------------------------------- NUMBER: F03/0079 TITLE: Value of decimal exponent for a real zero value KEYWORDS: Data edit descriptors, Numeric editing, decimal exponent, zero value DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: In formatted output, what is the value of the decimal exponent produced for a real zero value under the D, E, EN, ES, and G edit descriptors? ANSWER: In such a case, the decimal exponent should have the value zero whether or not a nonzero scale factor is in effect. Edits are supplied to make this clear. DISCUSSION: The Fortran 2003 standard does not specify what the value of the decimal exponent of a real zero value should be under formatted output. Every implementation of which Sun is aware uses the value zero for the decimal exponent unless a nonzero scale factor is in effect. Different implementations format real zeros differently under nonzero scale factors, but the difference is mainly in the form of the mantissa and not the exponent. EDITS: [227:15+] At the end of the numbered list in 10.6.1 "Numeric editing", add: "(7) On output of a real zero value, the digits in the exponent field shall all be zero." SUBMITTED BY: Michael Ingrassia HISTORY: 06-125 m175 F03/0079 Submitted 07-281r2 m182 Passed by J3 meeting 08-133r2 m183 Passed by letter ballot #15 08-101 ---------------------------------------------------------------------- NUMBER: F03/0080 TITLE: Formatted output of a negative real zero value KEYWORDS: formatted output, negative zero, IEEE DEFECT TYPE: Interpretation STATUS: Passed by J3 letter ballot QUESTION: Suppose a Fortran processor's representation of the real zero value is signed. When a negative real zero value is written using formatted output, does the Fortran 2003 standard require the representation of the zero value in the output field to be prefixed with a minus sign? ANSWER: Yes, the negative sign is required to appear in formatted output of a negative zero value. In subclause 10.6.1, list item (3) at [227:3-4] says "The representation of a negative internal value in the field shall be prefixed with a minus sign." For a processor that distinguishes between positive and negative zero, there is no exemption for output at [38:1-6]. For the case of IEEE reals, the IEEE_IS_NEGATIVE function at [375:25] explicitly says that -0.0 is "negative". EDITS: none. SUBMITTED BY: Michael Ingrassia HISTORY: 06-126 m175 F03/0080 Submitted 07-282r1 m182 Passed by J3 meeting 08-133r2 m183 Passed by letter ballot #15 08-101 ---------------------------------------------------------------------- NUMBER: F03/0100 TITLE: Error in field width for special cases of signed INFINITY output KEYWORDS: formatted output, signed infinity DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTION: Is there an error in the description for the output of a IEEE infinity with a sign and a field width of 3 or 8? 228:36-37 describes the output for an IEEE infinity and special cases field widths of 3 and 8. But, the special casing doesn't consider the possibility of a plus or minus sign in the field. A signed infinity should be special cased for field widths of 9 and 4. The current text also fails to take into account the case of = 0, for both Infinity and NaN values. ANSWER: Yes, there is an error in the special cases. Edits are provided to correctly describe the required field widths for signed infinities. An edit is also provided to repair the description of the output of NaN values. EDITS: [228:36-37] In the paragraph beginning "For an internal value that is an IEEE infinity." in 10.6.1.2.1 "F editing" replace the final sentence with: "The minimum field width required for output of the form 'Inf' is 3 if no sign is produced, and 4 otherwise. If is greater than zero but less than the minimum required, the field is filled with asterisks. The minimum field width for output of the form 'Infinity' is 8 if no sign is produced and 9 otherwise. If is zero or is less than the mimimum required but large enough to produce the form 'Inf', the form 'Inf' is output." [229:2] In the paragraph in 10.6.1.2.1 "F editing" covering the output of NaN values, replace the last sentence "If ... asterisks." with "If is greater than zero and less than 3, the field is filled with asterisks. If is zero, the output field is 'NaN'.". SUBMITTED BY: Dick Hendrickson HISTORY: 07-271 m181 F03/0100 Submitted 07-271r2 m181 Passed by J3 meeting 07-321 m182 Failed J3 letter ballot #14 07-279 07-340r1 m182 Passed by J3 meeting 08-133r2 m183 Passed by letter ballot #15 08-101 ---------------------------------------------------------------------- NUMBER: F03/0104 TITLE: Deallocation and finalization of bounds-remapped pointers KEYWORDS: deallocate, finalization, bounds-remapping, pointer DEFECT TYPE: Interpretation STATUS: Passed by J3 letter ballot INTRODUCTION: Consider the following example assuming a derived type of X is declared previously and made accessible to the current scoping unit, type(X), pointer :: a(:), b(:,:) allocate (a(100)) b(1:10, 1:10) => a DEALLOCATE (b) QUESTION: (a) Is DEALLOCATE (b) in the example intended to be standard conforming? (b) If the answer to (a) is yes, and also assume type X has finalizers of both rank-one and rank-two, then which finalizer should be invoked by the DEALLOCATE statement. ANSWER: (a) Yes, the example is intended to be standard conforming. The deallocation of pointer b should be executed successfully. (b) The Standard is clear about how the finalizations are processed in this case. In 4.5.5.1, the first step in invoking the appropriate final subroutine requires a finalizer matching the rank of the entity being finalized. In this case, object b is being finalized and therefore the rank-two final subroutine of type X will be invoked with object b as the actual argument. EDITS: None. SUBMITTED BY: Jim Xia HISTORY: 07-299 m182 F03/0104 Submitted; Passed by J3 meeting 08-133r2 m183 Passed by letter ballot #15 08-101 ---------------------------------------------------------------------- NUMBER: F03/0106 TITLE: Inquire by unit inconsistencies KEYWORDS: inquire, unit, not connected DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: There are many things that can be inquired about, such as ACTION or READ, that are purely file or connection properties. In some cases, such as ACTION, the specifier description includes "If there is no connection [the result is] the value UNDEFINED" or similar words. In other cases, such as READ, there seems to be a tacit assumption that there is a file connected to the unit. The descriptions refer to "the file" and don't specify a result if there is no connection. In most cases, there is a phrase like "if the processor is unable to determine if the file ... [the result is] {UNDEFINED, UNKNOWN, -1, etc.}". Question 1) Are the inquire specifiers DIRECT, ENCODING, FORMATTED, NAMED, NEXTREC, NUMBER, POS, READ, READWRITE, SEQUENTIAL, SIZE, STREAM, UNFORMATTED, and WRITE allowed in an INQUIRE by unit when there is no file connected to the unit? Question 2) If so, should the descriptions for the above specifiers be clarified by adding phrases such as "if there is no file specified or connected" to the "UNKNOWN" result descriptions? ANSWER: Question 1) Yes. In an inquiry by unit, the specifiers have little meaning when there is no file connected to the unit. However, the standard should specify the results. Question 2) Yes, edits are supplied below. Note: 9.9.1.15 NAMED= [213:10] needs no edit; the value will be false if the unit specified by UNIT= is not connected to a file EDITS: 9.9.1.8 DIRECT= At [212:15], add to the end of the last sentence "or if the unit specified by UNIT= is not connected to a file" 9.9.1.9 ENCODING= At [212:21], after "file" insert "or if the unit specified by UNIT= is not connected to a file" 9.9.1.12 FORMATTED= At [212:36], add to the end of the last sentence "or if the unit specified by UNIT= is not connected to a file" 9.9.1.16 NEXTREC= At [213:15], change "or if" to "," and At [213:16], after "condition" insert ", or the unit specified by UNIT= is not connected to a file" 9.9.1.17 NUMBER= At [213:21+], insert "If the unit specified by UNIT= is not connected to a file, the value is the unit specified by UNIT=." 9.9.1.21 POS= At [214:19], change "or if" to "," and At [214:20], after "conditions" insert ", or the unit specified by UNIT= is not connected to a file" 9.9.1.23 READ= At [215:2], add to the end of the last sentence "or if the unit specified by UNIT= is not connected to a file" 9.9.1.24 READWRITE= At [215:7], add to the end of the last sentence "or if the unit specified by UNIT= is not connected to a file" 9.9.1.27 SEQUENTIAL= At [215:26], add to the end of the last sentence "or if the unit specified by UNIT= is not connected to a file" 9.9.1.29 SIZE= At [215:34], after "determined" insert "or if the unit specified by UNIT= is not connected to a file" 9.9.1.30 STREAM= At [216:5], add to the end of the last sentence "or if the unit specified by UNIT= is not connected to a file" 9.9.1.31 UNFORMATTED= At [216:10], add to the end of the last sentence "or if the unit specified by UNIT= is not connected to a file" 9.9.1.32 WRITE= At [216:15], add to the end of the last sentence "or if the unit specified by UNIT= is not connected to a file" SUBMITTED BY: Dick Hendrickson HISTORY: 07-309 m182 F03/0106 Submitted 07-309r1 m182 Answer based on 07-310; Passed by J3 meeting 08-133r2 m183 Passed letter ballot #15 08-101 ---------------------------------------------------------------------- NUMBER: F03/0107 TITLE: Are the IEEE_* elemental routines required KEYWORDS: IEEE, elemental routines DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: The descriptions for all of the IEEE elemental intrinsics listed in 14.9 say something like "shall not be invoked if IEEE_SUPPORT_DATATYPE(X) is false". I believe this was to allow a careful programmer to do something like if (IEEE_SUPPORT_DATATYPE(x)) then x = IEEE_SCALB(x,2) else x = x*4 endif and program around partial IEEE support. But 14.9.2 says that "IEEE_ARITHMETIC contains the following [routines] for which IEEE_SUPPORT_DATATYPE(X) [is] true" I'd read that as saying the functions aren't there for cases where IEEE_SUPPORT_DATATYPE is false. But, then, there is no way to program around their absence. The example above will fail at load time because IEEE_SCALB is absent. If a processor provides the IEEE_ARITHMETIC module must it provide versions of all of the intrinsics for all of the available datatypes, including those for which IEEE_SUPPORT_DATATYPE() is false? ANSWER: Yes, edits are provided to make this clear. DISCUSSION: It was intended that the above coding snippet could be used by a careful programmer to program portably for processors which have varying degrees of IEEE support. This might require processors to provide some stub function for each routine and for each non-IEEE datatype they support. If a program invokes one of the stub routines, it is a run-time programming error. Nevertheless, a program which has references to the routines, but doesn't invoke them, must load and execute. EDITS: [370:8-9] Replace "for reals X and Y for which IEEE_SUPPORT_DATATYPE(X) and IEEE_SUPPORT_DATATYPE(Y) are true" with "for all reals X and Y" NOTE: The following note should be inserted at the end of the section on IEEE arithmetic in a future standard: "The standard requires that code such as if (IEEE_SUPPORT_DATATYPE(x)) then x = IEEE_SCALB(x,2) else x = x*4 endif be executable. The elemental functions in the IEEE_ARITHMETIC module (14.9.2) must exist for all real kinds supported by the processor, even if IEEE_SUPPORT_DATATYPE returns false for some kinds. However, if IEEE_SUPPORT_DATATYPE returns false for a particular kind, these functions must not be invoked with arguments of that kind. This allows a careful programmer to write programs that work on processors that do not support IEEE arithmetic for all real kinds. The processor might provide stub routines which allow the program to link and execute, but which will abort if they are invoked." SUBMITTED BY: Dick Hendrickson HISTORY: 07-312 m182 F03/0107 Submitted 07-312r2 m182 Passed by J3 meeting 08-133r2 m183 Passed letter ballot #15 08-101 ---------------------------------------------------------------------- NUMBER: F03/0108 TITLE: Is IEEE_SUPPORT_NAN consistent with the other IEEE_SUPPORT functions KEYWORDS: IEEE_SUPPORT_NAN, IEEE support functions DEFECT TYPE: Clarification STATUS: Passed by J3 letter ballot QUESTION: The restriction of IEEE_IS_NAN requires that IEEE_SUPPORT_NAN returns the value true. The restrictions for the similar functions IEEE_IS_{FINITE, NEGATIVE, and NORMAL} all require that IEEE_SUPPORT_DATATYPE be true. This is a much stronger restriction. Should IEEE_SUPPORT_NAN also require that IEEE_SUPPORT_DATATYPE return true? ANSWER: No. The IEEE_SUPPORT_NAN restriction is weaker than requiring IEEE_SUPPORT_DATATYPE but IEEE_SUPPORT_NAN is sufficient. IEEE_SUPPORT_DATATYPE is used in IEEE_IS_FINITE, IEEE_IS_NEGATIVE, and IEEE_IS_NORMAL because there are no IEEE_SUPPORT_* inquiry functions to query support for finite, negative, or normal. IEEE_SUPPORT_INF asks about infinities not finites and IEEE_SUPPORT_DENORMAL only covers denormals and not the other non-finites (NaNs and Infinities). EDITS: None. SUBMITTED BY: Dick Hendrickson HISTORY: 07-328 m182 F03/0108 Submitted 07-328r2 m182 Passed by J3 meeting 08-133r2 m183 Passed letter ballot #15 08-101 ----------------------------------------------------------------------