ISO/IEC JTC1/SC22/WG5 N1939 Result of the interpretations ballot 3, N1933 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. No result for F08/0040 is given here because it should not have been in N1933. It is not included in N1932. The comments are given in alphabetic order, which sometimes causes forward references to later comments. F03/ F03/ F03/ F03/ F03/ F03/ F03/ F03/ F03/ F03/ 0017 0018 0019 0021 0046 0053 0065 0084 0096 0103 Bader Y Y Y Y Y N Y N Y Y Chen Y Y Y Y Y Y Y Y Y N Cohen Y Y Y Y Y Y Y Y Y Y Corbett Y Y Y Y Y N C N Y Y Long Y Y Y Y Y N Y N Y Y Maclaren Y Y Y Y Y C C C Y - Muxworthy Y Y Y Y Y Y Y N Y Y Reid Y Y Y Y Y N Y N Y Y Snyder Y Y Y Y Y Y Y N Y Y Result Y Y Y Y Y N C N Y C F03/ F03/ F03/ F03/ F08/ F08/ F08/ F08/ F08/ F08/ 0116 0118 0120 0121 0004 0008 0031 0032 0038 0042 Bader Y Y Y N Y Y Y C 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 N N C Y Y Y Y Long Y Y Y N Y Y Y Y Y Y Maclaren Y Y Y C Y Y Y Y Y Y Muxworthy Y Y Y C Y Y Y Y Y Y Reid Y Y Y N Y Y Y Y Y Y Snyder Y Y C N Y Y Y Y Y Y Result Y Y C N C C Y C Y Y Comments and reasons for NO votes F03/0053 Bader NO vote: I agree with John Reid that it should be explicitly stated that the above types do not have the BIND attribute. Corbett NO vote: I agree with John that allowing private components in derived types that have the BIND attribute seems absurd. Long NO vote: Regarding answer 3, I think it would be better to disallow PRIVATE components in a type with the BIND attribute. A C routine called outside the module where the type is defined, and accessing a variable of such a type would be able to access and modify the PRIVATE components. Maclaren comment: A better solution would be to state that, notwithstanding the general rules for derived types, they do have the BIND attribute and are interoperable with C variables of type 'void *' and 'void (*) ()', respectively. This matter should be addressed in a future revision, but it might be easier to do that now than make the current situation consistent. I also agree with John Reid on question (2), and regard the liberty to break the privacy restrictions by using interoperability as a defect in the standard. And, yes, I agree that it would be fine to do that for SEQUENCE, too. But both would be changes to the standard. Reid NO vote: 1. I remain of the opinion that 15.3.3 should state clearly that C_PTR and C_FUNPTR do not have the BIND attribute. It is counter- intuitive that they are interoperable and yet do not have the BIND attribute. They are defined in an intrinsic module so the reader cannot look at the definition. The present text relies on the distinction between "derived type" in 15.3.3 and "Fortran derived type" in 15.3.4. The term "Fortran derived type" is undefined and is not used anywhere else in the standard (as far as I can see). The text of 15.3.3 is similar to 15.2.2 in the Fortran 2003 standard. In N1622, J3 thought it was unclear and proposed editing 15.2.2 to say that these types do have the BIND attribute. I suggest the edit: [431:2] 15.3.3, para 1. At the end of sentence 1 add "and without the BIND attribute". 2. Was it really intended that a user-defined derived type with the BIND attribute be permitted to have private components? It seems to me that this should not be permitted since it destroys the purpose of declaring components to be private. If it was intended, the rationale should be included in the answer - this is, after all, an interpretation. .................................................................... F03/0053: Replies from the editor - it is a fundamental principle that entities only have the attributes that the standard says they have. We do not say the integer 13 does not have the BIND attribute. We do not even say that derived types defined with no BIND(C) clause do not have the BIND attribute! We should strenuously resist putting more unnecessary blather into the standard. Oh, and at max this is "friendly witter". Inserting witter is not necessary for defect correction. In fact my opinion is that this kind of thing is not friendly at all but is harmful to comprehension, because it means that in every other case where we don't say an entity "does not have (laundry-list of attributes)", the reader will be misled into thinking that maybe it might. No. No. No. Just don't do it. And especially there is no case for doing it via interp. <<< It is counter-intuitive that they are interoperable and yet do not have the BIND attribute. >>> Not so; plenty of things are interoperable and do not have the BIND attribute. For an example of another type that is interoperable but does not have the BIND attribute, see INTEGER(c_int). <<< They are defined in an intrinsic module so the reader cannot look at the definition. >>> There is, in fact, no derived-type definition, any more than there is a secret INTERFACE block for any generic intrinsic. A derived-type definition is a piece of Fortran syntax in the program, and therefore cannot be exist in anything intrinsic. <<< The present text relies on the distinction between "derived type" in 15.3.3 and "Fortran derived type" in 15.3.4. >>> No it does not. I do not know where this bizarre idea comes from. <<< The term "Fortran derived type" is undefined and is not used anywhere else in the standard (as far as I can see). >>> It is not an undefined term, it is plain English. Grr. I understand why the authors of that text thought it was useful to drop a few "Fortran" hints in case the reader got the idea they might have been using a C term, but IMO it was unnecessary (it has confused John at least!). <<< The text of 15.3.3 is similar to 15.2.2 in the Fortran 2003 standard. In N1622, J3 thought it was unclear and proposed editing 15.2.2 to say that these types do have the BIND attribute. >>> I dispute this account. Though N1622 is ancient history and not relevant anyway. The point is that J3 was confused about whether THEY INTENDED for these types not to have the BIND attribute. There was no confusion in my mind, or likely in other /DATA or /INTEROP members, as to what the standard actually said, the question was entirely whether this was a mistake or not! And if the answer was ever going to be that they had the BIND attribute, of course an edit was needed as you point out, because in the absence of an edit they do NOT have the BIND attribute, any more than 42_c_int does. <<< 2. Was it really intended that a user-defined derived type with the BIND attribute be permitted to have private components? >>> Yes, by analogy with SEQUENCE. In fact BIND is very very like SEQUENCE, the only real difference being a potential difference in alignment padding. <<< It seems to me that this should not be permitted since it destroys the purpose of declaring components to be private. >>> Then we had better prohibit PRIVATE from SEQUENCE types, because it has Precisely The Same Effect there, and has done since 1991. We Are Not Going To Do That. (Aside: we don't even prohibit non-SEQUENCE non-BIND(C) types with PRIVATE components in the TRANSFER intrinsic, so this idea that PRIVATE is some kind of impermeable electric fence has never been correct.) <<< If it was intended, the rationale should be included in the answer - this is, after all, an interpretation. >>> No rationale is required for this any more than for any other part of the standard. It has the normal rationale "it got voted in". You don't get us to write 1000 lines after class if you don't like the answer, that is no more reasonable than it would be for me to demand to hear from you why everyone voted for SEQUENCE+PRIVATE back in the day... J3 has consistently voted against any kind of rationale document. There is no case to answer here. Nick writes: > I also agree with John Reid on question (2), and regard the liberty to > break the privacy restrictions by using interoperability as a defect in > the standard. Well good then, because you cannot "break the privacy restrictions" that way. The user cannot put BIND(C) on the derived types in the library he is calling. If it's his own library, *HE CAN DO ANYTHING HE LIKES ANYWAY*. The Fortran PRIVATE attribute has never ever been this super-restrictive thing that you and John are imagining. For SEQUENCE types (and thus BIND(C) types) there are multiple ways of "seeing past the curtain", in these cases all PRIVATE does is to hide the name when accessing things of the type outside of a module with a definition. This is not as useful as PRIVATE on an extensible type, but still has some uses. Once again, with feeling: BIND(C) is merely the interoperable version of SEQUENCE, and therefore has basically the same allowances and limitations as SEQUENCE. There is no defect here. .................................................................... F03/0065 Corbett comment: While I would not object to adding a note about relational equivalence, I do not think relational equivalence should be allowed to change the results of relational operations. The Fortran standard claims to promote portability and reliability of Fortran programs. Allowing a processor to produce the value false for -2 .LT. 2147483647 does not seem likely to promote portability or reliability. The FORTRAN 66 standard allowed a processor to commute and re-associate the operands of operators when the corresponding mathematical operators were commutative or associative, but that was all it explicitly allowed. The concept of integrity of parentheses made sense in this context. The general notion of mathematical equivalence was introduced in FORTRAN 77. It has been a bane of Fortran programmers ever since. The concept of relational equivalence is specified in Section 6.6.6 of the FORTRAN 77 standard. Maclaren comment: My problem is not with the decision, but the answer, which I consider to be a serious mistake. I shall submit a J3 paper trying to explain why, but this is a summary. The intention was that this is an interpretation about the handling of 'EQ.' - no more - but that is not the only way to read those words. I read them as also making a statement about the arithmetic (in this case, X+3.0), because of the sentence beginning "On a machine ...", and I am sure that at least some other readers will do the same. Specifically, there are a lot of widespread and important optimisations that would also fall foul of the test "the logical values for X+3.0==3.0 are not the same as ". In particular, this very common one would: IF (REAL(X,KIND=KIND(0.0D0))+3.0D0 .EQ. 3.0D0) ... I suggest that the answer be changed to something more like: No, transformations across a relational operator are not permitted unless they give the same answer for all possible values of the operands on either side (X, 0.0, X+3.0 and 3.0). The standard does not specify how X+3.0 is calculated, but the transformation would not give the same answer for all values of X in any floating-point arithmetic. In particular, the qualification "across a relational operator" (or similar wording) is essential to resolve my concerns. .................................................................... F03/0084 Bader NO vote: The answers given to both (1) and (2) in the interp appear to me to be counterintuitive; the programmer would expect that the calculation of Z1 and Z2 respectively obey the imposed rounding mode. In particular, I suspect there are situations where it is more obvious to the compiler than to the programmer that expressions are evaluated at compile time, and that different processors may have differing capabilities in identifying such expressions. The resolution of such situations is one target that the IEEE facilities were designed for. I therefore am in favor of the stance that, if supported, the setting of the rounding mode should take precedence over processor-dependent compile-time evaluations. Corbett NO vote: I disagree with the interpretation given. I believe that the assignments should require conversions to be done and that the conversions should be done in accord with the rounding mode currently in effect. Therefore, the results should not be zero. Long NO vote: I was confused by John's comment that the rounding mode on entry to the subroutine affected the value of Z1 since the computation of Z1 follows a call that resets the rounding mode. I think the real question here is what the standard means by "mathematical". I had always thought in terms of things like algebra. John's answer seems to imply that computational numerics (as specified by IEEE) are part of the concept of "mathematical". In other contexts, I think that John's interpretation could be harmful. On the other hand, the current answer does seem to make the usefulness of the IEEE_SET_ROUNDING_MODE routine more limited that would be expected. Also, does the concept of mathematically equivalent apply to the aggregation of multiple statements, or does it apply to just one expression? A processor that used the "mathematically equivalent" argument to get 0 would need to forward sub the expressions for Z1 and Z2 into the print statement to get X*Y - X*Y. I don't think we intended to allow forward substitution of expressions across one of the IEEE mode setting routines. Maclaren comment: This relates to F03/0065, but is the other way round. Unlike that one, I consider this consistent with the majority of the semantic wording in the C standard. Muxworthy No vote: I agree with John's vote. Reid NO vote: The IEEE rounding mode on entry to the procedure may vary from call to call. The value of Z1 depends on this rounding mode. Therefore, the processor should not always print zero for Z1-Z2. Whether or not Z1 and Z2 have the PARAMETER attribute makes no difference. Yes, the processor is allowed to evaluate an expression in any mathematically equivalent way, but here the mathematics dictates that a particular form of rounding, defined in the IEEE standard, be applied. Snyder NO vote: The answer makes rounding mode changes pointless. The work-around usually advanced to cause rounding mode changes to have effect (but not advanced in the answer to the interpretation) is to store intermediate results that are computed with different rounding modes in VOLATILE variables if they are ultimately to be combined in a single expression. Subclause 5.3.19 states, in part, however, that "The VOLATILE attribute specifies that an object may be referenced, defined, or become undefined, by means not specified by the program." Setting the rounding mode is done by means that ARE specified by the program, so the advice is not germane. One who reads subclauses 5.3.19, 14.4, 14.11.6, and 14.11.21, and the answer to this interpretation, might not realize that the use of VOLATILE variables is required, under the present interpretation, for subclauses 14.4, 14.11.6, and 14.11.21 to be meaningful. A better answer would have been to amend 7.1.5.2.4 to require that all entities within the expression are evaluated with the same rounding mode, or to specify that quantities evaluated with different rounding modes cannot be considered to be mathematically equivalent, even if evaluated by textually identical expressions. This might require processors either to abandon certain optimizations, or to perform more detailed dataflow analysis that propagates rounding mode to determine when those optimizations are permitted. If the position implied by the answer to this interpretation is to be maintained, the absence of edits is entirely inadequate. The definition of VOLATILE must be changed to encompass actions that ARE specified by the program, and to encompass advice concerning rounding mode changes. Advice to store intermediate results that are computed with different rounding modes into VOLATILE variables, if they are to be combined in a single expression, must be included in subclauses 14.4 and 14.11.21. During the requirements phase for the 2008 standard, there was a request (in 04-219) for a "strict mode" similar to that described in section G.2 of the Ada standard, in which rounding mode settings would actually have an effect without needing to resort to VOLATILE variables. If a "strict mode" had been provided, it might have made sense to allow a processor to ignore rounding mode changes outside strict regions. A request for a "strict mode" will be presented during the requirements-gathering phase for the next revision of the standard, for this as well as other reasons. .................................................................... F03/0084: Replies from the editor John Reid writes: <<< The IEEE rounding mode on entry to the procedure may vary from call to call. The value of Z1 depends on this rounding mode. Therefore, the processor should not always print zero for Z1-Z2. Whether or not Z1 and Z2 have the PARAMETER attribute makes no difference. Yes, the processor is allowed to evaluate an expression in any mathematically equivalent way, but here the mathematics dictates that a particular form of rounding, defined in the IEEE standard, be applied. >>> No it does not. IEEE peculiarities play no part in the mathematical Reals. IEEE is merely one form of computer arithmetic. (It would make very bad mathematics, since IEEE numbers are not even a subset of the 2-point compactification of the Reals, thus nearly all mathematical identities and theorems about the Reals would get destroyed.) Computer arithmetic is *computational* not *mathematical*. ALL computer arithmetics frequently give different computational answers for mathematically-equivalent expressions. And I cannot believe you are again trotting out this nonsense saying constant expressions should not be treated as constant. If I have "REAL(KIND=INT(a+b)) :: x(INT(a+b)) = a+b; y=a+b", with a and b being floating-point named constants, I am not allowed to evaluate a+b at compile time? Surely you jest. Or I can in the KIND= but not in the array bound? Unless the array is in COMMON or has the SAVE attribute? Surely you jest even more. Or I can everywhere except in the "y ="? You cannot be serious. Furthermore, the rationale you are using is applicable to all routines regardless of whether they call IEEE_SET_ROUNDING and would thereby destroy many basic optimisations. You.Really.Can.Not.Be.Serious. .................................................................... F03/0103 Chen NO vote: The reason for the 'NO' vote on F03/0103 is because: Passing a polymorphic optional argument that is not present to a non-polymorphic optional dummy should be disallowed as it requires de-referencing the descriptor. There are rules that disallow passing a pointer dummy or allocatable dummy that is not present as actual argument to a nonpointer nonallocatable optional dummy (12.5.2.12p3 (7)/(8)). There should be a similar rule for prohibit passing a polymorphic optional argument that is not present to a non-polymorphic optional dummy. I am aware that adding a runtime checking can solve the problem, but it will impact the performance. .................................................................... F03/0120 Snyder comment: There are typos in the discussion following question (5). In the fourth line of the second paragraph delete "are" before "can". In the sixth line of the second paragraph after the example after question (5), replace "It" before "2" with "Is". In the third line of the third paragraph delete "of" before "different". .................................................................... F03/0121 Bader NO vote: The answer as a whole seems misleading; given the specification of the REAL intrinsic and existing rules for type conversions (or their absence) in expressions, the answer should simply be "yes". The reference to mathematically equivalent expressions is mostly irrelevant (since by parenthesization the programmer's purpose should very likely be achievable), and that to VOLATILE variables is simply unnecessary. Corbett NO vote: I previously voted for the answer given. Since then, I have been convinced I was mistaken. I no longer think that REAL(X), where X has type REAL but has a different kind type parameter value from that of type default real, should be considered mathematically equivalent to X. I now agree with Mr. Braams that the intrinsic function REAL should do a real conversion. I agree with Van that nothing in the standard or in the existing interpretations requires VOLATILE to force a conversion. Interpretation F90/000001 is the only interpretation I have found that addresses the issue, and it, of course, could not require the use of VOLATILE. I agree with John that VOLATILE should not be required to force a conversion. Long NO vote: Similar to F03/0084, this hinges on the meaning of "mathematical". I'm not convinced that a processor is allowed to treat X and REAL(X,wp) as mathematically equivalent. The REAL function (may) perform an operation that is outside the scope of normal algebra. Maclaren comment: The recommendation to use VOLATILE is wrong. There is a common myth in among C and C++ programmers and even in informative text in the standards that volatile implies this semantic, but it is not justified by their normative text, nor do all compilers support it. Fortran should not follow suit - in particular, Fortran 2008 5.3.19 makes no such guarantee. In particular, because 5.3.19 provides licence to the processor and not to the programmer, a compiler is at liberty to optimise all references to VOLATILE variables if it does not provide any method of accessing it other than those specified by the program. Regrettably, the correct response is: There is no feature in Fortran to provide this facility, though assignment to a VOLATILE variable will often work. On some processors, making that a BIND(C) variable in a module will be needed but, on a few, this recipe will not work at all. This should be addressed properly in a future revision. Muxworthy comment: Like Van, I find the Answer unsatisfactory although the outcome (no edit) is correct. The answer is Yes. This is stated clearly in 13.7.138. What a processor might or might not do behind the scenes is irrelevant. If it does not obey 13.7.138 it is non-standard- conforming. (We are talking about a high-level language, not C). Reid NO vote: I think it is unacceptable to recommend the use of the VOLATILE attribute for a variable that is referenced, defined, or becomes undefined only within the Fortran program. The desired effect may be obtained by assigning the intermediate result to a variable without the VOLATILE attribute because this rules out the exceptions explained in the final sentence of the first paragraph of the answer ("Furthermore, ..."). Snyder NO vote: The answer refers to subclause 7.1.5.2.4 without identifying that subclause: "the processor may evaluate any mathematically equivalent expression, provided that the integrity of parentheses is not violated," and uses that as justification for the answer. Subclause 7.1.5.2.4 is entirely irrelevant to the question. Subclause 4.1.2 specifies that "For each type there is a set of valid values." Subclause 4.2 specifies that "the set of values... depend[s] on the values of the parameters." Subclause 13.7.2, as amended by the answer to interp F08/0008, says, in part, "A program shall not invoke an intrinsic procedure under circumstances where a value ... returned as a function result is not representable by objects of the specified type and type parameters." Allowing the REAL intrinsic function to return a result that is claimed to have a specified kind, and a value that is not a member of the set of valid values for that kind, violates the requirements of subclauses 4.1.2, 4.2, and 13.7.1 as amended by interpretation F08/0008. An interpretation should not introduce an inconsistency that will later need to be resolved by yet another interpretation. Even if F08/0008 were to fail, the result of the answer to this interpretation would be to introduce a conflict to 13.7.1 status quo ante, which reads, in part, "A program is prohibited from invoking an intrinsic procedure under circumstances where a value to be returned in a subroutine argument or function result is outside the range of values representable by objects of the specified type and type parameters," and continues with caveats not germane to the present interpretation. The only reason ever to invoke the REAL intrinsic function with a real argument and a KIND argument is to produce a result with the specified kind, and a value that is a member of the set of valid values for that kind. This is exceedingly rare, except perhaps as an actual argument (where the processor must necessarily produce a value that is a member of the set of valid values, and additionally is represented by the specified type and kind), and therefore requiring processors to produce a value for the result of REAL that is a member of the set of valid values for the kind of the result would have no measurable effect on performance in any program other than an arcane SPEC benchmark. The answer should be "Although a processor is allowed to replace an expression with a mathematically equivalent expression, subclauses 4.1.2, 4.2, and 13.7.1 (or 13.7.1 as amended by interpretation F08/0008) require the value of the result of every intrinsic function to be a member of the set of valid values for the type and kind of the function result." No normative edits would be required, although it would be helpful to add a recommendation in a note (or a requirement) to 13.7.138p5 Case (i) that the result have a value that is not different from the argument by more than one unit in its least significant place (unless the argument is NaN), and that it be rounded according to IEC 60559:1989 and the rounding mode currently in effect if the IEEE_ARITHMETIC module is accessible (unless the argument is NaN). Advice in the presently proposed answer is offered to use the VOLATILE attribute. Subclause 5.3.19 states, in part, however, that "The VOLATILE attribute specifies that an object may be referenced, defined, or become undefined, by means not specified by the program." Invoking the REAL intrinsic function is a means that IS specified by the program, so the advice is not germane. One who reads subclauses 4.1.2, 4.2, 5.3.19, 7.1.5.2.4 and 13.7.1 would have no clue that the way to make REAL operate as essentially all users expect it to operate is to store its result into a variable that has the VOLATILE attribute! If one must have the presently proposed answer, having no edits is entirely inadequate. Subclause 5.3.19 must be amended to include effects that ARE specified by the program. Subclauses 5.3.19 and 13.7.138 must be amended to include advice to use the VOLATILE attribute to make REAL function as essentially all users expect it to. Further, there must be an explicit exemption for REAL in subclause 13.7.1, and maybe in 4.1.2 and 4.2 as well. A perverse reading of 13.7.1, adroitly sidestepping subclauses 4.1.2 and 4.2, might be that a function is allowed to return a value that is not a member of the set of valid values for the type and kind of the result, but that a program is not allowed to invoke the function in such a way as to produce that result. This would make it illegal instead of pointless to invoke the REAL intrinsic function with the hope to produce a value that is a member of the set of valid values for the kind of the result. That is, for example, that REAL is permitted to act consistently with the present answer to this interpretation, but a program is not permitted to invoke REAL(3.14159265358979323846264338d0,kind(1.0e0)) if the processor uses 32-bit IEEE arithmetic for default real, because the result would not be a member of the set of valid values. If so, in order to detect programs that are not standard conforming, a helpful processor should announce an error in this circumstance, which requires producing a value that is a member of the set of valid values, and comparing it to the proposed result value instead of using it as the result value. One might argue that 13.7.1 was aimed, for example, at SQRT(-1.0), for which the mathematical function approximated by the intrinsic function has no values that are representable by the type and kind of the result. But it doesn't say so, and that argument does not reasonably apply to REAL. Since 13.7.138p5 Case (i) explicitly says that REAL produces an approximation to its argument, it is more reasonable for REAL(3.14159265358979323846264338d0,kind(1.0e0)) to produce an approximation that is a member of the set of valid values for the kind of the result, than for its invocation to be prohibited, or for it to produce a result that is not a member of the set of valid values for the kind of the result. If a processor absolutely must reduce REAL with a real argument to the identity operation under certain circumstances, a command-line argument to cause this behavior could be provided, with a caveat that using that setting admits behavior that is not consistent with the standard. .................................................................... F03/0121: Replies from the editor <<< I think it is unacceptable to recommend the use of the VOLATILE attribute for a variable that is referenced, defined, or becomes undefined only within the Fortran program. The desired effect may be obtained by assigning the intermediate result to a variable without the VOLATILE attribute because this rules out the exceptions explained in the final sentence of the first paragraph of the answer ("Furthermore, ..."). >>> Well no. Inter-statement optimisation is alive and well (re, in spite of F90/000001: some vendors have to compete on SPEC benchmarks and the like!), and the people moaning about the REAL() intrinsic not doing what they want frequently also want the optimisation cranked up to that level. In that case, VOLATILE is something that does, in fact, work. One might plausibly argue that we are being more helpful here than we need to. Nick opined: <<< ... is a common myth in among C and C++ and even in informative text in the standards that volatile implies this semantic >>> If informative text in the standard implies this semantic, that is a clear indication of the intent of the C committee. <<< but it is not justified by their normative text, >>> That is your opinion. You might or might not be right. My understanding of the normative text is otherwise i.e. the same as the informative implication. I might or might not be right. Under the circumstances, since this is the Fortran committee not the C committee, we should take the informative text as being correct rather than what some of the barracks-room lawyers say. <<< nor do all compilers support it >>> Many compilers have many bugs in many areas, and volatile is no exception to this. Indeed, papers have been written on such very topics. However, this case is very simple (no multi-threading required!) and in my experience it does work reliably. .................................................................... F08/0004 Corbett NO vote: I agree with the answer given, but I think the edit as written is likely to confuse readers. Given just the edit without the context of the interpretation, I would be hard put to figure out what it meant. I suggest the following alternative edit: If ASSOCIATED is invoked with two actual arguments and the argument corresponding to TARGET is a pointer, TARGET shall be considered to be a present pointer. .................................................................... F08/0008 Corbett comment: I agree with the answer given, but I shall note that the conditions given could be tightened. Specifically, the sentence If an IEEE NaN is assigned or returned, the actual arguments were finite numbers, the intrinsic module IEEE_ARITHMETIC is accessible, and the exception IEEE_INVALID is supported, the flag IEEE_INVALID shall signal. could say If an IEEE NaN is assigned or returned, the actual arguments were (possibly infinite) numbers, the intrinsic module IEEE_ARITHMETIC is accessible, and the exception IEEE_INVALID is supported, the flag IEEE_INVALID shall signal. The edits as written are correct, just not as tight as they could be. .................................................................... F08/0032 Bader comment: The additional constraint C1276b at first surprised me, since it seemed at first sight not to be connected with the problem dealt with in this interp. Rereading F08/0033 - which is incorporated in corrigendum 1 - it seems this must be included for similar reasons as the INTENT(OUT) case dealt with there. Still, this new restriction as well as the one introduced in F08/0033 seems a rather large hammer, because it also impacts the case where no finalizers at all are defined (and of course there now is the incompatibility with F2003). Therefore I wonder whether it would not be better to fix the finalizer part of the scheme by requiring that if a pure finalizer is defined for some type, any extension type that has a finalizer must also use a pure procedure for it. This would be a much smaller-impact change if feasible, but of course would imply re-working of F08/0033 as well.