To: WG5 and J3 08-164r1 From: Stan Whitlock Subject: Interpretation results from WG5 ballot 5 - N1722 & N1726 Date: 2008 May 15 WG5 interp ballot 5 is in N1722; the results of that ballot are in N1726. Many of the interps failed or passed with comments. Below is the summary of the comments from N1726 and the disposition of those comments. The /interp subcommittee considered the status of these interps at J3 meeting 184. The edits for F03/0003 and F03/0004 were clarified and the inteprs were declared "Passed by WG5 ballot". Attached are the edited interps in their final form, either "Passed by WG5 ballot" or "J3 consideration in progress". /Stan ---------------------------------------------------------------------- ISO/IEC JTC1/SC22/WG5 N1726 Result of the interpretations ballot 5, N1722 Key for the Result line: Y Vote passes unconditionally. C Vote passes, subject to J3 considering the comments and reasons and making no change that alters the technical content. N Vote fails. Returned to J3 for further work. F03/ F03/ F03/ F03/ F03/ F03/ F03/ F03/ F03/ 0003 0004 0079 0080 0100 0104 0106 0107 0108 Ingrassia C Y Y Y Y Y Y Y Y Long N N Y Y Y Y Y Y Y Morgan Y Y Y Y Y Y Y Y Y Muxworthy Y Y Y Y Y Y Y C Y Rasmussen Y Y Y Y Y Y Y Y Y Reid Y Y Y Y C Y Y Y Y Snyder C C Y Y Y Y N C Y Whitlock C Y Y Y C Y Y Y Y Xia Y Y Y Y N Y Y Y Y Result C C Y Y N Y C C Y ---------------------------------------------------------------------- F03/0003 Van Snyder In addition to the page/line reference for 04-007, the position of the edit should be noted as a new paragraph after C1224. /interp response: we'll make this change. Bill Long In the paragraph above the ANSWER:, there is a reference to "x%nondeferred_proc". There is no such entity in the program example. I suspect this should be "x%deferred_proc". The edit covers 3 of the 4 possible cases. It seems like the 4th should be covered as well. We should disallow an undefined pointer, a disassociated pointer, an unallocated allocatable variable (all covered), as well as a pointer with an undefined association status. It's not clear why the last one was left off. Stan Whitlock In the paragraph above ANSWER:, the reference to "x%nondeferred_proc" should be "x%deferred_proc". Michael Ingrassia The paragraph immediately above ANSWER is more confusing than helpful, and in any case is merely a comment by the Interp submitter. I believe it should be entirely deleted since it is not properly part of the question nor of the answer. My reading of the paragraph is that it really means something like: Because x is disassociated, its dynamic type is the same as its declared type, thus the interpretation of x%deferred_proc would have been reasonably clear if deferred_proc had been a nondeferred procedure [namely the binding in type(t) would be the procedure called]. It's not worth rewriting the paragraph to make it crystal clear, but I think its intent is subverted if the reference to x%nondeferred_proc is simply changed to x%deferred_proc; the submitter really is talking about nondeferred procedures here. /interp response: The question was about nondeferred procedures, as Mike says. The reference x%nondeferred_proc" should remain. Bill still believes that the EDIT is wrong: an "undefined pointer" is not the same as "a pointer with an undefined association status". In the standard, an "undefined pointer" is a pointer that is associated with an undefined target. (See 16.4.2.2). Malcolm still disagrees. /interp will continue to work on F03/0003. ...................................................................... F03/0004 Van Snyder In addition to the page/line reference for 04-007, the position of the edit should be noted as a new paragraph after C1224. /interp response: we'll make this change. Bill Long In the DISCUSSION: The first sentence is of the form "Access to (a.k.a. ) always ...". I have multiple problems with this sentence. 1) It is confusing to introduce a new, undefined term, "object-bound procedures" when we have a clear, defined term already "procedure pointer component". 2) Slang like "a.k.a" might be avoided, as a consideration to readers whose native language is not English. 3) The sentence runs afoul of f08 where procedure pointer components can have default initialization to a non-NULL target. In that case, the question in the interp applies to procedure pointer components with the NOPASS attribute as well as type-bound procedures. To head off another interp in the future, I'd prefer to just delete the whole DISCUSSION: section. Finally, the edit is the same as in F03/0003, and thus I have the same issue as above. /interp response: "a.k.a." is not slang, it is an abbreviation. The term "object-bound" is usefully descriptive terminology. This is all in the DISCUSSION section, not in the EDIT section or even in the ANSWER. Conflict of the edit (not the technical content) with a new feature in F2008 is irrelevant. But Bill still believes that the EDIT is wrong, as in F03/0003. /interp will continue to work on F03/0004. ...................................................................... F03/0100 John Reid There is a typo in line 9 of the edits: 'mimimum'. Stan Whitlock In line 9 of the edits, "mimimum" should be "minimum". /interp response: We'll fix the typo. Jim Xia The second edit says that if is zero, then the output field for NaN values is 'NaN'. This seems to be too restrictive. Processors should be given options for additional information in the output, e.g. a processor can provide additional information to specify whether a NaN is quiet NaN or signaling NaN. Malcolm Cohen This argument is without merit. w==0 is "minimal field width", and explicitly prohibits inclusion of optional information (such as optional plus signs and leading zeroes). If w==3 produces "NaN" and not "***", then w==0 producing anything longer than 3 is, by definition, NOT minimal. The standard says "On output, with ... F editing, the specified value of the field width may be zero. In such case, the processor selects the smallest positive actual field width that does not result in a field filled with asterisks." Jim's suggestion is contradicted both by the letter and the spirit of the minimal width editing feature in the standard. Jim Xia Then what about another quote from standard for 10.6.1.2.1. F editing: "When w is zero, the processor selects the field width." [228:10]. I think this sentence overrides what Malcolm just quoted since this sentence particularly describe the F editing, while the other is general description for I, B, O, Z and F editing. Malcolm Cohen I cannot agree that "the processor selects the field width" contradicts in ANY way "the processor selects the ... field width ...". The sentence you found does not list all the requirements on the processor. That in no way implies there are none. The word "selects" does not mean "can pick any value it chooses without limitation" unless the entire rest of the standard is silent on the matter. In particular, it does NOT say "processor-dependent". The "processor selects the field width" is drawing a distinction between this case and the w>0 case which might accurately be characterised as the "user selects the field width". Furthermore, re "this sentence overrides": No, that is not true. If there is a contradiction in the standard, then there is a contradiction and the standard is broken. That is not the case here. What we have here is a less specific sentence that gives fewer details than another sentence. Those details are given in other sentences, both within 10.6.1.2.1 and elsewhere. Since (a) the text I quoted is completely unambiguous on this question, (b) that text is NOT contradicted by other text, (c) the w==0 feature was introduced as "minimal field width editing" (see various papers in WG5 and J3 in the lead-up to F95) I don't see how there can be any question that the actual field width when w==0 can be anything other than minimal. /interp response: Stan is convinced by Malcolm's responses but Jim is not. /interp will continue to work on F03/0100. ...................................................................... F03/0106 Van Snyder The edits for 9.9.1.8, 9.9.1.8, 9.9.12, 9.9.1.24, 9.9.1.27, and 9.9.1.29-32 result in sentences of the form "if ... or if ...". The edits for 9.9.1.16 and 9.9.1.21 result in the form "if ..., ..., or...". For consistency with the others, rather than changing "or if" to comma, change "or if" to ", if", and rather than inserting ", or the unit..." insert ", or if the unit...." (This would only merit a C vote, not an N vote). The edit for 9.9.1.17 results in a confusing subclause. I suggest "If UNIT= appears the in the NUMBER= specifier is assigned the value specified by UNIT=. Otherwise if a unit is connected to the file specified by the FILE= specifier the value of the external unit number that is connected to the file is assigned. Otherwise the value -1 is assigned." /interp response: For consistency, the edits for 9.9.1.16 and 9.9.1.21 have been reworded as Van suggests. /interp did not like the suggested rewording for 9.9.1.17 and, following the style of 9.9.1.18, instead substituted "Execution of an INQUIRE by file statement causes the scalar-int-variable in the NUMBER= specifier to be assigned the value of the external unit number of the unit that is connected to the file. If there is no unit connected to the file, the value -1 is assigned. Execution of an INQUIRE by unit statement causes the scalar-int-variable to be assigned the value specified by UNIT=." F03/0106 passes with those changes ...................................................................... F03/0107 Van Snyder In addition to the page/line references to 04-007, it should be noted that the edits apply to the first paragraph of subclause 14.9.2. /interp response: We'll make that change. David Muxworthy The page reference, 370, relates to 04-007 of May 2004. In the standard itself the page number is 368. /interp response: Thank you, David, for the reminder that the line numbers in the printed ISO-IEC-1539-1-2004 differ slightly from 04-007. ---------------------------------------------------------------------- NUMBER: F03/0003 TITLE: Referencing deferred bindings KEYWORDS: Type-bound procedure, deferred binding DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot QUESTION: I thought that the intent was that it would be impossible to reference a deferred binding. However, it doesn't appear to me that this intent was achieved. Consider the following program (Sorry, but I don't have any compilers up to syntax-checking this). module defer type, abstract :: t contains procedure (sub), nopass, deferred :: deferred_proc end type t type, extends(t) :: t2 contains procedure, nopass :: deferred_proc => sub2 end type t2 contains subroutine sub write (*,*) 'Hello.' end subroutine sub subroutine sub2 write (*,*) 'Goodbye.' end subroutine sub2 end module defer program p use defer class(t), pointer :: x nullify(x) call x%deferred_proc end program p Is this a valid program? If not, what restriction of the standard does it violate? Note that x%deferred_proc does not require the value of x (4.5.7) and thus is not a reference to x (2.5.6). Therefore, [83:23-24] does not prohibit this. Nor is it clear that there is an intent to prohibit invocation of type-bound procedures for disassociated pointer objects; except in the case of deferred bindings, this seems well-defined and potentially useful. Because x is disassociated, its dynamic type is the same as its declared type, thus making the interpretation of x%nondeferred_proc reasonably clear. ANSWER: No, this was not intended to be a valid program. A type-bound procedure may not be invoked through an undefined pointer, a disassociated pointer, or an unallocated allocatable variable. An edit is supplied to clarify this situation. The same answer and edit also apply to F03/0004. EDITS: All edits refer to 04-007. Insert after [04-007: 266:24]: "The shall not be an unallocated allocatable variable or a pointer whose association status is disassociated or undefined." Note: this is the same edit as interp F03/0004. SUBMITTED BY: Richard Maine HISTORY: 04-322 m169 F03/0003 Submitted 04-322r1 m169 Passed by J3 meeting 04-418r1 m170 Subsumed by interp F03/0004 05-180 m172 Failed WG5 ballot N1617 - the edit is subsumed by F03/0004 07-280 m182 Revised 07-280r1 m182 Passed by J3 meeting 08-133r2 m183 Passed by letter ballot #15 08-101 08-164r1 m184 Passed WG5 ballot #5 N1722-N1726 with a changed edit ---------------------------------------------------------------------- NUMBER: F03/0004 TITLE: Type-bound procedures and undefined association status KEYWORDS: Type-bound procedure, dynamic type DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot QUESTION: It appears that the dynamic type is undefined for a pointer with undefined association status. This impacts type-bound procedures. Consider the following program. module undefined type :: t contains procedure, nopass :: nondeferred_proc => sub end type t type, extends(t) :: t2 contains procedure, nopass :: nondeferred_proc => sub2 end type t2 contains subroutine sub write (*,*) 'Hello.' end subroutine sub subroutine sub2 write (*,*) 'Goodbye.' end subroutine sub2 end module undefined program p use undefined class(t), pointer :: x call x%nondeferred_proc end program p Is this a valid program? If not, what restriction of the standard does it violate? If so, what does it print. Note that x%nondeferred_proc does not require the value of x (4.5.7) and thus is not a reference to x (2.5.6). Therefore, [83:23-24] does not prohibit this. If x were disassociated, its dynamic type would be t and the interpretation of this would be reasonably clear. However, the standard does not appear to specify the dynamic type of x when its association status is undefined. Nor can I find any prohibition that applies to this case. ANSWER: No, the program is not valid, because the standard does not establish an interpretation of it. An edit is supplied to clarify this. Furthermore, the case with a disassociated pointer was not intended to be valid. An edit is supplied to correct this oversight. DISCUSSION: Access to object-bound procedures (a.k.a. procedure pointer components) always require there to be an object. Access to type-bound procedures of an object was intended to require this too, but the effect of the NOPASS attribute on this was overlooked. EDITS: All edits refer to 04-007. Insert after [04-007: 266:24]: "The shall not be an unallocated allocatable variable or a pointer whose association status is disassociated or undefined." Note: this is the same edit as interp F03/0003. SUBMITTED BY: Richard Maine HISTORY: 04-323 m169 F03/0004 Submitted 04-323r1 m169 Passed by J3 meeting 04-418r1 m170 Passed J3 letter ballot #9 05-180 m172 Failed WG5 ballot N1617 07-337 m182 Passed by J3 meeting 08-133r2 m183 Passed by letter ballot #15 08-101 08-164r1 m184 Passed WG5 ballot #5 N1722-N1726 with a changed edit ---------------------------------------------------------------------- NUMBER: F03/0079 TITLE: Value of decimal exponent for a real zero value KEYWORDS: Data edit descriptors, Numeric editing, decimal exponent, zero value DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot QUESTION: In formatted output, what is the value of the decimal exponent produced for a real zero value under the D, E, EN, ES, and G edit descriptors? ANSWER: In such a case, the decimal exponent should have the value zero whether or not a nonzero scale factor is in effect. Edits are supplied to make this clear. DISCUSSION: The Fortran 2003 standard does not specify what the value of the decimal exponent of a real zero value should be under formatted output. Every implementation of which Sun is aware uses the value zero for the decimal exponent unless a nonzero scale factor is in effect. Different implementations format real zeros differently under nonzero scale factors, but the difference is mainly in the form of the mantissa and not the exponent. EDITS: [227:15+] At the end of the numbered list in 10.6.1 "Numeric editing", add: "(7) On output of a real zero value, the digits in the exponent field shall all be zero." SUBMITTED BY: Michael Ingrassia HISTORY: 06-125 m175 F03/0079 Submitted 07-281r2 m182 Passed by J3 meeting 08-133r2 m183 Passed by letter ballot #15 08-101 08-164 m184 Passed by WG5 ballot N1722-N1726 ---------------------------------------------------------------------- NUMBER: F03/0080 TITLE: Formatted output of a negative real zero value KEYWORDS: formatted output, negative zero, IEEE DEFECT TYPE: Interpretation STATUS: Passed by WG5 ballot QUESTION: Suppose a Fortran processor's representation of the real zero value is signed. When a negative real zero value is written using formatted output, does the Fortran 2003 standard require the representation of the zero value in the output field to be prefixed with a minus sign? ANSWER: Yes, the negative sign is required to appear in formatted output of a negative zero value. In subclause 10.6.1, list item (3) at [227:3-4] says "The representation of a negative internal value in the field shall be prefixed with a minus sign." For a processor that distinguishes between positive and negative zero, there is no exemption for output at [38:1-6]. For the case of IEEE reals, the IEEE_IS_NEGATIVE function at [375:25] explicitly says that -0.0 is "negative". EDITS: None. SUBMITTED BY: Michael Ingrassia HISTORY: 06-126 m175 F03/0080 Submitted 07-282r1 m182 Passed by J3 meeting 08-133r2 m183 Passed by letter ballot #15 08-101 08-164 m184 Passed by WG5 ballot N1722-N1726 ---------------------------------------------------------------------- NUMBER: F03/0100 TITLE: Error in field width for special cases of signed INFINITY output KEYWORDS: formatted output, signed infinity DEFECT TYPE: Erratum STATUS: J3 consideration in progress 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 minimum 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 08-164 m184 Failed WG5 balot #5 N1722-N1726 F03/0100 summary of Jim Xia's issues: 1. The standard puts similar but somewhat different sentences in three places, which is inconsistent. Only one sentence (in E editing) is complete while the other two (one for integer editing, and one for F editing) are both incomplete. 2. As to the restriction on output being "NaN" for F editing when w == 0, I'm still not convinced it is to the best benefit to Fortran users given the fact that the majority of the processors today distinguish qNaNs vs. sNaNs. ---------------------------------------------------------------------- NUMBER: F03/0104 TITLE: Deallocation and finalization of bounds-remapped pointers KEYWORDS: deallocate, finalization, bounds-remapping, pointer DEFECT TYPE: Interpretation STATUS: Passed by WG5 ballot INTRODUCTION: Consider the following example assuming a derived type of X is declared previously and made accessible to the current scoping unit, type(X), pointer :: a(:), b(:,:) allocate (a(100)) b(1:10, 1:10) => a DEALLOCATE (b) QUESTION: (a) Is DEALLOCATE (b) in the example intended to be standard conforming? (b) If the answer to (a) is yes, and also assume type X has finalizers of both rank-one and rank-two, then which finalizer should be invoked by the DEALLOCATE statement. ANSWER: (a) Yes, the example is intended to be standard conforming. The deallocation of pointer b should be executed successfully. (b) The Standard is clear about how the finalizations are processed in this case. In 4.5.5.1, the first step in invoking the appropriate final subroutine requires a finalizer matching the rank of the entity being finalized. In this case, object b is being finalized and therefore the rank-two final subroutine of type X will be invoked with object b as the actual argument. EDITS: None. SUBMITTED BY: Jim Xia HISTORY: 07-299 m182 F03/0104 Submitted; Passed by J3 meeting 08-133r2 m183 Passed by letter ballot #15 08-101 08-164 m184 Passed by WG5 ballot N1722-N1726 ---------------------------------------------------------------------- NUMBER: F03/0106 TITLE: Inquire by unit inconsistencies KEYWORDS: inquire, unit, not connected DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot QUESTION: There are many things that can be inquired about, such as ACTION or READ, that are purely file or connection properties. In some cases, such as ACTION, the specifier description includes "If there is no connection [the result is] the value UNDEFINED" or similar words. In other cases, such as READ, there seems to be a tacit assumption that there is a file connected to the unit. The descriptions refer to "the file" and don't specify a result if there is no connection. In most cases, there is a phrase like "if the processor is unable to determine if the file ... [the result is] {UNDEFINED, UNKNOWN, -1, etc.}". Question 1) Are the inquire specifiers DIRECT, ENCODING, FORMATTED, NAMED, NEXTREC, NUMBER, POS, READ, READWRITE, SEQUENTIAL, SIZE, STREAM, UNFORMATTED, and WRITE allowed in an INQUIRE by unit when there is no file connected to the unit? Question 2) If so, should the descriptions for the above specifiers be clarified by adding phrases such as "if there is no file specified or connected" to the "UNKNOWN" result descriptions? ANSWER: Question 1) Yes. In an inquiry by unit, the specifiers have little meaning when there is no file connected to the unit. However, the standard should specify the results. Question 2) Yes, edits are supplied below. Note: 9.9.1.15 NAMED= [213:10] needs no edit; the value will be false if the unit specified by UNIT= is not connected to a file EDITS: 9.9.1.8 DIRECT= At [212:15], add to the end of the last sentence "or if the unit specified by UNIT= is not connected to a file" 9.9.1.9 ENCODING= At [212:21], after "file" insert "or if the unit specified by UNIT= is not connected to a file" 9.9.1.12 FORMATTED= At [212:36], add to the end of the last sentence "or if the unit specified by UNIT= is not connected to a file" 9.9.1.16 NEXTREC= At [213:15], change "or if" to ", if" and At [213:16], after "condition" insert ", or if the unit specified by UNIT= is not connected to a file" 9.9.1.17 NUMBER= Replace [213:20-21] with "Execution of an INQUIRE by file statement causes the scalar-int-variable in the NUMBER= specifier to be assigned the value of the external unit number of the unit that is connected to the file. If there is no unit connected to the file, the value -1 is assigned. Execution of an INQUIRE by unit statement causes the scalar-int-variable to be assigned the value specified by UNIT=." 9.9.1.21 POS= At [214:19], change "or if" to ", if" and At [214:20], after "conditions" insert ", or if the unit specified by UNIT= is not connected to a file" 9.9.1.23 READ= At [215:2], add to the end of the last sentence "or if the unit specified by UNIT= is not connected to a file" 9.9.1.24 READWRITE= At [215:7], add to the end of the last sentence "or if the unit specified by UNIT= is not connected to a file" 9.9.1.27 SEQUENTIAL= At [215:26], add to the end of the last sentence "or if the unit specified by UNIT= is not connected to a file" 9.9.1.29 SIZE= At [215:34], after "determined" insert "or if the unit specified by UNIT= is not connected to a file" 9.9.1.30 STREAM= At [216:5], add to the end of the last sentence "or if the unit specified by UNIT= is not connected to a file" 9.9.1.31 UNFORMATTED= At [216:10], add to the end of the last sentence "or if the unit specified by UNIT= is not connected to a file" 9.9.1.32 WRITE= At [216:15], add to the end of the last sentence "or if the unit specified by UNIT= is not connected to a file" SUBMITTED BY: Dick Hendrickson HISTORY: 07-309 m182 F03/0106 Submitted 07-309r1 m182 Answer based on 07-310; Passed by J3 meeting 08-133r2 m183 Passed letter ballot #15 08-101 08-164 m184 Passed WG5 ballot #5 N1722-N1726 ---------------------------------------------------------------------- NUMBER: F03/0107 TITLE: Are the IEEE_* elemental routines required KEYWORDS: IEEE, elemental routines DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot QUESTION: The descriptions for all of the IEEE elemental intrinsics listed in 14.9 say something like "shall not be invoked if IEEE_SUPPORT_DATATYPE(X) is false". I believe this was to allow a careful programmer to do something like if (IEEE_SUPPORT_DATATYPE(x)) then x = IEEE_SCALB(x,2) else x = x*4 endif and program around partial IEEE support. But 14.9.2 says that "IEEE_ARITHMETIC contains the following [routines] for which IEEE_SUPPORT_DATATYPE(X) [is] true" I'd read that as saying the functions aren't there for cases where IEEE_SUPPORT_DATATYPE is false. But, then, there is no way to program around their absence. The example above will fail at load time because IEEE_SCALB is absent. If a processor provides the IEEE_ARITHMETIC module must it provide versions of all of the intrinsics for all of the available datatypes, including those for which IEEE_SUPPORT_DATATYPE() is false? ANSWER: Yes, edits are provided to make this clear. DISCUSSION: It was intended that the above coding snippet could be used by a careful programmer to program portably for processors which have varying degrees of IEEE support. This might require processors to provide some stub function for each routine and for each non-IEEE datatype they support. If a program invokes one of the stub routines, it is a run-time programming error. Nevertheless, a program which has references to the routines, but doesn't invoke them, must load and execute. EDITS: In the first paragraph of subclause 14.9.2 [370:8-9] Replace "for reals X and Y for which IEEE_SUPPORT_DATATYPE(X) and IEEE_SUPPORT_DATATYPE(Y) are true" with "for all reals X and Y" NOTE: The following note should be inserted at the end of the section on IEEE arithmetic in a future standard: "The standard requires that code such as if (IEEE_SUPPORT_DATATYPE(x)) then x = IEEE_SCALB(x,2) else x = x*4 endif be executable. The elemental functions in the IEEE_ARITHMETIC module (14.9.2) must exist for all real kinds supported by the processor, even if IEEE_SUPPORT_DATATYPE returns false for some kinds. However, if IEEE_SUPPORT_DATATYPE returns false for a particular kind, these functions must not be invoked with arguments of that kind. This allows a careful programmer to write programs that work on processors that do not support IEEE arithmetic for all real kinds. The processor might provide stub routines which allow the program to link and execute, but which will abort if they are invoked." SUBMITTED BY: Dick Hendrickson HISTORY: 07-312 m182 F03/0107 Submitted 07-312r2 m182 Passed by J3 meeting 08-133r2 m183 Passed letter ballot #15 08-101 08-164 m184 Passed WG5 ballot #5 N1722-N1726 ---------------------------------------------------------------------- NUMBER: F03/0108 TITLE: Is IEEE_SUPPORT_NAN consistent with the other IEEE_SUPPORT functions KEYWORDS: IEEE_SUPPORT_NAN, IEEE support functions DEFECT TYPE: Clarification STATUS: Passed by WG5 ballot QUESTION: The restriction of IEEE_IS_NAN requires that IEEE_SUPPORT_NAN returns the value true. The restrictions for the similar functions IEEE_IS_{FINITE, NEGATIVE, and NORMAL} all require that IEEE_SUPPORT_DATATYPE be true. This is a much stronger restriction. Should IEEE_SUPPORT_NAN also require that IEEE_SUPPORT_DATATYPE return true? ANSWER: No. The IEEE_SUPPORT_NAN restriction is weaker than requiring IEEE_SUPPORT_DATATYPE but IEEE_SUPPORT_NAN is sufficient. IEEE_SUPPORT_DATATYPE is used in IEEE_IS_FINITE, IEEE_IS_NEGATIVE, and IEEE_IS_NORMAL because there are no IEEE_SUPPORT_* inquiry functions to query support for finite, negative, or normal. IEEE_SUPPORT_INF asks about infinities not finites and IEEE_SUPPORT_DENORMAL only covers denormals and not the other non-finites (NaNs and Infinities). EDITS: None. SUBMITTED BY: Dick Hendrickson HISTORY: 07-328 m182 F03/0108 Submitted 07-328r2 m182 Passed by J3 meeting 08-133r2 m183 Passed letter ballot #15 08-101 08-164 m184 Passed WG5 ballot #5 N1722-N1726 ----------------------------------------------------------------------