J3/01-224 Date: 29-May-2001 To: J3 Members From: interp/Stan Whitlock Subj: Results of the F95 interp letter ballot #4 Here are the results of J3 letter ballot #4 on Fortran 95 interpretations that closed on 18-May-2001. If I have transcribed a vote or a comment incorrectly, please let me know. J3 rep 0 1 1 1 1 1 2 2 2 2 2 2 2 2 8 8 8 8 8 9 9 9 9 JP 2 0 1 2 8 9 0 1 2 3 4 5 8 9 1 5 7 8 9 0 1 2 3 06 Rich Bleikamp Y C Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Malcolm Cohen Y Y Y Y C Y Y Y Y Y Y Y Y Y C C C Y Y Y C N Y Y Craig Dedo Y N Y Y N Y Y Y Y N Y N Y Y N Y Y Y Y N N C N Y Dick Hendrickson Y N Y Y N Y Y Y Y Y Y N Y Y N Y N Y Y N C N C Y Kurt Hirchert Y Y Y Y Y Y Y N Y N N Y Y N N Y C Y Y Y N Y C Y Larry Meadows Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Dan Nagle Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Mallory North Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Mike Ross Y Y Y Y C Y Y Y Y Y Y Y Y Y Y Y N N Y N Y N N Y Brian Smith/Jeanne Martin ** no ballot received ** Van Snyder Y Y Y Y C Y Y Y Y Y Y Y Y Y C C Y Y Y N Y Y Y Y Jon Steidel/Bill Long Y N Y N C Y Y N Y N Y N Y Y Y Y N N Y N Y N N Y Toon Moene Y N Y Y Y Y Y Y Y Y Y N Y Y Y Y N Y Y Y Y Y Y Y Stan Whitlock Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y where Y means "yes" C "yes with comment" N "no with comment" The comments are attached below in the same order as the table above. John Reid and Rich Maine's e-mail comments are included, even though neither has a vote. The summary of DRAFT results is as follows: P = passed C = passed as amended F = further consideration 0 1 1 1 1 1 2 2 2 2 2 2 2 2 8 8 8 8 8 9 9 9 9 JP 2 0 1 2 8 9 0 1 2 3 4 5 8 9 1 5 7 8 9 0 1 2 3 06 Y F Y F F Y Y F Y F F F Y F F C F F Y F F F F Y The interps marked "P" can be considered by WG5 at John Reid's convenience. The interps marked "F" will be reconsidered at or before J3 meeting #157 by the /interp committee who will decide if the status becomes "withdraw for more work", "passed as amended", or "passed as printed". /Stan ********************************************************************** Number Title 000010 Meaning of embedded blanks in namelist input name RichB's YES comment on 000010 COMMENT: I do not see the ambiguity John Reid refers too, but I do not object to his proposed edit either. Craig's NO vote on 000010 NO: I agree with Dick Hendrickson and John Reid. I support John Reid's proposed edit. If the proposed edit is included, then I will change my vote to "Yes". DickH's NO vote on 000010 NO: I agree with John Reid's comment. It is confusing when the second line in the section refers to "object name or subobject designator". The first line of 10.9 refers to "name-value sequences" and then gives two forms for "name" in the second line. I think John's edit clarifies the intent. I also think it is minor enough that /INTERP could paste it in the answer unless someone disagrees. EDIT: Replace the last sentence of subclause 10.9.1.1 [179:32-33] by In the input record, each object name or subobject designator may be preceded and followed by one or more optional blanks but shall not contain embedded blanks. BillL's No vote on 000010 NO: We would prefer the EDIT text supplied by John Reid. Also, the ANSWER: contains a reference to section 19.9.1.1, which should be 10.9.1.1. Toon's NO vote on 000010 NO: This is something that will keep confusing people who use fixed format source code, because the rules are much stricter than for variable names / array items in (fixed form) source code. However, we think the answer is correct. Nevertheless, we prefer John Reid's edit. John Reid's e-mail comment on 000010 Section 10.9 starts (178:30) with the terminology of the rest of the standard and uses the words 'object name or subobject designator'. Unfortunately, it goes on to use 'name' for either of these. This results in an ambiguity at 179:32-33. It is used with its proper meaning on lines 29 and 30, and with its more general meaning on line 31. I think that an edit is essential. I suggest: EDIT: Replace the last sentence of subclause 10.9.1.1 [179:32-33] by In the input record, each object name or subobject designator may be preceded and followed by one or more optional blanks but shall not contain embedded blanks. 000012 Evaluation of Intrinsic Procedures BillL's NO vote on 000012 NO: The proposed text for the ANINT function could be interpreted to say that the value returned is of type integer, though it is actually REAL. The word 'integer' needs to be replaced by 'whole number'. 000018 ELEMENTAL procedures with no arguments Malcolm's YES comment on 000018 COMMENT: I agree with John Reid's comment. Craig's NO vote on 000018 NO: I agree with Dick Hendrickson and John Reid. I support John Reid's proposed edit in 12.4.3 [206:7-10]. DickH's NO vote on 000018 NO: Typo: In the first line of the interp "IS" should be "ISO". I also agree with John's comment. We should cover the case where there are arguments that don't match with OUT arguments. Replace the final sentence of subclause 12.4.3 [206:7-10] by: A reference to an elemental subroutine (12.7) is an elemental reference if there is at least one actual argument corresponding to an INTENT(OUT) or INTENT(INOUT) dummy argument, all such actual arguments are arrays, and all actual arguments are conformable. Mike's YES comment on 000018 COMMENT: none received Van's YES comment on 000018 COMMENT: Modulo typos -- either "h" -> "h2" everywhere, or vice-versa. BillL's YES comment on 000018 COMMENT: We would prefer the EDIT text supplied by John Reid. References to "h2" should be changed to "h", as pointed out by others. John Reid's e-mail comment on 000018 For the first edit, I think we need to allow for the case where there are some actual arguments, but none correspond to intent(inout) or intent(out) dummy arguments. I suggest: Replace the final sentence of subclause 12.4.3 [206:7-10] by: A reference to an elemental subroutine (12.7) is an elemental reference if there is at least one actual argument corresponding to an INTENT(OUT) or INTENT(INOUT) dummy argument, all such actual arguments are arrays, and all actual arguments are conformable. I think the line number for the second edit should be 30. The sentence in parentheses after the second edit should be deleted (it is a note to J3). 000021 Restrictions on on END INTERFACE Kurt's no vote on 000021 NO: This is one of two interpretations in this batch where I disagree with the proposed technical outcome. I believe that ".ne." should be considered "identical" to ".NE." (because they are constructed from characters that are syntactically equivalent), but that it should not be considered "identical" to "/=" (because they are _different_ syntactic constructs that happen to refer to the same semantic concepts). [I don't expect to prevail on this point, but I just couldn't bring myself to approve example 1.] BillL's NO vote on 000021 NO: The proposal to allow the equivalence of .NE. and /=, and related pairs, seems misguided. While some implementations might choose to allow this equivalence as an extension, the stricter requirement of textual equivalence is valuable to the user and should be allowed for a standard conforming processor. Including the generic name on an END INTERFACE allows a user to easily locate the beginning and end of the interface in a text editor. Relaxing the standard to allow textually inequivalent names diminishes this functionality, and does not supply any compensating benefit. 000022 Use of NULL() as initialization John Reid's e-mail comment on 000022 In the first edit, R429a should be on one line. 000023 Termination of the previous record by a WRITE statement Craig's NO vote on 000023 NO: I agree with Bill Long and Jon Steidel. Kurt's NO vote on 000023 NO: 1. The first question can be read in more than one way, so the answer to that question needs to make clearer which way we have read it. (I.e., a _processor_ is not permitted to unilaterally terminate the current record under these circumstances, but the _program_ is permitted to do so explicitly.) 2. I am not a fan of the wording of the edit. I would prefer something to the effect that the record becomes the last record and the data transferred by the write statement becomes the last data in the record. (I.e., I would prefer not to even suggest that there might be existing data beyond the current point in the record.) BillL's NO vote on 000023 NO: The answer to the first question, that a new record is not started, is correct, but the answer to the second question and the corresponding EDIT are not correct. Consider the following different, but related, example: program write_write write (10,"(a,t1,a,a)") "XXXXXXXXX", "ABC", "DEF" write (10,"(a,t1,a)",advance='no') "XXXXXXXXX", "ABC" write (10,"(a)") "DEF" end The output from this program is ABCDEFXXX ABCDEFXXX From the description of Position editing (10.6.1) it is clear that the output following the tab does not cause the deletion of the final XXX characters from the record. The fact that the second output record is created by a non-advancing write followed by an advancing write is not operationally different from the single advancing write that created the first record. The fundamental difference between this example and the question considered in the interp is the mechanism by which the current location in the record is established prior to the final advancing write statement. It would be inconsistent to have one case preserve previously existing characters in the record and the other case to require the opposite. To avoid this inconsistency, the answer to Question 2 should be Yes. The proposed EDIT should be deleted. 000024 Termination of a partial record by a CLOSE, BACKSPACE, ENDFILE, or REWIND statement Kurt's NO vote on 000024 NO: I am unhappy with the edit (but not its intent). The idea of changing the behavior of a WRITE statement that has already been executed seems a bit lame. An additional advancing WRITE that transfers no data might be a better descriptive model. 000025 List-directed input: types of variables corresponding to repeated values Craig's NO vote on 000025 NO: I agree with Bill Long and Jon Steidel. DickH's NO vote on 000025 NO: I don't believe the answer actually answers what I believe is the question. I think the answer to the question is found in the first sentence of the answer and should be made clear with an example. I think his question is along the lines of: given read(*,*) integer_variable, real_variable is 2*7 acceptable? or maybe 2*7.0 ? I think that is the real question, not how do you determine the type of the values. I agree that the discussion of type ambiguity when one of the variables is a character variable is interesting and that the supplied edit needs to be made. But I think there should be more discussion of the obvious cases. I would propose changing the first line from "No, the variables are not required to be of the same type, but the" to "No, the variables are not required to be of the same type, section 10.8, [175:8] states that the effect of the r*c form is as if c were repeated r times. Each effective instance of c must meet the form requirements of 10.8.1 corresponding to the corresponding input item. Note that the" ... BillL's NO vote on 000025 NO: An input item of 3*c should have the same interpretation as the following sequence c c c The proposed EDIT would make these two forms different, is completely contrary to the common expectation as to how repeat factors in input operate, and would cause existing implementations to become non-standard. The current text (175:7-8) "The r*c form is equivalent to r successive appearances of the constant c, ..." is correct and does not need modification. The definition of constant (R306 23:8) is ultimately in terms of graphic characters (21:7). A particular sequence of graphic characters (.true., for example) can be valid as a value for more than one data type (character and logical, for example). The flawed part of the answer to the question states "... the type of the repeated constant is either a literal constant, or a nondelimited character constant, but not both...". But this is not what the standard says. There is no "either" and no "but not both" in the standard text, and that text should not be there. A better answer would be: "No, there is no such restriction. The cited Fortran 90 implementation is non-conforming." No EDIT is required. Toon's NO vote on 000025 NO: Despite the J3 vote in meeting 156, we think that the analysis by Bill Long c.s. is correct. Rich Maine's e-mail comment on 000025 On item 25, I distinctly disagreed with Bill Long's analysis, but I do think that it points out a flaw in the wording that perhaps merits further improvement. The fields in formatted input records are *NOT* constants. Literal constants appear only in source code and, although their syntax is similar in many ways to the syntax of formatted I/O fields, it is not the same (for example, you can't have kind numbers in I/O fields). We went to a lot of trouble in one of the f90 interps to get rid of most of the places where I/O fields were incorrectly referred to as constants. Looks like we missed one. That omission appears to be what Bill is basing much of his answer on. Probably we ought to fix it and get the word "constant" out of this text. I could actually "buy" either answer to this interp, but I don't "buy" an analysis based on the inappropriate use of the word "constant". On item 25, I do think it was an error. I can't imagine this as an intentional specification - it probably just "fell out" of the wording when someone forgot to mention the cases where neither "yes" nor "no" make sense. On the other hand, I don't really much care. Probably the reason that nobody griped before is that it only comes up when the user "asks" (with inquire) a "stupid" question. It would be a pretty strange program that asked, for example, about pad= for an unformatted file and then cared what the answer was. I can imagine code that asks (perhaps because the same INQUIRE statement is used for both formatted and unformatted files), but darned if I can figure out what constructive use would be made of the answer. 000029 Nested Derived Types and Defined Assignment Kurt's NO vote on 000029 NO: I agree with the technical intent of this response, but I have trouble with the statement "there is no ambiguity or error in the standard." In at least one sense, it may have been an error to make the default interpretation of assignment in this case intrinsic assignment instead of some kind of implicit defined assignment. It's just that this is not the kind of "error" we can fix in a corrigendum. 000081 Definition status of derived-type objects with pointer components Malcolm's YES comment on 000081 COMMENT: The last sentence in the question should say "containing" instead of "contains". Re Kurt's suggestion that the pointer components should have some "defined" association status; they do, it's called "undefined pointer association status". It differs significantly from the "undefined definition status" of variables in that it is not valid to "assign from" an undefined variable, but it is valid to "pointer-assign from" an undefined pointer. Since we are not allowed to do X = Y unless Y is defined, and for derived types this consists of doing assignment of nonpointers and pointer assignment of pointers, we do not want to end up with the silly situation where it is ok to do assignment by writing out each component by hand but not ok to do it by writing it as a single statement. Thus pointer association status of components ought not to have any effect on the definition status of the parent. Craig's NO vote on 000081 NO: I agree with Dick Hendrickson and Kurt Hirchert. DickH's NO vote on 000081 NO: I'm really unhappy with the briefness of the answer. "No pointer components do not affect the definition status of an object. Edits are supplied to clarify this situation." Where in the standard does it say that pointer components don't affect the definition status? Why not point the questioner to that section? The edits don't appear to clarify something; they appear to change something. This calls for an actual explanation of why things are being changed. I think 111:7-8 hints at the answer, but I don't understand the example and answer well enough to be sure. Maybe it would be clear to me if the answer discussed whether or not each assignment statement is standard conforming in TYPE t REAL,POINTER :: x END TYPE TYPE(t) var1,var2,var3, var4 NULLIFY(var1%x) var2 = var1 var3 = var4 Kurt's NO vote on 000081 NO: This is one of two interpretations in this batch where I disagree with the proposed technical outcome. The proposed edit moves from giving too much weight to pointer components to ignoring them completely. I believe that for a derived-type object to be defined, its pointer components should have a defined pointer association status. Van's YES comment on 000081 COMMENT: I agree with the edits, but the answer seems to be either self-contradictory or incomplete. The question is "Should the definition status of an object contain pointer components depend on the pointer association status of its pointer components and not their definition status?" Judging from the edits, the answer should be "Neither...." Also, shouldn't the "contain" in the question be "containing"? John Reid's e-mail comment on 000081 The sentence in parentheses after the edits should be deleted (it is a note to J3). 000085 Public components of private types Malcolm's YES comment on 000085 COMMENT: I agree with the comment that the title ought to be "Public components of inaccessible types". Van's YES comment on 000085 COMMENT: Neither the question nor the answer appear to have anything to do with private types. SHouldn't the title be "... inaccessible types"? 000087 MOD and MODULO intrinsic functions with zero divisor Malcolm's YES comment on 000087 COMMENT: The protestations that the described semantics of MOD are correct would be more convincing if the majority of F77 compilers actually did this. With the 6 F77 compilers I have easy access to, including a well-known free one and various "market leaders", MOD with an integer zero P produces messages ranging from a simple "Abort" to "integer divide by zero"; NONE (!) of them produce a processor-defined value for MOD with an integer zero divisor. With the half-dozen Fortran 90 compilers I have access to, "INTEGER :: X = MOD(1,0)" failed even to compile on all but one. Even if we are talking about floating-point MOD at runtime on an IEEE machine, if IEEE traps are enabled the program generally dumps core (if traps are not enabled, non-conformant output results). Never mind non-IEEE machines. Prohibiting a zero divisor allows the processor to do "clever" things when appropriate on an IEEE machine for floating point, while allowing other processors and other situations to be handled with an appropriate error message (which is what they virtually all do anyway, standard to the contrary!) DickH's NO vote on 000087 NO: This answer is completely wrong. How can we say the intent was "not intended to be standard-conforming"? Going all the way back to FORTRAN 77 the definition for MOD said "undefined when the value of the second argument is zero". F90 replaced "undefined" with "processor dependent". The words are clear, there is no "mistake" in the standard. We may have wished it was done differently in the past, but it's been clear for almost 40 years. There's no reason to change it. Compilers are NOT required to compute MOD(A,P) as A-INT(A/P)*P, that's a mere suggestion (see the answer to 000012!). They can evaluate it anyway they like and optimize it also. This would be a good change to make for F2K. But it's not an error in F95; it's merely a feature we wish were different and should be treated like all the other things we are changing to make F2k. Kurt's YES comment on 000087 COMMENT: Does this make Fortran 95 incompatible with Fortran 90 in a new way? Mike's NO vote on 000087 NO: none received BillL's NO vote on 000087 NO: The proposed changes represent a change to the standard that is too significant for an interp. Also, the discussion appears to be focused on INTEGER arguments, though REAL arguments to MOD and MODULO are also supported. Division by zero is supported for REAL values on some architectures. It would seem that the current "processor dependent" text would be preferred in that case. Toon's NO vote on 000087 NO: We agree with Dick Hendrickson's and Bill Long (c.s.)'s analysis here - in spite of my vote in meeting 156. There's no need to change the F95 Standard in this respect. 000088 INTRINSIC statement and attribute Mike's NO vote on 000088 NO: none received BillL's NO vote on 000088 NO: Changing "the name shall either appear in an INTRINSIC statement or be given the INTRINSIC attribute in a type declaration statement in the scoping unit" to "it shall have been explicitly declared to have the INTRINSIC attribute" would seem significant enough to warrant an EDIT to the standard only if there were mechanisms other than those cited in the current text for giving a name the INTRINSIC attribute. The answer to the question is correct, but the EDIT seems unnecessary. John Reid's e-mail comment on 000088 There is a typo in the last line of the edit. 000090 What do ``Prior Specification'' and ``defined previously'' mean? Malcolm's YES comment on 000090 COMMENT: Much though I appreciate the wish for generous semantics and the desire to create more work for vendors, I see no more obvious syntactic item than to which "specification" should refer. The question itself could go a bit further into the spectrum of choices, which I would have lined up as INTEGER,PARAMETER :: A(xyz1,xyz2) = SIZE(A) INTEGER,PARAMETER :: A(xyz1:xyz2,LBOUND(A,1)) INTEGER,PARAMETER :: A(xyz1:LBOUND(A,1)+10) As an implementor, I should certainly view with horror the suggestion that I should have to handle enquiries on array declarators before I'd finished analyzing them. Craig's NO vote on 000090 NO: I agree with John Reid, Dick Hendrickson, Bill Long, and Jon Steidel. DickH's NO vote on 000090 NO: The first answer says "A prior specification refers to a specification in a previous or in a previous statement. None of the examples are legal." This at least needs a reference so we can tell that it means a previous . I don't see anything in the cited text that implies the answer. In fact, had the phrase "to the left of" been included in the answer I would reach a different conclusion. Surely in integer :: P(10) = size(P) the "(10)" appears "to the left of" the size function. How does the answer apply to integer, dimension(10) :: p = size(p) or integer, dimension(10) :: q, p=size(p) or dimension p(10) integer :: p = size(p) I think consistency and usability require Van's interpretation of "to the left of". We should at least make John Reid's edits to clarify what the (wrong) answer is. Mike's NO vote on 000090 NO: none received Van's NO vote on 000090 NO: (1) The utility of a less strict answer to question 1 is obvious. (2) Several compilers accept the statement in example 1 and other subsequent similar ones. Therefore there appears to be no compelling technical reason for the answer to be so strict. (3) The answer leads to disturbing/amusing anomalies: INTEGER, PARAMETER :: P = BIT_SIZE(P) is prohibited, but INTEGER :: P PARAMETER ( P = BIT_SIZE(P) ) is permitted. I have no objection to the answer to question 2. BillL's NO vote on 000090 NO: The ANSWER text provided is potentially inconsistent with the sections on initialization expressions and specification expressions. The edits provided by John Reid resolve those issues, and need to be included. John Reid's e-mail comment on 000090 I think an edit is needed. I suggest adding the following at the end: In the edits, we have taken the opportunity to correct the text in the first lines of the referenced paragraphs in 7.1.6.1 and 7.1.6.2. EDITS: Page 94, Subclause 7.1.6.1. In the first line of the last paragraph of page 94 [94:38], replace 'for a type parameter' by 'that depends on a type parameter'. Page 94, Subclause 7.1.6.1, replace the last sentence of page 94 [94:40-41] by 'The prior specification may be to the left of the inquiry function in the same statement, but shall not be within the same .' Page 96, Subclause 7.1.6.2. In the first line of the last paragraph of the subclause [96:32], replace 'for a type parameter' by 'that depends on a type parameter'. Page 96, Subclause 7.1.6.2, replace the second sentence of the last paragraph of the subclause [96:34-35] by 'The prior specification may be to the left of the inquiry function in the same statement, but shall not be within the same .' 000091 Definition of "present" is defective Craig's NO vote on 000091 NO: I agree with John Reid and Dick Hendrickson. DickH's e-mail comment on 00091 COMMENT: I agree with John Reid that "in an instance of a subprogram" should be retained; it makes it clear that it is a property of a specific call (perhaps recursive) to the routine, not a general property. I also like his attempt at defining absent, but think it's an unnecessary change for F95. Can we do that when we apply the edits to F2K? Kurt's NO vote on 000091 NO: I think the edit is defective. In the example, I want it to be legal to test present(A) in subroutine S11. I think the allowance for host association in the proposed edit is in the wrong place to permit this. John Reid's e-mail comment on 000091 I think the edit should define 'absent', used a lot in 13. It always easier to understand something expressed as a positive. Also, I think the words 'in an instance of a subprogram' should be retained. I suggest: [202:43-45] Replace the first sentence of 12.4.1.5 by A dummy argument is <> in an instance of a subprogram if it is (1) not associated with an actual argument, or (2) is associated with an actual argument that is (a) a dummy argument that is absent or (b) an entity that is host-associated with a dummy argument that is absent. Otherwise, it is <>. The same edit is needed in the glossary: In Annex A, page 293, add as the first item: <> (12.4.1.5): A is <> in an if it is (1) not with an , or (2) is associated with an actual argument that is (a) a dummy argument that is or (b) an entity that is host-associated with a dummy argument that is . In Annex A, page 299, replace the item for <> by: <> (12.4.1.5): A is <> in an if it is not . 000092 Values of the PAD= Specifier in the INQUIRE Statement Malcolm's NO vote on 000092 NO: I disagree that this is an error. Fortran 90 is unambiguous and consistent, and the issue was not revisited for Fortran 95. This would render all existing Fortran 95 implementations non-conformant 4 years after publication. Craig's YES comment on 000092 COMMENT: I disagree with those who object because it changes an existing standard too much. My basic philosophy in situations like this is that if we find something that is an obvious mistake, we should assertively and forthrightly fix the mistake at the earliest opportunity. That opportunity is now. We discussed this extensively both in subgroup and in plenary. We passed the same fix for Fortran 2000 (F2K), in paper 01-111r3, even before we started work on Interpretation 92, in paper 01-172. 01-111r3 passed unanimously on March 20 and 01-172 passed unanimously on March 22. In both cases, there was extensive discussion of what should be the proper value of the PAD= specifier in an INQUIRE statement if the file or unit is not connected or is connected for unformatted I/O. During debate, we came to a consensus that in those cases a value of "YES" is misleading. The votes on both papers were taken with everyone having full knowledge of the consequences of approving these papers. Since this change definitely will be in Fortran 2000, the issue is not a matter of whether this change in PAD= will happen but when. If we do not retrofit this change into F95, vendors will still be required to make the change in F2K. Delaying implementation until F2K may involve some additional complexities. Since F2K is a large change to the language, vendors most likely will implement the F2K features in a series of compiler releases over a period of years. This process has already started in a significant number of F95 compilers. If this fix is delayed until F2K, vendors will need to choose which release they make the change in. How long should they stick with the F90 rule and when should they adopt the F2K rule? Doubless different vendors will choose different times, thus creating portability problems for application developers. Therefore, the simplest and most straightforward approach is to make this change in Fortran 95. DickH's NO vote on 000092 NO: This isn't the time to introduce incompatibilities with F90. The standard is perfectly clear about what is going on and what the results of inquire with pad= are. We merely think a bad choice was made in the 80's. The time to fix these things in in a new revision of the standard; not as an "interpretation". Defer this to F2K when people will expect to find surprises. Mike's NO vote on 000092 NO: none received BillL's NO vote on 000092 NO: The proposed change represents a significant improvement and should be made in the F2K standard. However, the change introduces too great of an incompatibility with the current standard to be made through an interp to F95. 000093 Allocatable arrays as actual arguments Craig's NO vote on 000093 NO: I agree with Dick Hendrickson. DickH's YES comment on 000093 COMMENT: I prefer a variation of John Reid's edit [80:34] Change "; it" to ". It shall not be supplied as an actual argument except to certain intrinsic inquiry functions. It" ^^^^^^^ Kurt's YES comment on 000093 COMMENT: The edit needs to be better identified for inclusion in a future corrigendum. It is in item (1) in the list in clause 6.3.1.2. Mike's NO vote on 000093 NO: none received BillL's NO vote on 000093 NO: The program is non-conforming because the argument to the SHAPE intrinsic function is not allocated, as is required in 267:7. If the dummy argument, X, is neither referenced nor defined in the subroutine, it is not clear why the code should be illegal. John Reid's e-mail comment on 000093 I do not know what 'as specified' in the edit means. We just need to exclude everything other than intrinsic inquiry functions. The text in 13 does the further exclusions that are needed, e.g. for SHAPE. I suggest: [80:34] Change "; it" to ". It shall not be supplied as an actual argument except to an intrinsic inquiry function. It" The sentence in parentheses after the edits should be deleted (it is a note to J3).