08-259 To: J3 From: Stan Whitlock Subject: Results of the J3 interp letter ballot #17 Date: 2008 July 28 Here are the results of J3 letter ballot #17 on Fortran interpretations that officially closed 25-Jul-2008. The ballot is in J3 paper 08-213 for meeting #185. If I have transcribed a vote or a comment incorrectly, please let me know. J3 rep F95 F95 F03 F03 F03 F03 F03 F03 F03 F03 074 102 049 071 073 074 075 076 077 081 Malcolm Cohen (*) Y Y Y C Y Y Y Y Y Y Michael Ingrassia Y Y Y Y Y Y Y C Y Y Shivarama Kokrady Y Y Y Y Y Y Y Y Y Y Bill Long Y Y Y C Y Y Y Y C Y Dan Nagle Y Y Y Y Y Y Y Y Y Y Craig Rasmussen Y Y Y Y Y Y Y Y Y Y Van Snyder C Y Y Y Y Y Y C Y Y Stan Whitlock Y Y Y Y Y Y Y Y Y Y Jim Xia Y Y Y N Y Y Y Y Y Y J3 rep F03 F03 F03 F03 F03 082 087 098 112 117 Malcolm Cohen (*) C Y Y N C Michael Ingrassia Y Y Y N C Shivarama Kokrady Y Y Y Y Y Bill Long C Y C N Y Dan Nagle Y Y Y N Y Craig Rasmussen Y Y Y Y Y Van Snyder C Y Y N Y Stan Whitlock Y Y Y C Y Jim Xia Y Y Y C C (*) Malcolm Cohen is the alternate for Jeanne Martin where Y means "yes" C "yes with comment" N "no with comment" The comments for each interp are attached below in the same order as the table above. The summary of DRAFT results is as follows: Y = passed C = passed as amended N = needs further consideration F95 F95 F03 F03 F03 F03 F03 F03 F03 F03 F03 F03 F03 F03 F03 074 102 049 071 073 074 075 076 077 081 082 087 098 112 117 Y Y Y N Y Y Y Y C Y Y Y C N C The interps marked "C" pass with some minor fixes, as noted below. The interps marked "N" will be reconsidered at J3 meeting #185 by the /interp committee who will decide if the status becomes "withdraw for more work", "passed as amended", or "passed as printed". The edited interps in their DRFAT form are attached for use at meeting #185. /Stan ********************************************************************** General comment from Malcolm Cohen: Contrary to Van's position, I believe we should be silent on whether F2008 will or will not have a new feature that would alter the answer of any interp. These interpretation requests are all specifically being answered in the context of Fortran 2003. Adding some partial premature information to some answers could mislead the reader into thinking we will never change the others in a future standard: it just ain't so. General comment from Michael Ingrassia: I agree with Malcolm that this process should be independent of the process for finalizing F2008 text, and consequently that information about the state of Fortran 2008 with respect to these issues should be kept out of the interpretations document. Not that it wouldn't be nice to keep a running tally of whether Fortran 2008 agrees with or overturns the corrigenda established by the interpretations process. General comment from Stan Whitlock as head of /interp: Van Snyder responded to Malcolm's general comment: This position was proposed in my comments on YES votes. I assume interpretations for which there are no NO votes pass as balloted, and comments on YES votes are meaningful only if there are NO votes and the answer needs to be rewritten. So if there are not any NO votes on those interepretations, they ought to pass unaltered. That's not quite the way /interp plays it. A comment on a YES vote can force an interp to be sent back to J3 or the comment might be incorporated into the interp so it passes "as modified". F95/0074 TARGET dummy arguments and POINTER expressions Van Snyder Comment for F95/0074: The answer should include a remark that the outcome of this interpretation is reversed in Fortran 2008 as a new feature. Resolution for F95/0074: passed as is Bill pointed out that Van was mistaken: What new feature is this? The relevant text in 16.1 looks the same in 04-007 and 08-007r2. There was a proposal along these lines, but it failed. Van agreed: Bill is right. This was proposed in 08-187 section 3, which I mistakenly thought had been considered at m184 and voted into 08-020. Section 3 says "for consideration at m185." F03/0071 Subroutine/function ambiguity in generics Malcolm Cohen Comment for F03/0071: Jim claims that the argument is not at all "convincing", and wants us to declare that the procedure call is ambiguous. That is less than unconvincing: it is contrary to the expressed design principles of generic resolution which were intended to make it impossible to write an ambiguous generic reference. (Note: ambiguous means more than one procedure matches.) Turning around and allowing some generic procedure references to be ambiguous would be highly controversial to say the least (to be consistent this would mean we should be thinking of discarding most of our 16.2.3 rules on disambiguation in favour of "sorting it out at the call site"!). Jim Xia responded to this comment from Malcolm: OK, then I must have used the wrong term. What I intended to say was the generic name (call q(ff)) can not be resolved to a specific name because there is no match for it. A declaration statement like "external ff" only declares an EXTERNAL attribute for ff -- one may treat it as a subroutine. Note this is indeed how we treat the declaration in the first example (in that we claim it *MUST* mean a subroutine). Unless a declaration of type is declared somewhere else in the program, I'm not convinced we should deduce that ff "must" mean a function name in the 2nd case. Bill Long Comment for F03/0071: In the paragraph at the end of Q1, the second word, "uncertainly" should be "uncertainty". Jim Xia Comment for NO vote on F03/0071: The second answer says the main program is standard conforming and the reason is "Since the generic does not allow a subroutine as an argument, it must therefore be a function." This is not a convincing argument at all because the call statement "call q(ff)" could also be a mistake made by the user. Without declarations that make the entity ff definitely a function, this call is ambiguous, and shouldn't be allowed (as standard conforming). The edits should be extended to cover this case. Resolution for F03/0071: needs futher consideration at M185 Stan's take on this is that there is agreement we need an edit to clarify question 1: if you want a dummy argument in an INTERFACE block to be a function, it must have its type and type parameters explicitly declared. It will already have the EXPLICIT attribute. If such a dummy argument has the EXPLICIT attribute but no explicit type, then it is a dummy subroutine. Jim suggests the same must be true when you call the generic with an actual argument that has the EXTERNAL attribute: if its type and type parameters are explicitly declared, then it is a function. If it only has the EXPLICIT attribute with no explicit type, it is a subroutine. That leads to the CALL Q (FF) in MAIN to have no generic resolution - Jim wanted the call to be ambiguous. Malcolm suggests that we should believe the INTERFACE block for Q which says the dummy argument must be a function. IMPLICIT typing rules make the actual argument FF REAL so we can resolve the generic reference to the specific QR. F03/0076 Scope of Fortran names of procedures with binding labels Michael Ingrassia Comment for F03/0076: The ANSWER says that an external C procedure must be given a unique Fortran name inside a Fortran program. But that begs the question of whether non-Fortran procedures have an attribute that could be called their "Fortran name". I don't think they do, in general. Certainly the name AnExternalCProcedure must be unique, but should calling it CProc in module A lay a claim to it being the unique name of that procedure ? We might prefer the name "foo" in some places and we can say use A, foo => CProc call foo() Chances are, if you could inspect the source for this procedure (which by definition isn't Fortran source) there would be zero chance of finding "CProc" as its name. Van Snyder Comment for F03/0076: The answer should include a remark that the outcome of this interpretation is reversed in Fortran 2008 as a new feature. Resolution for F03/0076: passed as is Malcolm commented: Never mind whether this will turn out to be true or not, I think it is inappropriate at this juncture. The question is being asked of the current standard. We don't have a new standard otherwise we would be answering the question from the viewpoint of the new standard not the old one. F03/0077 LBOUND of array structure component Bill Long Comment for F03/0077: Very minor edit: In the "before" text for edit [107:2-3], the "whole array" should be "<>", same as in the replacement text. Resolution for F03/0077: passed as modified The edit will read: ** start edit [107:2-3] Replace the existing definition which is "A <> is a named array, which may be either a named constant (5.1.2.10, 5.2.9) or a variable; no subscript list is appended to the name." with "A <> is a named array or a structure component whose final is an array component name; no subscript list is appended." {Make "whole array" include the whole array component case.} ** end edit F03/0082 VALUE in place of INTENT for pure procedure dummy arguments Malcolm Cohen Comment for F03/0082: I disagree with Bill's comment about what "However" means; in this case it clearly means "However, even though we didn't think about it, ...". A bald "The standard is consistent" does not sit well with the previous admission that we did not, in fact, think about it in advance. Perhaps Bill would prefer "Nonetheless" to "However"? As for the "no end date", I don't feel strongly about it but all the answers are subject to change in a revised standard, so it doesn't seem particularly useful to mention that here. Bill Long Comment for F03/0082: In the last sentence of the ANSWER, the "However, " seems out of place - I don't see a contrast with the previous sentence. Starting the sentence with "The standard is consistent..." reads better. The end of the same sentence, "this restriction should remain" does not have any implied end date, suggesting what we're doing in f08 is wrong. It might be better as "this restriction should remain in Fortran 2003", or "this restriction should remain until it is removed in a future standard". Van Snyder Comment for F03/0082: The answer should include a remark that the outcome of this interpretation is reversed in Fortran 2008 as a new feature. Resolution for F03/0082: passed as modified The last sentence of the answer will read: "Nonetheless, the standard is consistent and not in error, and so this restriction should remain in Fortran 2003." F03/0098 Does allocate with source= define subcomponents? Bill Long Comment for F03/0098: In the EDITS: the citation [422:41-42] should be [422:41-43]. Resolution for F03/0098: passed as modified The citation [422:41-42] will be changed to [422:41-43]. F03/0112 attributes allowed for dummy arguments in defined assignments Malcolm Cohen Comment for NO vote on F03/0112: - EDITORIAL COMMENT F03/0112: DISCUSSION is for discussion of the background to the *answer*, and is being used wrongly here. Furthermore the first paragraph is mere pontification. Therefore: (a) replace subtitle DISCUSSION with QUESTION; (b) delete its first paragraph; (c) delete subtitle QUESTIONS, replace following 1. with Q1. and 2. with Q2. - NO vote on F03/0112: My preference would be to revert to the answer in 08-163; this isn't a deep issue, it's a "the standard allows you to do something silly" question. Well, big deal. The standard allows you to write INTERFACE ASSIGNMENT(=) MODULE PROCEDURE s END INTERFACE ... SUBROUTINE s(a,b) TYPE t REAL x END TYPE TYPE(t),INTENT(OUT) :: a TYPE(t),INTENT(IN) :: b a = b END as well. It's impossible to call this in standard-conforming code, ever; both as assignment, and as a direct procedure call. So what's the big fuss over whether we allow POINTER/ALLOCATABLE on B? That just makes it impossible to call in standard-conforming code via =, so it's not quite as stupid as the example above (which no-one has championed making illegal as far as I know). If we must stick to the current answer's edit, the explanation with the edit is badly worded (it's my fault: sorry about that). Here is a greatly simplified alternative: ***BEGIN ALTERNATIVE ANSWER TEXT ANSWER: Yes to both questions. However, the allowance of ALLOCATABLE on the second dummy argument was inadvertant; an edit is provided to make this non-conforming. ***END ALTERNATIVE ANSWER TEXT Finally, I must say it is quite disheartening to hear and read restrictions on actual argument correspondance with dummy arguments being brought up as if it had some bearing on whether, in the absence of a specific invocation, a dummy argument is permitted to have some attribute. The requirements for a procedure to be in an INTERFACE ASSIGNMENT(=) block are emphatically NOT "in addition" to the normal rules for argument association: the rules for argument association have no bearing on the matter, because they only come into play on procedure references. Being included into a generic interface is not, in any way shape or form, a "procedure reference". Michael Ingrassia Comment for NO vote on F03/0112: The submitter says that use of POINTER/ALLOCATABLE attributes, because they don't disambiguate generic declarations, will prevent the normal declarations of defined assignments. I am not sure I appreciate the submitter's point; I think it means that if I am handed code where defined assignment uses a "silly" declaration, I can't make the defined assignment interface usable by extending it. If so, I agree. But surely I can still make the interface usable by first removing the "silly" declaration. So no problem is actually being solved here, and no edits are necessary. Bill Long Comment for NO vote on F03/0112: - Editorial comments: In the first line of the last paragraph of the DISCUSSION, insert "that" between "standard" and "disallow". In the EDITS section, EDITS should be EDIT (singular). Otherwise, the edit seems OK. - Reason for NO vote: The ANSWER section is not correct. The restrictions on the dummy arguments of defined assignment routines listed on [263] are only those that are in addition to restrictions that generally apply to arguments and argument association. In particular, a dummy argument with the ALLOCATABLE attribute cannot correspond to an actual argument that is an expression since such an actual argument does not have the ALLOCATABLE attribute. Therefore, the second dummy argument of a defined assignment routine is not allowed to have the ALLOCATABLE attribute [269:15-16]. This is consistent with the proposed edit, but not consistent with the current answer. Dan Nagle Comment for NO vote on F03/0112: The answer does not agree with the edits. Which do we mean? I could accept either answer, but it really should be consistent. Van Snyder Comment for NO vote on F03/0112: In the discussion of the second question, replace "There are no" by "No" or insert "to" or "that" before "disallow". The edit contradicts the answer: "Yes to both questions...." Either we don't need any edits, or the answer needs to include "... but we didn't intend...." Stan Whitlock Comment for F03/0112: I do not agree with Bill Long and Dan Nagle that the discussion contradicts the edit. The discussion says: "Such a restriction for the second argument has no effect since the right argument is treated as an expression enclosed in parentheses which would have neither attribute but it does no harm. An edit is provided." I find that a satisfactory explanation. But since there is some confusion about our actions, I suggest we change that part of the discussion to clarify what we're doing: "Such a restriction for the second argument has no effect since the right argument is treated as an expression enclosed in parentheses which would have neither attribute. But such a restriction does no harm so an edit to state that restriction is provided." Jim Xia Comment for F03/0112: The answer conflicts with the edits. The answer should be fixed to say the second dummy argument in a defined assignment does not allow ALLOCATABLE attribute. Resolution for F03/0112: needs further consideration at m185 F03/0117 STOP executed via function in input/output list Michael Ingrassia Comment for F03/0117: The first edit is clearly needed. I would not insist on the second edit as that action more properly seems to belong to Fortran 2008 (it feels like a "new feature" which we should avoid in interpretations). Malcolm Cohen Comment for F03/0117: I agree with Jim that I overlooked the paragraph at [202:27-28]. Therefore, the third paragraph of the QUESTION "This ... 2003." should be deleted. Jim Xia Comment for F03/0117: In the question section, the argument that F03 allows execution of CLOSE statement on external file during internal IO statement is false. The F03 standard clearly states that CLOSE is not allowed during DTIO as stated in 9.5.3.7.2 [202:27-28]. Furthermore, the standard says during an internal recursive IO, no external unit can be referred to as indicated in 9.11 [219:10-11]. Resolution for F03/0117: passed as modified Delete the third paragraph of the QUESTION section. ---------------------------------------------------------------------- NUMBER: F95/0074 TITLE: TARGET dummy arguments and POINTER expressions KEYWORDS: TARGET, POINTER, dummy arguments DEFECT TYPE: Interpretation STATUS: Passed by J3 letter ballot see also F95 interp 000031 QUESTION: Consider the following program. PROGRAM questionable REAL,TARGET :: x CALL s1(f(x)) CALL s2(f(x)) CALL s3(f(x)) CONTAINS FUNCTION f(a) REAL,POINTER :: f REAL,TARGET :: a f => a END FUNCTION SUBROUTINE s1(variable) variable = 42 ! statement 1 END SUBROUTINE SUBROUTINE s2(variable) INTENT(OUT) variable variable = 42 ! statement 2 END SUBROUTINE SUBROUTINE s3(targ) REAL,TARGET :: targ REAL,POINTER :: p p => targ PRINT *,ASSOCIATED(p,x) ! statement 3 END SUBROUTINE END Is this program standard-conforming, and if so, what value is printed? The real question is whether an expression argument that is a pointer function reference is treated as a variable (data-object) argument with the variable being the target of the pointer expression. (Or whether it is dereferenced as usual in the absence of POINTER dummy arguments). Re (statement 1), the question is whether VARIABLE is definable when argument-associated with "F()". Re (statement 2), if the previous answer was Yes (VARIABLE is definable), then presumably it can be made INTENT(OUT). A random sample of 4 compilers revealed that they considered it not to be definable. Re (statement 3), the question is whether P is pointer-associated with X, not pointer-associated with X, or processor-dependent. Of the same random sample 3 thought it was associated with X, 1 thought not. ANSWER: These answers are in the context of Fortran 2003. 1. The call to s1 is not standard conforming. 5.1.2.7 states "If no INTENT attribute is specified for a dummy argument, its use is subject to the limitations of the associated actual argument." The associated actual argument is the function reference f(x); this is an expression, not a variable, and therefore not definable, because only variables can be defined (in the sense of being given a value, see 2.4.3.1.1 and 2.5.5). 2. The call to s2 is not standard conforming. 12.4.1.2 says: "If a nonpointer dummy argument has INTENT(OUT) or INTENT(INOUT), the actual argument shall be definable." Again the actual argument is a function reference, which is not definable. 3. The call to s3 is standard conforming and the pointer assignment in s3 causes p and x to become associated. This may be deduced from 12.4.1.2, which says [270:5-0] "If the dummy argument has the TARGET attribute, does not have the VALUE attribute, and is either a scalar or an assumed-shape array, and the corresponding actual argument has the TARGET attribute but is not an array section with a vector subscript then (1) Any pointers associated with the actual argument become associated with the corresponding dummy argument on invocation of the procedure ..." EDITS: None. SUBMITTED BY: Malcolm Cohen HISTORY: 99-198 m150 F95/0074 submitted WG5/N1414 Draft answer 00-260 m154 Passed by J3 meeting 00-329 m155 Failed J3 letter ballot 04-311 m168 Passed by J3 meeting vote - alternate answer removed 04-417r1 M170 Passed by J3 letter ballot #8 05-180 m172 Failed WG5 ballot N1617 08-172 m184 Revised answer - Passed by J3 meeting 08-xxx m185 Passed by J3 letter ballot #17 08-213 ---------------------------------------------------------------------- NUMBER: F95/0102 TITLE: mask-expr evaluated only once KEYWORDS: WHERE DEFECT TYPE: Interpretation STATUS: Passed by J3 letter ballot QUESTION: Is a mask-expr required to be evaluated in a WHERE such as: WHERE ( (/ .TRUE., .TRUE. /) ) A = A + 1 ELSE WHERE (MASKF()) A = MAX END WHERE where an optimizing compiler might notice that the ELSEWHERE branch will never be executed ? Page 112, line 38 says of the mask expression in ELSEWHERE statements "The mask-expression is evaluated only once." ANSWER: The above quote is from the Fortran 95 standard. In Fortran 2003 the mask expression in an ELSEWHERE is not required to be evaluated, and this is made clear by the fourth paragraph of 7.4.3.2 (at [147:7]) which, referring to a masked ELSEWHERE statement, states "The is evaluated at most once." This also applies to the mask expressions of nested WHERE construct statements; this is made clear by the last sentence of the seventh paragraph of 7.4.3.2 (at [147:16]) which also states that it is evaluated "at most once". However, this does not apply to the mask expression of the outermost WHERE construct statement, which must be evaluated exactly once; this is made clear by the last statement of the first paragraph of 7.4.3.2 (at [147:1]) which states that this mask expression is evaluated "only once". That does not guarantee invocation of functions in that expression if they are not required to determine its value. EDITS: None. SUBMITTED BY: Matthijs van Waveren HISTORY: 03-239 m165 F95/0102 Passed by J3 meeting 04-417r1 m170 Passed by J3 letter ballot #8 05-180 m172 Failed WG5 ballot N1617 08-171 m184 Revised answer - Passed by J3 meeting 08-xxx m185 Passed by J3 letter ballot #17 08-213 ---------------------------------------------------------------------- NUMBER: F03/0049 TITLE: Separators in list-directed output involving UDDTIO KEYWORDS: list-directed output, separators, UDDTIO DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Consider the following program: MODULE m TYPE t INTEGER i END TYPE INTERFACE WRITE(FORMATTED) MODULE PROCEDURE formattedWriteT END INTERFACE CONTAINS SUBROUTINE formattedWriteT(dtv, unit, iotype, v_list, iostat, iomsg) CLASS(t), INTENT(IN) :: dtv INTEGER, INTENT(IN) :: unit CHARACTER(LEN=*), INTENT(IN) :: iotype INTEGER, INTENT(IN) :: v_list(:) INTEGER, INTENT(OUT) :: iostat CHARACTER(LEN=*), INTENT(INOUT) :: iomsg WRITE(unit, *) dtv%i, 'a' END SUBROUTINE END MODULE PROGRAM foo USE m TYPE(t) :: t1 = t(5) OPEN(10, FILE='foo.txt', ACCESS='SEQUENTIAL', FORM='FORMATTED', & DELIM='NONE') WRITE(10, *) 'xyz', t1, 'zyx' END PROGRAM 10.9.2 of Fortran 2003 states that character sequences produced for list-directed output are not separated from each other by value separators when the delimiter mode is NONE. The implication of this is obvious when the adjacent effective output list items are both of character type. But when user-defined derived-type input/output is involved, it is much less clear whether a separator should be included in the output. In the example given, it is unclear whether the output should be: xyz 5 azyx or: xyz 5 a zyx 1. Should a separator be inserted between two non-delimited character sequences when one of the character sequences is written by a child data transfer statement, and the other is written by a parent data transfer statement, where both statements are list-directed? 2. Should a separator be inserted between two non-delimited character sequences when the character sequences are written by two different child data transfer statements, where both statements are list-directed? 3. Should a separator be inserted between two character sequences when one of the character sequences is written by a child data transfer statement, and the other is written by a parent data transfer statement, where one of the statements is list-directed and the other is format-directed? 4. Should a separator be inserted between two character sequences when the character sequences are written by two different child data transfer statements, where one of the statements is list-directed and the other is format-directed? There is also the further question of whether, in the case of recursive i/o, this is affected by intervening i/o operations to a different unit. For example, in the modified program: MODULE m2 TYPE t INTEGER i END TYPE INTERFACE WRITE(FORMATTED) MODULE PROCEDURE formattedWriteT END INTERFACE CONTAINS SUBROUTINE formattedWriteT(dtv,unit,iotype,v_list,iostat,iomsg) CLASS(t), INTENT(IN) :: dtv INTEGER, INTENT(IN) :: unit CHARACTER(LEN=*), INTENT(IN) :: iotype INTEGER, INTENT(IN) :: v_list(:) INTEGER, INTENT(OUT) :: iostat CHARACTER(LEN=*), INTENT(INOUT) :: iomsg CHARACTER(100) temp WRITE (temp,'(I0)') dtv%i WRITE (unit,*) TRIM(temp) END SUBROUTINE END MODULE PROGRAM foo2 USE m2 TYPE(t) :: t1 = t(5) OPEN(10, FILE='foo.txt', ACCESS='SEQUENTIAL', & FORM='FORMATTED', DELIM='NONE') WRITE(10, *) 'xyz', t1, 'zyx' END PROGRAM 5. Does the second example write xyz 5xyz or xyz5xyz That is, in this case, does the data transfer which is an internal file write affect whether 'xyz' and TRIM(temp) are adjacent? 6. Similarly, if the outer list-directed WRITE were to an internal file does an intervening external file i/o operation affect whether the character sequences are considered adjacent (i.e. the opposite way around to the second example)? ANSWER: 1) No. It is the intent of the standard (10.9.2) that when both the parent and child data transfer statements are both list-directed output statements, or both are namelist output statements, the processor treats the first list item appearing in a child data transfer statement as if that list item had immediately followed the last list item processed by the parent data transfer statement, as long as no other data transfers to that unit occurred in between the processing of those two list items. Therefore, in this case, the two character sequences are considered adjacent. 2) No. It is the intent of the standard (10.9.2) that when two different child data transfer statements are both list-directed output statements, or both namelist output statements, they write to the same unit, and no other data transfers to that unit occur in between the two child data transfer statements, the processor treats the first list item appearing in the second child data transfer statement as if that list item had immediately followed the last list item processed by the first child data transfer statement. Therefore, in this case, the two character sequences are considered adjacent. 3) It is processor dependent whether or not a separator appears between two such character sequences. In section 10.9.2, the phrase "adjacent undelimited character sequences" refers to character sequences produced by list-directed output. When one of the sequences is written by a child or parent output statement that is not list-directed, the exception described in the first paragraph of 10.9.2 does not apply. The other rules for inserting optional blanks around values in list-directed output allow the processor to insert optional leading and trailing blanks around a list item. The standard does not specify when optional blanks are written; therefore, when two adjacent list items (the values thereof) are written to an output record, and only one of them was written by list-directed input/output, the standard does not specify whether or not any optional blanks appear between those values in the output record. 4) It is processor dependent whether or not a separator appears between two such character sequences. See answer 3. 5) The result should be "xyz5xyz", that is, the recursive i/o to the internal file does not affect whether the character sequences being written by the outer data transfer statement are considered adjacent. 6) No, if an outer data transfer is to an internal file, then a recursive i/o operation to a different internal file or an external file does not affect whether the character sequences are considered adjacent. NOTE TO J3: In Fortran 2008, recursive i/o operations to a different external unit are allowed and these also ought not to affect whether the character sequences written by the outer data transfer statement are considered to be adjacent. The edit to F2003 below will produce that result when applied to the (draft) F2008. EDITS: [241:5] In Section 10.9.2, add the following to the end of the first paragraph: "Two undelimited character sequences are considered adjacent when both were written using list-directed input/output, no intervening data transfer or input/output file positioning operations on that unit occurred, and both were written either by a single data transfer statement, or during the execution of a parent data transfer statement along with its child data transfer statements." SUBMITTED BY: Rob James HISTORY: 05-140 m171 F03/0049 Submitted 05-140r1 m171 Passed by J3 meeting 05-170 m172 Failed J3 letter ballot #11 06-367r1 m178 Passed by J3 meeting 07-272 m181 Passed as changed by J3 letter ballot #13 08-155 m184 Failed WG5 ballot #4 N1711-N1721 08-182r1 m184 Revised answer - Passed by J3 meeting 08-xxx m185 Passed by J3 letter ballot #17 08-213 ---------------------------------------------------------------------- NUMBER: F03/0071 TITLE: Subroutine/function ambiguity in generics KEYWORDS: subroutine, generic, implicit DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTION: Q1. Is the following generic allowed? interface q subroutine qr(f) implicit real(f) external f end subroutine subroutine qc(f) implicit complex(f) external f end subroutine end interface q The uncertainly arises because it is not established whether F is a subroutine or a function. If either F were a subroutine, then it would be clear that the generic was disallowed. One might be able to use this to deduce that both Fs must be functions. This seems like an obscure deduction to demand of the compiler. Q2. Consider the following "obviously" allowed generic module m interface q subroutine qr(f) real, external :: f end subroutine subroutine qc(f) complex, external :: f end subroutine end interface q end module m Is the following main program valid? program main use m external ff call q(ff) end Again, the problem is that it is unclear whether or not ff is a function or subroutine. If it is a subroutine, then the call is ambiguous. One might thus deduce that ff must be a function, and therefore of type real, but this seems like an obscure deduction to demand of the compiler. ANSWER: 1. The program fragment is not conforming. A generic interface is required to be nonambiguous. This is a similar situation to the declaration of an external procedure in a module, where a procedure that is a function is required to have its type and type parameters explicitly declared. An edit is provided to require this for specific procedures in a generic interface. 2. The main program is conforming. As remarked, at the call site the procedure is known to be either a subroutine or a function. Since the generic does not allow a subroutine as an argument, it must therefore be a function. Implicit typing means that ff is real so qr is called. (The generic cannot have a specific that accepts a subroutine as an argument, as that would violate the requirements in 16.2.3.) EDITS: [261:3] In 12.3.2.1 Interface block, immediately after "A generic interface is always explicit.", append new sentence to paragraph "If a specific procedure in a generic interface has a function dummy argument, that argument shall have its type and type parameters explicitly declared in the specific interface." {I.e. if you just say EXTERNAL dummy, you must mean a subroutine.} SUBMITTED BY: Richard Maine HISTORY: 05-265 m174 F03/0071 Submitted 08-189r1 m184 Answer provided - Passed by J3 meeting 08-213 m185 In J3 letter ballot #17 ---------------------------------------------------------------------- NUMBER: F03/0073 TITLE: C interop of dummy procedures KEYWORDS: Interoperability, dummy procedures DEFECT TYPE: Interpretation STATUS: Passed by J3 letter ballot QUESTION: Is the following interface interoperable, and if yes, what is the interoperable C prototype? subroutine my_sub(my_fun) bind(c, name="My_Proc") interface function my_fun(x) bind(c) use iso_c_binding integer(c_int) :: my_fun real(c_double), value :: x end function end interface end subroutine ANSWER: Yes, this interface is interoperable with the following prototype: void My_Proc(int (*his_fun)(double)); Its formal parameter is of a pointer type, and the referenced type is a function that is interoperable with my_fun, thus satisfying the requirements in item 5 in the list in subclause 15.2.6. EDITS: None: SUBMITTED BY: Aleksandar Donev HISTORY: 06-102 m175 F03/0073 Submitted 08-188r1 m184 Answer proposed - Passed by J3 meeting 08-xxx m185 Passed by J3 letter ballot #17 08-213 ---------------------------------------------------------------------- NUMBER: F03/0074 TITLE: Type mismatch for C character arguments KEYWORDS: Interoperability, dummy procedures DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Is the following conforming if the C character kind (C_CHAR) is not the same as the default character kind (KIND('A'))? use iso_c_binding Interface Subroutine sub(string) Bind(C) import C_Char Character(Kind=C_Char) :: string(*) End Subroutine End Interface Character(Kind=C_Char,Len=10) :: string Call sub(string) The second and 3rd paras of 12.4.1.2 do not treat C character kind the same as default character kind, and seem to require matching type parameter values between the actual and dummy. This makes Note 15.23 nonconforming if C_CHAR is not the same as default character kind, and is also not in sync with 270:25-26. ANSWER: Yes, the program fragment is standard-conforming. An edit is provided to correct the oversight in 12.4.1.2. EDITS: [269:3,5,8] After each "of type default character", Insert "or of type character with the C character kind (15.1)", Thrice. SUBMITTED BY: Aleksandar Donev HISTORY: 06-105 m175 F03/0074 Submitted 08-190r1 m184 Revised answer - Passed by J3 meeting 08-xxx m185 Passed by J3 letter ballot #17 08-213 ---------------------------------------------------------------------- NUMBER: F03/0075 TITLE: C interop of derived types with array components KEYWORDS: Interoperability, dummy procedures DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Is the following C struct: typedef struct { float x[5]; } array; interoperable with this Fortran type: type, bind(c) :: array real(c_float) :: x(3) end type ANSWER: No. According to the words in 15.2.3, the answer is yes, since only interoperability of the types of the C and Fortran components is required. This is, however, an oversight. An edit is provided to correct this. EDITS: In the first sentence of the first paragraph after NOTE 15.12 in subclause 15.2.3 [04-007:398:11-12], replace "have types and type parameters that are interoperable with the types of the corresponding components of the struct type" with "would interoperate with corresponding components of the C struct type as described in 15.2.4 and 15.2.5 if the components were variables". SUBMITTED BY: Aleksandar Donev HISTORY: 06-106 m175 F03/0075 Submitted 08-191r1 m184 Revised answer - Passed by J3 meeting 08-xxx m185 Passed by J3 letter ballot #17 08-213 ---------------------------------------------------------------------- NUMBER: F03/0076 TITLE: Scope of Fortran names of procedures with binding labels KEYWORDS: Interoperability, dummy procedures DEFECT TYPE: Interpretation STATUS: Passed by J3 letter ballot QUESTION: Is the following conforming: module A interface subroutine CProc() bind(C,name="AnExternalCProcedure") end subroutine end interface end module module B interface subroutine CSub() bind(C,name="AnExternalCProcedure") end subroutine end interface end module ANSWER: No, the fragment is not conforming. The name of an external procedure is a global entity and is required to be unique. That is, the external C procedure AnExternalCProcedure, must be given a unique Fortran name inside a Fortran program. EDITS: None. SUBMITTED BY: Aleksandar Donev HISTORY: 06-107 m175 F03/0076 Submitted 08-187 m184 Passed by J3 meeting 08-xxx m185 Passed by J3 letter ballot #17 08-213 ---------------------------------------------------------------------- NUMBER: F03/0077 TITLE: LBOUND of array structure component KEYWORDS: LBOUND, lower bounds, bounds, structure component, array sections DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Given the declarations TYPE t REAL x REAL y(-5:5) END TYPE TYPE(t) z(10:20) What is the result of the following LBOUND references: LBOUND(z(10)%y) LBOUND(z%x) The confusion arises because the existing definition of LBOUND uses the undefined term "array structure component" in determining whether to return the lower bound in the or 1. It seems clear that Z(10)%Y must be an array structure component (so the answer ought to be -5) but it is not clear whether Z%X is one and therefore whether the result of that LBOUND ought to be 1 or 10. ANSWER: Yes, the result of the first LBOUND is indeed -5. The result of the second LBOUND is 1. Clarifying edits are provided. The description of the intrinsic function UBOUND suffers from the same flaw, and the edits provided fix that function as well. EDITS: To avoid the undefined term, or any long phrase, the edit changes the definition of "whole array" to include the case of a whole array component of a structure. [107:2-3] Replace the existing definition which is "A <> is a named array, which may be either a named constant (5.1.2.10, 5.2.9) or a variable; no subscript list is appended to the name." with "A <> is a named array or a structure component whose final is an array component name; no subscript list is appended." {Make "whole array" include the whole array component case.} [107:7-8] Replace "whole array name" with "whole array designator", twice. [326:8] After "a whole array" delete "or array structure component". {No longer need kludgy wording in LBOUND.} [358:6-7] After "a whole array" delete "or array structure component". {No longer need kludgy wording in UBOUND.} [436:36] After "named array" insert "or array component of a structure, with no subscript list." {Fix the glossary.} SUBMITTED BY: Aleksandar Donev HISTORY: 06-118 m175 F03/0077 Submitted 08-174 m184 Revised with edits 08-174r1 m184 Fixed typo - Passed by J3 meeting 08-xxx m185 Passed as modified by J3 LB #17 08-213 ---------------------------------------------------------------------- NUMBER: F03/0081 TITLE: F edit descriptor with field width 0 KEYWORDS: Data edit descriptors, F edit descriptor, field width DEFECT TYPE: Interpretation STATUS: Passed by J3 letter ballot QUESTION: Does the Fortran 2003 standard allow the output field produced by an F edit descriptor with a field width w whose value is zero for a real value whose magnitude is less than one to include an optional leading zero? For example, is the PRINT statement PRINT '(F0.2)', 0.01 allowed to write "0.01"? ANSWER: No. This is clear from Section 10.6.1 of the Fortran 2003 standard, item (6). EDITS: None. SUBMITTED BY: Michael Ingrassia HISTORY: 06-127 m175 F03/0081 Submitted 08-175 m184 Editorial revision - Passed by J3 meeting 08-xxx m185 Passed by J3 letter ballot #17 08-213 ---------------------------------------------------------------------- NUMBER: F03/0082 TITLE: VALUE in place of INTENT for pure procedure dummy arguments KEYWORDS: VALUE, INTENT, PURE DEFECT TYPE: Interpretation STATUS: Passed by J3 letter ballot QUESTION: C1266 requires all nonpointer dummy arguments of a pure function to be data objects that have INTENT(IN). C1267 requires all dummy arguments of a pure subroutine to have specified intents. Was it intended that VALUE not be allowed in place of INTENT(IN), that is, was it intended that if a dummy argument of a pure procedure has the VALUE attribute, it is nonetheless also required to have the INTENT(IN) attribute explicitly specified? ANSWER: The possible extension of the VALUE attribute to allow omission of the INTENT(IN) attribute in the specific case of pure procedures was not considered during the development of Fortran 2003. Nonetheless, the standard is consistent and not in error, and so this restriction should remain in Fortran 2003. EDITS: None. SUBMITTED BY: Van Snyder HISTORY: 06-153 m176 F03/0082 Submitted, fix edit, needs more 08-176 m184 Reversed answer + revised alternative edits Passed by J3 meeting 08-xxx m185 Passed as modified by J3 LB #17 08-213 ---------------------------------------------------------------------- NUMBER: F03/0087 TITLE: Entry names as dummy procedure arguments KEYWORDS: Entry names, dummy procedure arguments DEFECT TYPE: Interpretation STATUS: Passed by J3 letter ballot QUESTION: Does the following subprogram fragment conflict with the 2003 Fortran standard? If so, was the conflict intended? entry A ( X ) interface subroutine X ( A ) abstract interface subroutine I ( ... ) ... end subroutine I end interface procedure (I) A end subroutine X end interface ... It seems that constraint C1255 in subclause 12.5.2.4 [283:10-12] prohibits the entry name A to appear in the PROCEDURE statement in the interface body. There shouldn't be a problem, however, since the PROCEDURE statement is in a different scoping unit. ANSWER: No, this program fragment conforms to the 2003 Fortran standard. EDITS: None NOTE: C1255 is pointless because Clause 16 applies. It could fruitfully be removed from a future revision of the Fortran standard. SUBMITTED BY: Van Snyder HISTORY: 07-105 m179 Submitted F03/0087 07-105 m179 Passed by J3 meeting 07-272 m181 Failed J3 letter ballot #13 07-250r1 08-192r1 m184 Revised answer - Passed by J3 meeting 08-xxx m185 Passed by J3 letter ballot #17 08-213 ---------------------------------------------------------------------- NUMBER: F03/0098 TITLE: Does allocate with source= define subcomponents? KEYWORDS: allocate, source, define DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Was it intended that an allocate with a source= clause define subcomponents? Bullet 11 on 422 says "Successful execution of an ALLOCATE statement ...causes the subcomponent to become undefined." ANSWER: An Allocate with a SOURCE= specifier was intended to define subcomponents. In fact, none of the lists in clause 16 account for a SOURCE= specifier. Edits are supplied to clarify this. EDITS: [113:21] At the end of the last sentence in 6.3.1.1 insert "unless the SOURCE= specifier appears and the corresponding component of the is allocated". [421:27] 16.5.5, list item 19, after "Allocation", insert ", except by an ALLOCATE statement with a SOURCE= specifier," [421:28+] 16.5.5, insert new list item after (19) "(19a) Successful execution of an ALLOCATE statement with a SOURCE= specifier causes a subobject of the allocated object to become defined if the corresponding subobject of the SOURCE= expression is defined." [422:41-43] 16.5.6, list item (11), replace list item with "Successful allocation of an ALLOCATE statement with no SOURCE= specifier causes a subcomponent of an allocated object to become undefined if default initialization has not been specified for that subcomponent." [422:43+] 16.5.6, add a new list item after (11), "(11a) Successful execution of an ALLOCATE statement with a SOURCE= specifier causes a subobject of the allocated object to become undefined if the corresponding subobject of the SOURCE= expression is undefined." SUBMITTED BY: Dick Hendrickson HISTORY: 07-268 m181 F03/0098 Submitted 07-268r2 m181 Passed by J3 meeting 07-279 m182 Passed as changed by J3 LB #14 07-321 08-155 m184 Failed WG5 ballot #4 N1711-N1721 08-183 m184 Revised edits - Passed by J3 meeting 08-xxx m185 Passed as modified by J3 LB #17 08-213 ---------------------------------------------------------------------- NUMBER: F03/0112 TITLE: attributes allowed for dummy arguments in defined assignments KEYWORDS: defined assignment, dummy argument, attributes DEFECT TYPE: Erratum STATUS: Passed by J3 meeting DISCUSSION: It seems the standard is quite loose in allowing various attributes declared for the dummy arguments used in a defined assignment (7.4.1.4). In particular, attributes such as POINTER and ALLOCATABLE can be declared for dummy arguments in the defined assignment. However the interpretations on their declarations need to be clarified. Consider the follow subroutines (assuming a derived type DT already defined) 1. POINTER/ALLOCATABLE on the second dummy argument interface ASSIGNMENT (=) subroutine defAssgn1 (dt1, dt2) type(DT), intent(out) :: dt1 type(DT), POINTER, intent(in) :: dt2 end subroutine end interface In 12.3.2.1.2 [263:10-12], the standard says the following "A defined assignment is treated as a reference to the subroutine, with the left-hand side as the first argument and the right-hand side enclosed in parentheses as the second argument." This statement seems to prohibit the use of subroutine defAssgn1 for defined assignment since a pointer enclosed in parentheses refers to its associated target not the pointer itself, as indicated by rules in 7.1.4.1 [123:39-124:3]. 2. POINTER/ALLOCATABLE on the first dummy argument interface ASSIGNMENT (=) subroutine defAssgn2 (dt1, dt2) type(DT), POINTER, intent(out) :: dt1 type(DT), intent(in) :: dt2 end subroutine end interface There are no rules in the standard disallow this declaration. However the use of POINTER/ALLOCATABLE attributes on the first dummy argument is very doubtful. Since POINTER/ALLOCATABLE attributes don't disambiguate generic declarations(16.2.3), their use will prevent the normal declarations of defined assignments, wherein dt1 is declared without POINTER or ALLOCATABLE attribute. QUESTIONS: 1. Are POINTER and ALLOCATABLE attributes allowed for the second dummy argument in defined assignment? 2. Are POINTER and ALLOCATABLE attributes allowed for the first dummy argument in defined assignment? ANSWER: Yes to both questions. The standard places very few restrictions on the arguments to defined assignment subroutines: [263:6...] Each of these subroutines shall have exactly two dummy arguments. Each argument shall be nonoptional. The first argument shall have INTENT (OUT) or INTENT (INOUT) and the second argument shall have INTENT (IN). ... Preventing the first argument from having the POINTER attribute violates F90. Such a restriction for the second argument has no effect since the right argument is treated as an expression enclosed in parentheses which would have neither attribute but it does no harm. An edit is provided. EDITS: In section 12.3.2.1.2 of 04-007, second paragraph, at the end of the third sentence [263:8], after "INTENT (IN)", insert "and shall not have the ALLOCATABLE attribute". SUBMITTED BY: Jim Xia HISTORY: 08-120 m183 F03/0112 Submitted 08-120r1 m183 Create answer 08-120r2 m183 Passed by J3 meeting 08-163 m184 Failed J3 letter ballot 08-141 08-186r1 m184 Another answer - Passed by J3 meeting 08-213 m185 In J3 letter ballot #17 ---------------------------------------------------------------------- NUMBER: F03/0117 TITLE: STOP executed via function in input/output list KEYWORDS: STOP DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Interpretation F90/000209 considered the question Section 9.7. May a function referenced in an I/O statement execute a STOP or PAUSE statement? If STOP statements are permitted, what is the state of the file at the end of execution? The answer (w.r.t. STOP), included in F95 corrigendum 2, replied No, a STOP statement may not be executed in this situation. Executing a STOP statement causes normal termination of execution, which closes all files (9.3.5), and this is equivalent to executing a CLOSE statement, which is prohibited by 9.7. A clarifying edit is supplied. However, on further consideration of the reasoning behind this answer, it seems unhelpful to rule out STOP, which is often used for user signalling of error conditions, during i/o operations. For one thing, if the data transfer statement being executed is READ, the question about file state has a very straightforward answer. It might also be considered unhelpful in the WRITE case for STOP to cause the user's entire file system to be potentially reformatted instead of just making the contents of the relevant file undefined. Furthermore, the user who wants to signal an error can cause error termination via one of the "approved" methods such as DEALLOCATE of an unallocated array. It seems less than unhelpful to force the user to use such a circumlocution simply for standards conformance, and the question about file state can equally be asked of this situation. Q1. Is execution of a STOP statement during internal i/o allowed? Q2. Is execution of a STOP statement during a READ statement allowed? Q3. Is execution of a STOP statement during a WRITE statement allowed? Q4. What is the effect on the file state of executing the following code fragment during a WRITE statement to an external file: REAL,ALLOCATABLE :: array(:) DEALLOCATE(array) (And if the answer to Q3 is yes, does a STOP statement have the same effect.) ANSWER: The answer to the first three questions is yes, this should have been allowed. An edit is provided to correct the standard. The answer to Q4 is that the effects on the file currently being written by that WRITE statement are not standardised. (This was, in fact, the situation before the adoption of the previous interp answer.) A clarifying edit is provided to indicate that the contents of the file become undefined. EDITS: [195:23+] In 9.5.3 "Execution of a data transfer input/output statement", immediately before Note 9.38 insert a new paragraph "If execution of the program is terminated during execution of a WRITE or PRINT statement, the contents of the file become undefined." Delete [219:30] the last paragraph of 9.11 which currently reads "A STOP statement shall not be executed during execution of an input/output statement." SUBMITTED BY: Malcolm Cohen HISTORY: 08-173 m184 F03/0117 Submitted - Passed by J3 meeting 08-xxx m185 Passed as modified by J3 LB #17 08-213 ----------------------------------------------------------------------