ISO/IEC JTC1/SC22/WG5 N2047 Result of the interpretations ballot 8, N2043 Key for the Result line: Y vote passes unconditionally. C vote passes, subject to minor changes noted below. N vote fails. Returned to J3 for further work. F08/ F08/ F08/ F03/ F08/ F08/ F08/ F08/ F08/ F08/ 0099 0100 0101 0102 0103 0104 0106 0108 0112 0113 Bader Y Y Y Y Y Y Y Y Y Y Chen Y Y Y Y Y Y Y Y Y Y Cohen Y Y Y Y Y Y Y Y Y Y Corbett Y Y Y Y C Y Y Y Y Y Long Y Y Y Y Y C Y Y Y Y Muxworthy Y Y Y Y Y Y Y Y Y Y Reid Y Y Y Y Y C Y Y Y C Snyder C Y Y N Y Y Y Y Y Y Whitlock Y Y Y Y Y Y Y Y Y Y Result Y Y Y Y Y C Y Y Y C Comments, reasons for NO votes, and decisions of /INTERP. F08/0099 Snyder comment There is no execution sequence for evaluation of specification expressions within a . The only requirement is that the specification expressions are evaluated, in processor- dependent order, before the first executable construct is executed. Therefore, one might infer that the value of a volatile variable that appears more than once in specification expressions could be required to be copied into an anonymous local variable, and then that value used throughout elaboration of the specification part. The answer would thereby be "The program is required to print 'T T'." A note explaining the reasoning by which the program is not required to print 'T T' would be helpful: "NOTE 7.33a If a variable that has the VOLATILE attribute appears more than once in a , its value might be different at each appearance. For example, if N has the VOLATILE attribute, the specification expressions N*N and N**2 might have different values." Decision of /INTERP: pass unchanged. Reasons: We disagree that it would be helpful to put in a Note in the middle of "expressions" in clause 7 to explain the semantics of VOLATILE, which are adequately described in the "VOLATILE attribute" subclause of clause 5. F08/0102 Snyder reason for no vote I agree with the analysis and answer, but not the edit. Three lines into the proposed new paragraph, it says "(for both the declared and dynamic types)". Upon arriving at that statement, one wonders "Where does it say that?" One might expect that a statement prefaced with "Because..." ought to have prior supporting normative specification. The only places that "dynamic" appears in Clause 13 are in the descriptions of EXTENDS_TYPE_OF, MOVE_ALLOC, SAME_TYPE_AS, and STORAGE_SIZE. The note in the answer shows why it is necessary, but the reader ought not be required to prove this theorem. Insert "declared and dynamic" before "type and type parameters" at [368:24], and in the edit for [368:26]. Further, it does not follow that the result is polymorphic if and only if TSOURCE and FSOURCE are polymorphic, simply because they are required to have the same declared and dynamic type and type parameters. Remove "Because ... types)," from the edit (and capitalize "the"), leaving only the requirement (not the unsupported conclusion) "The result is polymorphic if and only if both TSOURCE and FSOURCE are polymorphic." Decision of /INTERP: pass unchanged. Reasons: The requirement on the type of TSOURCE being the same as the type of FSOURCE (at [368:24]) is not qualified explicitly or implicitly to be referring to one or the other, therefore this must mean both the declared type and the dynamic type, see interp F08/0047. It does follow that the result is polymorphic if and only if TSOURCE and FSOURCE are polymorphic. If TSOURCE is not polymorphic, the result has its dynamic type and so is not polymorphic. If FSOURCE is not polymorphic, TSOURCE has the dynamic type of FSOURCE and so the result does too and is therefore not polymorphic. F08/0103 Corbett comment: The answer given requires processors to use less efficient implementations of procedure pointers that target internal procedures and actual arguments that are internal procedures than is necessary. Allowing the two argument form of the intrinsic function ASSOCIATED to take procedure arguments effectively banned some optimizations, but at least a case can be made for doing so. Requiring ASSOCIATED to return .FALSE. in the case where the arguments ultimately reference different instances of the same internal procedure prohibits a processor from taking advantage of the special case where the internal procedure references only statically allocated variables in the host scoping unit. I cannot think of a case where such semantics are useful. If the answer had been that the result returned by ASSOCIATED is undefined when both arguments reference the same internal procedure, more efficient implementations would be possible. Nonetheless, I do not oppose the interpretation. The new semantics given by the interpretation should at least be implementable for processors where pointers to internal procedures are allowed. Decision of /INTERP: pass unchanged. Reasons: Different people preferred different answers. The current answer was the only one with overall support. .................................................................... F08/0104 Long comment: The edit instruction "[407-408:24+]" seems irregular. Table 14.1 starts at [407:24+], but the change is on page 408. [408:1-] would be better. Reid comments: 1. The wording of the edit for [150:28+] is awkward and suggests that the clause "where each argument is a restricted expression," applies only to a function from the intrinsic module ISO_C_BINDING. The wording should be like that proposed for [152:7-8]. I suggest: "(nn) a reference to a transformational function from the intrinsic module IEEE_ARITHMETIC (14), IEEE_EXCEPTIONS (14), or ISO_C_BINDING (15.2), where each argument is a restricted expression," 2. The edit labelled for [407-408:24+] should be labelled for [408:1-]. Decision of /INTERP: pass as amended. .................................................................... F08/0113 Reid comment: In the last line of the edit for [194:6-] add "the value of" before "". Decision of /INTERP: pass as amended.