08-133r2 To: J3 From: Stan Whitlock Subject: Results of the J3 interp letter ballot #15 Date: 2008 February 15 Here are the results of J3 letter ballot #15 on Fortran interpretations that officially closed 10-Feb-2008. The ballot is in J3 paper 08-101 for meeting #183. If I have transcribed a vote or a comment incorrectly, please let me know. J3 rep F03 F03 F03 F03 F03 F03 F03 F03 F03 F03 F03 003 004 079 080 099 100 102 103 104 105 106 Dick Hendrickson ** - - - - - C - - - - C Michael Ingrassia Y Y Y C Y Y Y Y Y Y Y Shivarama Kokrady no ballot received Bill Long C C Y Y Y C Y Y C Y N Jeanne Martin Y Y Y Y Y Y Y Y Y Y Y Dan Nagle Y Y Y Y Y Y Y Y Y Y Y Craig Rasmussen Y Y Y Y Y Y Y Y Y Y Y Van Snyder Y Y Y Y Y Y Y Y Y Y Y Matthijs van Waveren * Y Y Y Y Y Y Y Y Y Y Y Stan Whitlock C Y Y Y Y Y Y Y Y Y N Jim Xia C Y Y Y Y Y Y C Y Y N Malcolm Cohen ** C C C Y N N N N C N C J3 rep F03 F03 F03 107 108 109 Dick Hendrickson ** - - - Michael Ingrassia Y Y Y Shivarama Kokrady no ballot received Bill Long Y Y Y Jeanne Martin Y Y Y Dan Nagle Y Y Y Craig Rasmussen Y Y Y Van Snyder Y Y Y Matthijs van Waveren * Y Y Y Stan Whitlock Y Y Y Jim Xia Y Y Y Malcolm Cohen ** N Y N * ballot from alternate Toon Moene ** valuable comments even though vote doesn't count where Y means "yes" C "yes with comment" N "no with comment" The comments for each interp are attached below in the same order as the table above. The summary of DRAFT results is as follows: Y = passed C = passed as amended N = needs further consideration F03 F03 F03 F03 F03 F03 F03 F03 F03 F03 F03 F03 F03 F03 003 004 079 080 099 100 102 103 104 105 106 107 108 109 C Y C Y N C N N C N C C Y N The interps marked "C" pass with some minor fixes, as noted below. The interps marked "N" will be reconsidered at J3 meeting #183 by the /interp committee who will decide if the status becomes "withdraw for more work", "passed as amended", or "passed as printed". The edited interps in their final form for F03/003 F03/080 F03/106 F03/004 F03/100 F03/107 F03/079 F03/104 F03/108 are attached for use at meeting #183. /Stan ********************************************************************** F03/0003 Referencing deferred bindings YES Comment for F03/0003 from Bill Long: As noted by others, a ",nopass" needs to be added to the procedure statement in the definition of type t2. YES Comment for F03/0003 from Stan Whitlock: I agree with Jim Xia: The example given in the interp has another error unrelated to the issue raised: the type-bound procedure, deferred_proc, for type t2 must have NOPASS attribute. The example should be corrected. YES Comment for F03/0003 from Jim Xia: The example given in the interp has another error unrelated to the issue raised: the type-bound procedure, deferred_proc, for type t2 must have NOPASS attribute. The example should be corrected. Comment for F03/0003 from Malcolm Cohen: I agree with Jim Xia's suggested change to the example. Resolution for F03/0003: passed with change: Add ", nopass" to the procedure statement in the definition of type t2. F03/0004 Type-bound procedures and undefined association status YES Comment for F03/0004 from Bill Long: Wording improvement in the Discussion section: replace "requires there to be an object" with "requires an object". Comment for F03/0004 from Malcolm Cohen: The DISCUSSION section is ok as is. It would not hurt to singularise it, but that is unnecessary. Bill Long's suggestion is ungrammatical (mixes singular and plural). The point of "... always require there to be an object" is that we are talking about pointers here, and that we're that there be an object in question. We're not requiring the object, just that there be one. (With disassociated/undefined, there is no object.) Resolution for F03/0004: passed with no change F03/0079 Value of decimal exponent for a real zero value Comment for F03/0079 from Malcolm Cohen: The discussion seems subtly wrong-headed - not wrong enough for me to vote No, but enough to raise questions. The discussion focusses on what the effect of a scale factor is, but the EN and ES edit descriptors explicitly say that the scale factor has no effect; any implementation that formats EN/ES differently IN ANY WAY due to scale factor is not conforming already. But anyway, shouldn't we just say that the "exponent value" of a real zero is zero? Resolution for F03/0079: passed with change: Change the edit to remove any mention of scale factor. F03/0080 Formatted output of a negative real zero value YES Comment for F03/0080 from Michael Ingrassia: Since this interpretation is not compatible with Fortran 90, a note to that effect should be added to section 1.6.2 of the Fortran 2003 standard as an additional Edit. Resolution for F03/0080: passed with no change There is no conflict with Fortran 90. F03/0099 Clause 16 does not account for volatile variable No Comment for F03/0099 from Malcolm Cohen: In the second edit, everything past the first sentence is redundant, unnecessary, and unwanted; it is covered by 16.4.2.0. Indeed, if it were not covered by that, we would need to produce these extra words in many other places. I disagree with the third and fourth edits not being list items - we might as well do away with the whole list in that case! Perhaps someone was worried about the "might" in the list - well, we are already in the "sometimes" situation for INQUIRE, I don't see what is so different here. Resolution for F03/0099: Failed letter ballot F03/0100 Error in field width for special cases of signed INFINITY output Comment for F03/100 from Dick Hendrickson: 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 less than the mimimum required but large enough to produce the form "Inf" then the form ^ A comma is needed here to make the sentence parallel to the other "If " sentence above "Inf" is output.' YES Comment for F03/0100 from Bill Long: It appears that part of the HISTORY section is missing. It seem like we're on the second round with this one. No Comment for F03/0100 from Malcolm Cohen: Firstly, the "then" should be a comma - see nearby sentences in the standard for examples (this is English not Fortran). Secondly, the last sentence omits the case of w==0, which is now unspecified. >> Bill Long responded: I disagree with the second comment. The case for w==0 is covered at [228:10]. The text we're trying to fix is just wrong in the current standard. It says that if w=0 (a special case of < 3), the field is filled with *. Resolution for F03/0100: passed with change: Fix edits for 'Inf' and 'NaN' for when is zero. F03/0102 Evaluation of bound-expr in data pointer assignment NO Comment for F03/0102 from Malcolm Cohen: The example is already not conforming - see [128:6-7]. Just because the standard has another redundant sentence is not sufficient reason for adding more. According to 16.5.5, changing the pointer association can cause definition, so that bit is definitely unnecessary. I don't immediately see the corresponding version for 16.5.6 - that would appear to be an omission in its own right (unrelated to the example given or any legal mutation thereof). If that omission is fixed (or if it is there and I just didn't spot it) this interp (after fixing the example) probably needs no edit at all. Resolution for F03/0102: failed letter ballot We agree with Malcolm's comment. F2003 [414:4-5] says; "If a pointer is associated with a target, the definition status of the pointer is either defined or undefined, depending on the definition status of the target." The correct place for an edit would be in section 16.5.6 "Events that cause variables to become undefined". F03/0103 Restrictions on dummy arguments not present for polymorphic type or parameterized derived type YES Comment for F03/0103 by Jim Xia: My only comment is that rules for optional dummy arguments of either polymorphic type or a type with assumed length type parameters seem much more relaxed compared to pointer/allocatable cases. These rules make the restrictions on optional pointer/allocatable optional dummy arguments too restrictive. NO Comment for F03/0103 from Malcolm Cohen: The DISCUSSION is completely irrelevant unless we are talking about POINTER/ALLOCATABLE, which we are not. I probably disagree with the assertion that these two situations "is" or were intended to be allowed. The question needs some example code we can say is right or wrong. (With some example code maybe I could say whether or not I actually agree or disagree with the bold assertion in the ANSWER!) The edit makes the following code fragment legal: Subroutine one(x) Double Precision,Optional :: x Call two(x) End Subroutine two(y) Real,Optional :: y ... I can categorically state that we definitely did NOT intend this to be legal! Resolution for F03/0103: failed letter ballot We do not understand the question sufficiently to produce a response. F03/0104 Deallocation and finalization of bounds-remapped pointers YES Comment for F03/0104 from Bill Long: In ANSWER: (b), first line, add "are" between "finalizations" and "processed". Comment for F03/0104 from Malcolm Cohen: I agree with Bill Long that "are" should be inserted before "processed" in the first sentence. Furthermore, the first sentence should begin "The standard" at a minimum. Resolution for F03/0104: passed with change: Make the changes described by Bill and Malcolm. F03/0105 SIZE= specifier and UDDTIO NO Comment for F03/0105 from Malcolm Cohen: I don't quite follow the reasoning behind this one; it appears to me that the characters are being transferred by the DT edit descriptor (proxied via the child i/o procedure). It is also a horrible restriction that cannot be detected statically. Resolution for F03/0105: failed letter ballot We believe that the example is standard conforming. We believe the Standard requires SIZE= to work in the presence of child I/O. F03/0106 Inquire by unit inconsistencies Comment for F03/106 from Dick Hendrickson: 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=." This contradicts table C.1 in Appendix C of F95 (page 325). Should there be some sort of note about non-upward compatibility? Or, should the result be -1 instead? >> Response from Bill Long: Appendix C is not normative. We only document incompatibilities related to normative text. The normative text in F95 leaves this case ambiguous. The point of the interp is to fill in holes and clarify those amibuities. NO Comment for F03/0106 from Bill Long: The edit for 9.9.1.16 NEXTREC=... is unnecessary and redundant. If there is no connection, then certainly the file is not connected for direct access, so that case is covered by [213:15]. The edit for 9.9.1.21 POS=... is unnecessary and redundant. If there is no connection, then certainly the file is not connected for stream access, so that case is covered by [214:19]. >> Malcolm Cohen responded: I don't agree. [213:15] presupposes there is a file we are talking about, and in the case of UNIT= there is no file so it is meaningless to talk about "the file" when there isn't one. The same comment for POS=. These edits are fixing real unspecified behaviour; if there is no file saying something about "the file" says nothing (or the standard derefs a null pointer and seg faults, or something). I have my own problems with the edits, but that's just because they specify a three-element list as "A or B or C" instead of "A, B, or C". NO Comment for F03/0106 from Stan Whitlock: I agree with Jim Xia: The edit for NEXTREC= (9.9.1.16) says "At [213:16], after 'connection' ...". But I cannot find the word "connection" on that line, so I'm not quite certain what the edit is trying to say. Does it mean the word "connected" at [213:15]? NO Comment for F03/0106 from Jim Xia The edit for NEXTREC= (9.9.1.16) says "At [213:16], after 'connection' ...". But I cannot find the word "connection" on that line, so I'm not quite certain what the edit is trying to say. Does it mean the word "connected" at [213:15]? Comment for F03/0106 from Malcolm Cohen: I disagree with Bill Long's suggested changes for POS= and NEXTREC=. The existing wording is entirely talking about "the file"; well, if the unit is not connected *there is no file*. So either it is unspecified for an unconnected UNIT=, or the standard seg faults on the nonexistent file. Resolution for F03/0106: passed with change: The directions for the edit should read "At [213:16], after 'condition' ...". Fix the edits for NEXTREC= and POS= to change "if A or if B or if C" to "if A, B, or C" F03/0107 Are the IEEE_* elemental routines required NO Comment for F03/0107 from Malcolm Cohen: As a matter of principle an interp should be seeking to make the smallest possible change. Insertion of a large note is out of order. Those who are interested in the answer will be reading the discussion in the interp request. Resolution for F03/0107: passed with change: We recommend that the large note in the edit not be put into F2003 but be put into a future standard. F03/0108 Is IEEE_SUPPORT_NAN consistent with the other IEEE_SUPPORT functions Resolution for F03/0108: passed with no change F03/0109 Referencing deferred binding via absent dummy argument NO Comment for F03/0109 from Malcolm Cohen: This edit is being done to the wrong text. Restrictions on the use of nonpresent dummy arguments are meant to be in the subclause "Restrictions on dummy arguments not present". Furthermore, I see no corresponding restrictions for object-bound procedures. These are invoked via which is %. This is not a so is not covered by item (5) in 12.4.1.6. (This will affect lots of usages, not just invocation.) Yes, I appreciate that that wasn't quite the question asked by the interp but since these two things are so similar we should consider them both. Resolution for F03/109: failed letter ballot We agree with Malcolm's comment - the edit needs to be elsewhere. ---------------------------------------------------------------------- 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-xxx 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-xxx 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-xxx 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-xxx 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-133r1 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-133r1 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-133r1 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-133r1 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-133r1 m183 Passed letter ballot #15 08-101 ----------------------------------------------------------------------