J3/12-194 To: J3 Subject: Result of WG5 interpretations ballot 4, N1934 From: Malcolm Cohen Date: 2012 October 16 Reference: WG5/N1944 1. Introduction This paper contains a revision of the WG5 paper N1944, recording the result of WG5 interpretations ballot 4 (paper N1934), after consideration by J3/INTERP. Section 2 contains a copy of N1944 with the final results recorded. Interpretations F08/0054, F08/0055, F08/0057, F08/0058, F08/0059, F08/0064, and F08/0067 pass with minor modifications; section 3 contains the revised versions of these interpretations. 2. Final ballot results for N1934 (modified N1944) Key for the Result line: Y vote passes unconditionally. CY vote passes unchanged after J3/INTERP review of the comments. CM vote passes with minor modifications after J3/INTERP review. N vote fails. Returned to J3 for further work. ? result will be decided by the Convener and /INTERP. The comments are given in alphabetic order, which sometimes causes forward references to later comments. F08/ F08/ F08/ F08/ F08/ F08/ F08/ F08/ F08/ F08/ 0043 0048 0054 0055 0056 0057 0058 0059 0060 0061 Chen Y Y Y Y Y Y Y Y Y Y Cohen Y N Y C Y Y Y Y Y Y Corbett Y C N Y N Y N Y Y Y Long Y C Y C Y Y Y C Y Y Maclaren - Y Y - - Y Y - Y Y Muxworthy C Y C C Y C Y Y Y Y Reid Y Y Y Y Y Y Y Y Y Y Snyder Y Y Y Y Y C C Y Y Y Whitlock Y Y Y Y Y Y Y Y Y Y Result CY CY CM CM CY CM CM CM Y Y F08/ F08/ F08/ F08/ F08/ F08/ F08/ F08/ F08/ F08/ F08/ 0062 0063 0064 0065 0066 0067 0068 0069 0070 0072 0073 Chen Y Y Y Y Y Y Y Y Y Y Y Cohen Y Y Y Y Y Y Y Y Y Y C Corbett Y N C Y Y C Y Y Y Y Y Long Y Y C Y Y Y C Y Y C Y Maclaren Y C Y C - - - - - Y - Muxworthy Y Y Y Y Y Y Y Y Y Y Y Reid Y Y Y Y Y Y Y Y Y Y C Snyder Y Y Y Y Y C Y Y Y Y Y Whitlock Y Y Y Y Y Y Y Y Y Y Y Result Y CY CM CY Y CM CY Y Y CY CY Comments and reasons for NO votes F08/0043 Muxworthy comment: Why not remove C1229 now? It takes only three small edits. Reply from the editor: Because there is no defect in the standard so it would be an unnecessary edit. Editorial fixes like removing redundant text is more efficiently done via the editorial process for the next revision. (It might not necessarily be best to remove the specific redundancy identified by the interp question.) .................................................................... F08/0048 Cohen reason for NO vote: Bill Long writes: "Does the interp open the door to a whole room full of "clever programming" opportunities? For example, you can pass a different element on each image." Yes, that is precisely why I voted against this interp at every previous opportunity. I think it is a bad idea to provide such a confusing feature with so few redeeming qualities. Corbett comment: While I see no problem with implementing the feature as described in the proposed interpretation, I would agree to defer approval of the interpretation until after further consideration of Malcolm's objections. Long comment: I think it would be clearer if the last word of the edit were changed from "array" to "coarray". I know that further restriction could be deduced from 12.5.2.8p1, but why be unnecessarily obscure? Does the interp open the door to a whole room full of "clever programming" opportunities? For example, you can pass a different element on each image. An only slightly more complicated example than the outline in the interp is: program test interface subroutine sub (x) real x(10)[*] end subroutine end interface real :: x(100)[*] integer :: ti ti = this_image() x = 666 call sub (x(ti)) print *, "For image ", ti, "x(1:15) = ", x(1:15) end program test subroutine sub(y) real y(10)[*] y = 999 end subroutine sub Testing this out does lead to the expected results: > aprun -n4 ./a.out For image 3 x(1:15) = 2*666., 10*999., 3*666. For image 4 x(1:15) = 3*666., 10*999., 2*666. For image 2 x(1:15) = 666., 10*999., 4*666. For image 1 x(1:15) = 10*999., 5*666. > If sub contained coindexed references to y, it could get confusing about what elements of x you are really accessing on the remote images. In principle this is OK, but I wanted to be sure we were all agreeing to the same consequences for this interp. Reply from the editor re: Changing "contiguous array" to "contiguous coarray": The editor will change it back, since that would make this sentence confusing and at the same time partially duplicate the technical content of the previous sentence. It is ALWAYS a bad idea to duplicate requirements! There is no obscurity, the previous sentence is perfectly clear. It does not have to be stated again. .................................................................... F08/0054 Corbett reason for NO vote: I think that the proposed interpretation is a misinterpretation of what was intended by paper 02-144. As I have said before, I think that the paper was sloppy in that it did not mean a procedure reference when it used the term "referenced." I think that by "referenced," it meant any use other than a declaration. Nonetheless, I think the difference between the proposed interpretation and what I think was intended in the paper is small enough that I would not vote "no" on this interpretation for that reason. The reason I am voting "no" on this interpretation is that the proposed edits are incorrect. The text of the relevant portion of the standard is also erroneous. I assume that the term "procedure identifier" is meant to include operators and the names of procedures and procedure pointers. The problem is that a generic identifier appears to fall under this definition. A generic identifier does not have either implicit or explicit interface. I do not see how the proposed edits apply in the case of a generic identifier. As I thought about the issue, I convinced myself that the property of having implicit or explicit interface should apply only to the names of procedures and procedure pointers, and not to procedures themselves. Because of renaming, a single procedure can have more than one name in a given scoping unit. The properties of each name might be different. For example, a function F might be identified by the names G and H in a scoping unit. The names of the dummy arguments of G and H might be different. Reply from the editor: > > I think that the proposed interpretation is a misinterpretation of > what was intended by paper 02-144. Paper 02-144 ***DID NOT INTEND TO MAKE A TECHNICAL CHANGE*** Not even a small one. (Either that or the authors secretly wanted a technical change and got it past the committee by subterfuge. I do not believe that is the case.) ... > The reason I am voting "no" on this interpretation is that the > proposed edits are incorrect. The text of the relevant portion of > the standard is also erroneous. > > I assume that the term "procedure identifier" is meant to include > operators and the names of procedures and procedure pointers. The > problem is that a generic identifier appears to fall under this > definition. A generic identifier does not have either implicit or > explicit interface. Huh? The edit says "Within the scope of a procedure identifier, THE PROCEDURE shall have an explicit interface" Nothing about generic identifiers having an explicit interface. > I do not see how the proposed edits apply in > the case of a generic identifier. Seems clear enough to me. > As I thought about the issue, I convinced myself that the property > of having implicit or explicit interface should apply only to the > names of procedures and procedure pointers, and not to procedures > themselves. Because of renaming, a single procedure can have more > than one name in a given scoping unit. The properties of each name > might be different. For example, a function F might be identified > by the names G and H in a scoping unit. The names of the dummy > arguments of G and H might be different. They would still both have explicit interfaces though... I am reluctant to completely rewrite the way the standard describes interfaces to procedures along the lines suggested, in an interp. I agree that the language could be better, but apart from not being entirely convinced that the suggested approach would actually be an improvement, I think that the right time for rewriting the whole method of description must be in a revision, not an interp. Muxworthy comment: In the first edit shift 'only' four words to the right? Reply from the editor: ok (the original is also ok, but this is marginally nicer). .................................................................... F08/0055 Cohen comment: In the edits, change "with d==0" to "with d equal to 0", twice. Long comment: Particularly for an interp about G output formatting, it would be very helpful to actually display the expected output. [Generally, when there is example code that has output, it would be helpful to state the correct output if the code is claimed to be conforming.] Muxworthy comment: Is it preferred style to use 'd==0' in narrative English in the edits (twice), rather than d=0? d is not a variable (although it could be represented by a character variable). Reply from the editor: I take your point, but actually I don't like "[with] d=0" much either; "[with] d equal to zero" would be better I think, and matches the wording in the later clause better. .................................................................... F08/0056 Corbett reason for NO vote: I continue to oppose this interpretation. I think the functionality it provides is too little to be worth the risk of misuse. I have yet to think of a case where I would want use the functionality provided. I can easily imagine cases where the wrong variable is used in the SOURCE= specifier and the error goes undetected. .................................................................... F08/0057 Muxworthy comment: It would be more in accordance with previous practice to number the new constraint C1504a. [Corrigendum 1 uses both upper and lower case suffices for new constraints. Presumably lower case is preferred.] Reply from the editor: I agree. I think we should use lower case for the suffices. Snyder comment: Does this need a compatibility caveat in 1.6? .................................................................... F08/0058 Corbett reason for NO vote: I continue to believe that removal of this restriction in Fortran 90 was deliberate. The restriction in FORTRAN 77 was intended to make it easier to write one-pass compilers. Many such restrictions were removed in Fortran 90. The restriction serves no purpose now. The restriction in the FORTRAN 77 standard is in paragraph 2 of Section 15.7.4. Snyder comment: Replace "program" in the first paragraph of the answer with "module". .................................................................... F08/0059 Long comment: The last sentence of the Answer should begin "Edits are" instead of "An edit is". There are two edits. .................................................................... F08/0063 Cohen comment on Corbett NO vote: > This interpretation upends the meaning of item (5) in Clause 10.7.2.1. > A similar argument could be made against any application of item (5). I disagree. F6.1 makes sense and according to item (5) will produce asterisks for large values e.g. 1e8. E10.2E2 makes sense and according to item (5) will produce asterisks for large enough values e.g. 1d200. F4.5 does not make sense. The standard does not make sense of F4.5, so it does not say *anything*. It would be a good idea to require F4.5 to produce 4 asterisks in the next revision, sure looks like a wart to me. Corbett reason for NO vote: This interpretation upends the meaning of item (5) in Clause 10.7.2.1. A similar argument could be made against any application of item (5). I am surprised anyone thinks that editing under an F4.5 edit descriptor should be permitted to produce anything other than four asterisks. Under the proposed interpretation, I have no idea what should be expected as a result of editing under an F4.4 edit descriptor. Maclaren comment: This is a good candidate for improvement in a future revision. .................................................................... F08/0064 Corbett comment: There should be no "their" in the sentence This relies on their being a difference between "no value" and "zero-length value". Long comment: Perhaps the original should have been "there". .................................................................... F08/0065 Maclaren comment: Upon checking on what this meant, I believe that the lists in tables 14.1 and 14.2 contain some errors. Specifically, I can see no reason for IEEE_GET_ROUNDING MODE and IEEE_GET_UNDERFLOW MODE not to be pure (but they aren't), but I can see good reasons for IEEE_SET_FLAG and IEEE_SET_HALTING_MODE not to be (and they are). However, even if true, that is a matter for a future revision. .................................................................... F08/0067 Corbett comment: I agree that the program should not be standard conforming, and I agree that the edit provided ensures that it is not. I do not agree with the rationale given for the answer. Whether the invocation of SUB2 in SUB1 does or does not require the shape of A depends on the argument passing conventions used by the processor. While all or almost all existing Fortran processors use copy-in/copy-out to pass the array argument to SUB2, the Fortran standard does not require a conforming processor to use copy-in/copy-out. Other argument passing conventions exist that do not require making a copy in this case. Those conventions do not require the shape or size of A to be known. Snyder comment: To clarify the answer, it would be helpful to replace ", and therefore the" by "because, in the absense of an explicit interface, the corresponding dummy argument is assumed to be nonpolymorphic, and therefore a copy consisting only of the declared type part of the actual argument is required. The" .................................................................... F08/0068 Long comment: I think that the second bullets in each of the two edits is trying to say that the dummy argument becomes associated with the part of the actual argument (target) with the declared type of the dummy argument. The current "declared type part of that actual argument (target)" could be confused to refer to the declared type of the actual argument. .................................................................... F08/0072 Long comment: It would be helpful to supply more explanation than just "No." for the answer. Specification of rank is allowed for a FINAL subroutine dummy argument. Why should corank be different? Reply from the editor: Because we did not intend it to do that, and it would not make any sense. We don't need to write a treatise on language design, we just need to answer the question. "No" conveys the entirety of "we did not intend to do that", which is the only thing we can easily agree on. Doing anything more would not only be difficult to craft all those language-design- principlely words and getting agreement all the way up and down the committees, but would delay answering the actual question and fixing the standard. (Actually rank specification would not have made a lot of sense either if F2003 had had impure elemental procedures... it was merely papering over that particular deficiency in the language.) .................................................................... F08/0073 Cohen comment: The note about the edit being unnecessary if F08/0059 passes should be an instruction not to make the edit in that case. Reid comment: I hope we pass F08/0059 and do not make the edit in F08/0073. .................................................................... 3. Revised interpretations ---------------------------------------------------------------------- NUMBER: F08/0054 TITLE: Requirements for needing an explicit interface KEYWORDS: Explicit interface DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot QUESTION: Consider the program SUBROUTINE Fred() BIND(C,NAME='Nurke') PRINT *,'ok' END SUBROUTINE SUBROUTINE S(dummy) INTERFACE SUBROUTINE dummy() BIND(C) END SUBROUTINE END INTERFACE CALL dummy END SUBROUTINE PROGRAM example1 EXTERNAL Fred,S CALL S(Fred) END PROGRAM According to 12.4.2.2, an explicit interface is only ever required in a scope where a procedure is referenced. The main program does not reference Fred, so this appears to be conforming. It appears that no processors accept this example... However, the very similar program minus the BIND(C) specifications SUBROUTINE Freddy(x) LOGICAL,OPTIONAL :: x IF (PRESENT(x)) PRINT *,'ok' END SUBROUTINE SUBROUTINE SUB(dummy) INTERFACE SUBROUTINE dummy(x) LOGICAL,OPTIONAL :: x END SUBROUTINE END INTERFACE CALL dummy(.TRUE.) END SUBROUTINE PROGRAM example2 EXTERNAL Freddy,SUB CALL SUB(Freddy) END PROGRAM but with a different reason for requiring an explicit interface, is also apparently valid in Fortran 2003/2008 but is not valid in Fortran 90 or Fortran 95, because they require the explicit interface without the condition of the procedure being referenced in that scope. This feature (viz only require the explicit interface where it is referenced) was added by paper 02-144, which makes no mention of it being a new feature. Was this a deliberate new feature? ANSWER: No, this was a mistake in 02-144 and thus in Fortran 2003 and 2008. An edit is provided to correct the mistake. EDITS to 10-007r1 (after corrigendum 1): [24:11+] 1.6.2 Compatibility, at the end, insert new paragraph "Fortran 2003 required an explicit interface only for a procedure that was actually referenced in the scope, not merely passed as an actual argument. This part of ISO/IEC 1539 requires an explicit interface for a procedure under the conditions listed in 12.4.2.2, regardless of whether the procedure is referenced in the scope." [279:19] In 12.4.2.2p1, replace "A procedure ... and" with "Within the scope of a procedure identifier, the procedure shall have an explicit interface if \obs{it is not a statement function and}" SUBMITTED BY: Malcolm Cohen HISTORY: 11-135 m194 F08/0054 submitted 11-135r1 m194 Passed by J3 meeting 11-207r1 m195 Passed as amended by J3 letter ballot #23 11-156 N1889 m197 Failed WG5 ballot 2 N1877 12-141 m197 Revised edits 12-141r1 m197 Revised edits - Passed by J3 meeting 12-165r2 m198 Passed by J3 letter ballot #25 12-147 12-194 m199 Passed as amended by WG5 ballot 3. ---------------------------------------------------------------------- NUMBER: F08/0055 TITLE: G editing for reals KEYWORDS: format, G editing DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot QUESTION: Q1. Gw.d editing for a real value that is in the range (0.1,10**d) and is not near an integer power of 10 uses F editing to produce exactly a value with d significant digits. For values in this range that are near an integer power of 10, is it intended that F editing be used to produce a value with d significant digits? The rules in 10.7.5.2.2 usually have this effect, but the following examples illustrate exceptions for rounding UP and to ZERO. print "(ru,g11.2)", -9.95 print "(rz,g11.2)", -9.95 When rounded to two significant digits these are both equal to -9.9, however following through the rules in the standard it says to use F7.0 format which will give the result -9. (only one significant digit). For positive values, rounding DOWN and to ZERO print "(rd,g11.2)", 9.95 print "(rz,g11.2)", 9.95 both give the result 9.9 according to the rules in the standard. Q2. Is Gw.d editing intended to use F editing when that produces d significant digits? It usually achieves this, but for print "(ru,0p,g11.2)", -99.5 the standard requires 0PE11.2 editing to be used, which gives -0.99E+02 even though F7.2 editing can represent it as -99. Similarly for print "(ru,0p,g11.2)", 99. the standard requires 0PE11.2 editing to be used, which gives 0.99E+02, even though it is representable in F7.2 format as 99. Q3. COMPATIBLE and NEAREST modes of rounding differ only when the two nearest representable values are equidistant from the given value. The similarity appears not to be represented in the second table. What is meant by "if the higher value is even"? If by "even" we mean the last digit is even, then since we are talking about a mantissa which is close to 10, COMPATIBLE and NEAREST would have the same effect. Q4. The table has no entry for PROCESSOR_DEFINED rounding; since there is no value specified for r, it is impossible to interpret the table, which seems to indicate that it would not be standard conforming to use G editing with PROCESSOR_DEFINED. How does the PROCESSOR_DEFINED I/O rounding mode affect G editing? Q5. According to 10.7.2.3.7 paragraphs 3 and 4, the effect of NEAREST is processor dependent unless IEEE rounding on conversions is supported. How does this affect G editing? Q6. Consider PRINT '(5(1X,1PG9.0))', 0.0, 0.04, 0.06, 0.4, 0.6 noting that these values are strictly monotonic increasing. The standard appears to say that the output should be 0.E+00 4.E-02 0. 0. 6.E-01 which is decidedly not monotonic increasing. Is this intentional? ANSWER: A1. Yes, it is intended to produce output with d significant digits. The algorithm for choosing the output form for some I/O rounding modes is defective. An edit is provided to replace this algorithm. A2. Yes. This is solved by the same edit. A3. This question is rendered moot by the same edit. A4. This question is rendered moot by the same edit. A5. This question is rendered moot by the same edit. A6. No. An edit is supplied to fix this. EDITS to 10-007r1: [24:11+] In 1.6.2, insert new paragraph following paragraph 1: "The form produced by the G edit descriptor for some values and some I/O rounding modes differs from that specified by Fortran 2003." [24:27+] In 1.6.3, append new bullet item "- The form produced by the G edit descriptor with equal to zero differs from that specified by Fortran 95 for some values.". [25:6] In 1.6.4, replace the last full stop with semicolon and insert new bullet item "- the G edit descriptor with equal to zero for some values.". [258:14-] Insert new paragraph "If \si{d} is zero, \si{k}PE\si{w}.0 or \si{k}PE\si{w}.0E\si{e} editing is used for G\si{w}.0 editing or G\si{w}.0E\si{e} editing respectively." {Without the italics markup, this is "If d is zero, kPEw.0 or kPEw.0Ee editing is used for Gw.0 editing or Gw.0Ee editing respectively."} [258:15-19] Replace the second and subsequent sentences of paragraph 4 including the two internal pseudo-tables by "If the internal value is a zero value, let $s$ be one. If the internal value is a number other than zero, let \it{N} be the decimal value that is the result of converting the internal value to \si{d} significant digits according to the I/O rounding mode and let $s$ be the integer such that $10^{s-1}$ <= \it{N} < $10^s$. If $s$<0 or $s$>\si{d}, \si{k}PE\si{w}.\si{d} or \si{k}PE\si{w}.\si{d}E\si{e} editing is used for G\si{w}.\si{d} editing or G\si{w}.\si{d}E\si{e} editing respectively, where \si{k} is the scale factor (10.8.5). If 0<=$s$<=\si{d}, the scale factor has no effect and F(\si{w}-\it{n}).(\si{d}-$s$),n('b') editing is used where \it{b} is a blank and \it{n} is 4 for G\si{w}.\si{d} editing and \si{e}+2 for G\si{w}.\si{d}E\si{e} editing." {Note: \it{something} is something in italics, \si{something} is a syntax term (in italics), and $something$ is LaTeX math notation. Without the italics markup, this is "If the internal value is a zero value, let s be one. If the internal value is a number other than zero, let N be the decimal value that is the result of converting the internal value to d significant digits according to the I/O rounding mode and let s be the integer such that 10^(s-1) <= N < 10^s. If 0<=s<=d, F(w-n).(d-s),n('b') editing is used where b is a blank and n is 4 for Gw.d editing and e+2 for Gw.dEe editing. If s<0 or s>d, kPEw.d or kPEw.dEe editing is used for Gw.d editing or Gw.dEe editing respectively."} SUBMITTED BY: John Reid and Thomas Henlich HISTORY: 11-174 m195 F08/0055 submitted 11-174r2 m195 Revised answer - Passed by J3 meeting 11-241 m196 Failed J3 letter ballot #24 11-229 11-261 m196 Revised edits - Passed by J3 meeting 12-165r2 m198 Passed as amended by J3 letter ballot #25 12-147 12-194 m199 Passed as amended by WG5 ballot 3. ---------------------------------------------------------------------- NUMBER: F08/0057 TITLE: Interoperability with empty types. KEYWORDS: Interoperability, derived type. DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot QUESTION: Consider TYPE,BIND(C) :: t END TYPE This is apparently standard-conforming, and interoperates with struct t { }; However, the latter is not valid syntax according to the C standard. How can a type be interoperable with a syntax error? ANSWER: The type definition was not intended to be standard-conforming. An edit is supplied to correct this error. EDIT: [431:11-] In 15.3.4, insert new constraint before C1505 "C1504a (R425) A derived type with the BIND attribute shall have at least one component." SUBMITTED BY: Malcolm Cohen HISTORY: 11-195 m195 F08/0057 submitted - passed by J3 meeting 12-165r2 m198 Passed as amended by J3 letter ballot #25 12-147 12-194 m199 Passed as amended by WG5 ballot 3. ---------------------------------------------------------------------- NUMBER: F08/0058 TITLE: ENTRY point RESULT variable KEYWORDS: ENTRY, RESULT DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot QUESTION: MODULE m REAL x CONTAINS FUNCTION f() f = 1 x = 2 RETURN ENTRY e() RESULT(x) x = 3 END FUNCTION END MODULE Is this standard-conforming? If so, what is the result of referencing f() and e(), and what effect does that have on the module variable x? Note that the standard prohibits dummy arguments of an entry point from appearing in executable statements ahead of the ENTRY statement (unless they are also dummy arguments of an earlier ENTRY statement or the FUNCTION statement), but makes no similar requirement on the RESULT name. ANSWER: This module was not meant to be conforming. An edit is provided to correct this mistake in the standard. EDITS to 10-007r1: Append new statement to 12.6.2.6p8 [310:20], "A name that appears as a in an ENTRY statement shall not appear in any executable statement that precedes the first RESULT clause with that name." Append new statement to 12.6.2.6p9 [310:23] "A name that appears as a in an ENTRY statement shall not appear in the expression of a statement function that precedes the first RESULT clause with that name unless the name is also a dummy argument of that statement function." SUBMITTED BY: Malcolm Cohen HISTORY: 11-196 m195 F08/0058 submitted 11-196r1 m195 Revised edits - Passed by J3 meeting 12-165r2 m198 Passed by J3 letter ballot #25 12-147 12-194 m199 Passed as amended by WG5 ballot 3. ---------------------------------------------------------------------- NUMBER: F08/0059 TITLE: Auto-targetting requirements KEYWORDS: POINTER, TARGET, argument association DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot QUESTION: Consider PROGRAM one REAL,TARGET :: x = 0 CLASS(*),POINTER :: p p => x ! (0). CALL s(p) ! (1). CALL s(x) ! (2). PRINT *,x CONTAINS SUBROUTINE s(q) CLASS(*),INTENT(IN),POINTER :: q IF (ASSOCIATED(q)) THEN SELECT TYPE (q) TYPE IS (REAL) q = q + 1 END SELECT END IF END SUBROUTINE END PROGRAM Clearly everything except statement (2) is standard-conforming. The statement marked (2) violates the requirement in 12.5.2.5 paragraph 2 for the actual argument to be polymorphic when the dummy argument is a polymorphic pointer. However, apart from that requirement, statement (2) is functionally equivalent to the sequence (0) then (1), so the "auto-targetting" feature does not need this requirement. Was this imposition of this requirement (which is needed when both the actual and the dummy are pointers) an oversight in this case? Note that similar considerations apply to CHARACTER(100),TARGET :: actual CHARACTER(:),POINTER,INTENT(IN) :: dummy in that the pointer assignment would be valid, but the requirements in 12.5.2.5 paragraph 5 are not met. ANSWER: Yes, the imposition of these requirements to the auto-targetting feature was an oversight. Edits are supplied to correct this. EDITS to 10-007r1: [295:16-17] In 12.5.2.5, Replace paragraph with "The requirements in this subclause apply to an actual argument with the ALLOCATABLE or POINTER attribute that corresponds to a dummy argument with the same attribute." {Except for paragraph 4, all these requirements are unnecessary when auto-targetting is happening. Note that 12.5.2.5p6 is moot because a coindexed object is not permitted in auto-targetting as it is not a valid target in a pointer assignment (C725).} [296:4-5] Delete paragraph 12.5.2.5p4 and reinsert twice, once at [296:12+] as a new paragraph after 12.5.2.6p3, and once at [296:35] as a new sentence at the end of 12.5.2.7p3. {Duplicate the bit about assumed type parameters.} SUBMITTED BY: Malcolm Cohen HISTORY: 11-197 m195 F08/0059 submitted 11-197r1 m195 Revised editing instructions - Passed by J3 meeting 12-165r2 m198 Passed as amended by J3 letter ballot #25 12-147 12-194 m199 Passed as amended by WG5 ballot 3. ---------------------------------------------------------------------- NUMBER: F08/0064 TITLE: STATUS of GET_ENVIRONMENT_VARIABLE KEYWORDS: GET_ENVIRONMENT_VARIABLE DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot QUESTION: Assuming the processor supports environment variables, consider Program m197_m1 Call Get_Environment_Variable(Name='HOME',Length=n,Status=istatus) Print *,istatus If (istatus==0) Print *,n End Program If the environment variable HOME does not exist, this program is obviously standard-conforming and prints the value 1 (STATUS paragraph of 13.7.67). If the environment variable HOME does exist but has "no value", this program is obviously standard-conforming and prints the value 0 (STATUS paragraph) and then prints the value 0 (LENGTH paragraph). Aside: Indeed, if a VALUE argument is supplied, it seems that "no value" is the same as "zero-length value" in that no difference between them is discernable in a standard-conforming program. "Inconvenience 1": If the environment variable HOME does exist, and has a value whose length is zero, the program appears to be not standard-conforming as no interpretation is established: there is no specification of the value to be assigned to the STATUS argument. This relies on there being a difference between "no value" and "zero-length value". "Inconvenience 2": If the environment variable HOME does exist, and has a value whose length is not zero, the program is definitely not standard-conforming as no interpretation is established w.r.t. the STATUS argument. Thus, even though VALUE is optional, it would seem that it is not permitted to omit it except when enquiring the existence of an environment variable that does not exist. Was it really intended to be impossible to enquire the existence and length of the environment variable without attempting to fetch it? ANSWER: No, this was not intended. An edit is supplied to correct this. EDIT: [351:18] After "either has no value" change "or" to a comma. After "assigned to VALUE," insert "or the VALUE argument is not present,". SUBMITTED BY: Malcolm Cohen HISTORY: 12-103 m197 F08/0064 submitted 12-103r1 m197 Revised Edit - passed by J3 meeting 12-165r2 m198 Passed by J3 letter ballot #25 12-147 12-194 m199 Passed as amended by WG5 ballot 3. ---------------------------------------------------------------------- NUMBER: F08/0067 TITLE: Passing arrays of extended type objects KEYWORDS: assumed-size arrays, extended type DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot QUESTION: Can an assumed-size array of extended type be passed as an actual argument to a nonpolymorphic dummy array whose type is the parent type of the extended type? Clause 6.5.2 "Whole arrays" [121:10-12] permits an assumed-size array to appear as an actual argument in a procedure reference. Consider the program MODULE TYPES TYPE REC INTEGER A END TYPE TYPE, EXTENDS(REC) :: REC2 INTEGER B END TYPE END SUBROUTINE SUB1(A, N) USE TYPES CLASS(REC), INTENT(IN) :: A(*) CALL SUB2(A, N) END SUBROUTINE SUB2(A, N) USE TYPES TYPE(REC) A(*) PRINT *, A(:N)%A END PROGRAM MAIN USE TYPES CLASS(REC), ALLOCATABLE :: A(:) INTERFACE SUBROUTINE SUB1(A, N) USE TYPES CLASS(REC), INTENT(IN) :: A(*) END SUBROUTINE END INTERFACE ALLOCATE (A, SOURCE = (/(REC2(I, -I), I = 1, 10)/)) CALL SUB1(A, 10) END The subroutine reference in SUB1 that invokes SUB2 appears to be standard conforming according to that clause. Is that intended? ANSWER: Depending on the processor's calling conventions, the invocation of SUB2 in SUB1 might require the shape, in which case it would not be conforming on that processor. It was not intended to be conforming on any processor. An edit is supplied to clarify this. EDIT to 10-007r1: [293:5] In 12.5.2.4 Ordinary dummy variables, paragraph 2, append "If the actual argument is a polymorphic assumed-size array, the dummy argument shall be polymorphic." SUBMITTED BY: Robert Corbett HISTORY: 12-114 m197 F08/0067 submitted 12-114r1 m197 Draft answer - passed by J3 meeting 12-165r2 m198 Passed by J3 letter ballot #25 12-147 12-194 m199 Passed as amended by WG5 ballot 3. ----------------------------------------------------------------------