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 N N Y Y N Y C C Y Comments and reasons for NO votes ............................................................................... 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. 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. ............................................................................... 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. 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. ............................................................................... 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". 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. I quote from the standard "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 Sorry Jim, but 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. Not now. Not ever. If there is a contradiction in the standard (and I don't mean a contrived one made up by taking sentences out of context) 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. ............................................................................... 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." ............................................................................... 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. David Muxworthy The page reference, 370, relates to 04-007 of May 2004. In the standard itself the page number is 368.