09-155 To: J3 Members From: Stan Whitlock Subject: J3 Fortran interp letter ballot #18 - due 23-Mar-2009 Date: 2009 February 23 Enclosed in the next letter ballot on Fortran interpretations. The rules by which we operate say: o J3 votes on the answer at a J3 meeting; a simple majority vote marks the answer as "passed by J3 meeting". o Between J3 meetings the chair of /interp sends a J3 letter ballot to J3 to approve interp answers that have been "passed by J3 meeting". The letter ballot runs for 30 days. Not voting on three of four consecutive J3 letter ballots is grounds to terminate J3 membership. An interp answer passes by a 2/3rds vote; a no vote must be accompanied by an explanation of the changes necessary to change the member's vote to yes. J3/interp reserves the right to recall an interp answer for more study even if the answer passes. 12 Fortran interpretations are currently "Passed by J3 meeting" after J3 meeting #187. This is the letter ballot phase to go from "Passed by J3 meeting" to "Passed by J3 letter ballot". Some of these interps contain notes about fixes that have already or should possibly go into F2008. These notes are not part of the ballot - they are information to /interp and the editor about possible F2008 changes. The following Fortran interpretations are being balloted: Yes No Number Title --- --- F03/0063 Procedure pointers in BLOCK DATA program units --- --- F03/0064 Recursive declaration of procedure interfaces --- --- F03/0065 Relational equivalence --- --- F03/0071 Subroutine/function ambiguity in generics --- --- F03/0112 Attributes allowed for dummy arguments in defined assignments --- --- F03/0119 Elemental procedures and deferred length character components --- --- F03/0122 When do objects of sequence derived type have the same type? --- --- F03/0125 Definitions of EXTENDS_TYPE_OF and SAME_TYPE_AS --- --- F03/0126 References to VOLATILE variables in pure procedures --- --- F03/0127 Duration of procedure execution --- --- F03/0128 Subobjects in namelist output --- --- F03/0129 C_LOC of character substrings The text of these interpretations is attached. Each interpretation starts with a row of "-"s. Please mark the above -Y- in the Yes column for "yes", -C- in the Yes column for "yes with comment", or -N- in the No column for a "no" answer {be sure to include your reasons with "no"} and send only the above text {not this entire mail message} with any comments to j3@j3-fortran.org by 11:59:59PM, PDT, Monday, 23-Mar-2009, in order to be counted. Thanks /Stan ---------------------------------------------------------------------- NUMBER: F03/0063 TITLE: Procedure pointers in BLOCK DATA program units KEYWORDS: Procedure pointer, common block, block data DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTION: It is clear that procedure pointers are permitted in common blocks. However, due to the restrictions on BLOCK DATA program units, it seems that such a common block can not appear in a BLOCK DATA program unit. Was it intended that common blocks containing procedure pointers could be initialized in a BLOCK DATA program unit? ANSWER: It was a mistake to try to allow procedure pointers in common blocks. Edits are provided to correct this blunder. EDITS: All edits refer to 04-007. [98:17] Delete the second line of R558. [98:21] After "allocatable" insert "or a procedure pointer". SUBMITTED BY: Rob James HISTORY: 05-178 m172 F03/0063 submitted 05-225 m173 Passed by J3 meeting 06-133r2 m175 Passed J3 letter ballot #12 N1658 m176 Failed WG5 ballot N1657 09-148 m187 Revised answer, passed by J3 meeting F2008 note: include edits above + [04-007/98:21-22 5.5.2 C588] Delete "a function name, an entry name," because these were originally synonyms for "a result name" (as applied to in R558). Now, "a function name" (as applied to in R558) prohibits function pointers. ---------------------------------------------------------------------- NUMBER: F03/0064 TITLE: Recursive declaration of procedure interfaces KEYWORDS: procedure, interface DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTION: Consider the following program: PROGRAM foo PROCEDURE(sub) :: p INTERFACE SUBROUTINE sub(p2) IMPORT p PROCEDURE(p) :: p2 END SUBROUTINE END INTERFACE END PROGRAM C1212 appears to prohibit the case of an interface name in a procedure declaration statement being the name of something declared in a later procedure declaration statement. But it does not appear to prohibit the case of an interface name being the name of something declared in a later interface body. In the above program, the characteristics of p rely on the characteristics of sub. The characteristics of sub, in turn, rely on the characteristics of p. Is this program standard-conforming? ANSWER: No, this program is not standard-conforming. The interface name in a procedure declaration statement should not be permitted to be declared in a later interface body. An edit is supplied to correct this oversight. DISCUSSION: The edit changes C1212 to read: C1212 ... If is declared by a or it shall be previously declared." Example 1: MODULE m1 CONTAINS SUBROUTINE s(p) PROCEDURE(s) :: p END SUBROUTINE END MODULE This is clearly invalid, since the declaration of "s" in the PROCEDURE statement is still in progress (until END SUBROUTINE) and therefore "s" which is being declared by an interface body is *NOT* previously declared. Example 2: MODULE m2 CONTAINS SUBROUTINE s1(a) PROCEDURE(s2) :: a END SUBROUTINE SUBROUTINE s2(b) PROCEDURE(s1) :: b END SUBROUTINE END MODULE This is invalid because the interface body for S1 does not have access to S2. Furthermore, adding an IMPORT statement is ineffective because of the requirement "An entity that is imported ... and is defined in the host scoping unit shall be explicitly declared prior to the interface body." EDITS: All edits refer to 04-007. [264:22] Before "it shall", insert "or ". SUBMITTED BY: Rob James HISTORY: 05-179 m172 F03/0064 submitted 05-226 m173 Passed by J3 meeting 06-133 m175 Failed J3 letter ballot #12 09-149 m187 Passed by J3 meeting ---------------------------------------------------------------------- NUMBER: F03/0065 TITLE: relational equivalence KEYWORDS: transformation, relational equivalence, mathematical value DEFECT TYPE: Interpretation STATUS: Passed by J3 meeting QUESTION: Given REAL X X = ... some value ... may IF( X+3.0 .EQ. 3.0 )... be transformed into IF( X .EQ. 0.0 )... by the processor? References are to J3/04-007. 7.1.8.3 Evaluation of numeric intrinsic operations has a discussion of "mathematically equivalent", "mathematical value" and "computational results". 7.1.8.5 Evaluation of relational intrinsic operations has "Two relational intrinsic operations are relationally equivalent if their logical values are equal for all possible values of their primaries." "values" in that context is ambiguous to me. Is it the infinite set of mathematical values or is it the finite set of hardware representable (computational) values? My brief scan of F2003 finds that "values" without any adjectives means what the hardware can represent. Assuming "values" in 7.1.8.5 means what the hardware can represent, then I conclude that the transformation cannot be done. However, Note 7.22 shows "I > J" transformed into "J-I < 0"; which is not true for the finite set of hardware values (due to undefined behavior of overflow), but is true for the infinite set of mathematical values. I believe that "possible values" should be changed to either: possible mathematical values or possible computational values ANSWER: Since it can be undecidable whether expressions are mathematically equivalent, it is clear that the permission to evaluate mathematically equivalent expressions means "if an expression can be determined to be mathematically equivalent it can be used instead." Even in cases where it is easy to determine that expressions are mathematicaly equivalent, it can be formidably expensive to determine that they are equivalent for the finite but sometimes very large set of "all possible computational values of their primaries." The term "different computational results" includes the case that one expression does not produce overflow when evaluated computationally for some set of computational values of its primaries, while a mathematically equivalent expression does produce overflow when evaluated computationally for some members of that set of values of its primaries. One can imagine a processor that cannot evaluate I > J, but it can evaluate I - J and then examine the sign. This transformation thus has to be allowed for all values, not just for those computational values for which no overflow results. Therefore, the term "all possible values" refers to mathematical values. EDITS: None. SUBMITTED BY: Fred Tydeman HISTORY: 05-192 m173 F03/0065 submitted 09-150 m187 Passed by J3 meeting ---------------------------------------------------------------------- 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 uncertainty 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 program unit is conforming, although the program would not be if the external procedure FF were not in fact a real function. If the reference had been to QR instead of Q, it would be clear that FF has to be a real function, from the point of view of the main program scoping unit. At the call site, the reference to Q is known to be a reference either to QR or QC (the interface block for Q is not defective), both of which require a function actual argument. FF is known to be either a subroutine or a function, since it explicitly has the EXTERNAL attribute, and if it is a function it is known by implicit typing rules to be real. Because neither specific in the generic allows a subroutine as an argument, FF must therefore be a function. Since FF is real, 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-259 m185 Failed J3 letter ballot #17 08-213 08-262 m185 Passed by J3 meeting F2008 note: edit is 09-007 [287:5+] 12.4.3.4.1 "Generic identifiers" after "A generic interface is always explicit." ---------------------------------------------------------------------- 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 INTRODUCTION: 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. QUESTION: Consider the follow subroutines (assuming a derived type DT already defined) Q1. Are POINTER and ALLOCATABLE attributes allowed for the second dummy argument in defined assignment? 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]. Q2. Are POINTER and ALLOCATABLE attributes allowed for the first dummy argument in defined assignment? 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 that 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. ANSWER: Yes to both questions. The interface blocks are not defective. The standard places very few restrictions on the arguments to defined assignment subroutines: [363: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. Preventing the second argument from having the ALLOCATABLE attribute would introduce a prohibition not specified by TR 15581, and might therefore be viewed as an incompatibility that ought to be announced in subclause 1.5. A program couldn't reference defAssgn1 by way of defined assignment because the right-hand side of a defined assignment is treated as an expression enclosed in parentheses which would have neither the POINTER nor the ALLOCATABLE attribute. A note is provided to draw the readers attention. EDITS: At the end of 12.3.2.1.2 insert a new NOTE 12.10+: "NOTE 12.10+ If the second argument of a procedure specified in a defined assignment interface block has the POINTER of ALLOCATABLE attribute, it cannot be accessed by defined assignment, since the right-hand side of the assignment is enclosed in parentheses before being associated as an actual argument with the second argument. This makes it an expression, which does not have the POINTER or 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-259 m185 Failed J3 letter ballot #17 08-213 08-263r1 m185 Revised answer - passed by J3 meeting F2008 note: edit is 09-007 [289:9+] 12.4.3.4.3 "Defined assignments" after NOTE 12.8 ---------------------------------------------------------------------- NUMBER: F03/0119 TITLE: Elemental procedures and deferred length character components KEYWORDS: deferred length, elemental DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTION: Constraint C1279 says "In the scoping unit of an elemental subprogram, an object designator with a dummy argument as the base object shall not appear in a except as the argument to one of the intrinsic functions BIT_SIZE, KIND, LEN, or the numeric inquiry functions (13.5.6)." It has been stated in previous J3 papers that the reason for this restriction is to ensure that every iteration of a single invocation of an elemental procedure will have the same stack size: and this desire was achieved in Fortran 95. However, the situation changes with deferred-length character components. Consider example 1: PROGRAM example1 TYPE t CHARACTER(:),ALLOCATABLE :: cp END TYPE TYPE(t) array(100) DO i=1,100; array(i)%cp = REPEAT('x',i); END DO CALL zap(array) ... CONTAINS ELEMENTAL SUBROUTINE zap(x) TYPE(t),INTENT(INOUT) :: x REAL work(LEN(x%cp)) ... END SUBROUTINE END PROGRAM In the invocation "CALL zap(array)", the invoked procedure will have a different size for its WORK array for every element of ARRAY. Thus the restriction no longer achieves its aim (though this aim is not actually stated in the standard). However, as stated the restriction still prohibits the very similar program example2: PROGRAM example2 INTEGER :: array(100) = (/ (i,i=1,100) /) CALL es(array) PRINT *,array CONTAINS ELEMENTAL SUBROUTINE es(x) INTEGER,INTENT(INOUT) :: x REAL work(x) ... END SUBROUTINE END PROGRAM There does not seem to be any technical reason for the prohibition of example2. A more problematic case arises for an elemental function whose result variable has a length type parameter that depends on a deferred length parameter of a dummy argument. This can occur both for intrinsic type CHARACTER and for parameterized derived types. Consider: PROGRAM example3 TYPE t1(n) INTEGER,LENGTH :: n INTEGER istring(n) END TYPE TYPE t2 CHARACTER(:),ALLOCATABLE :: string END TYPE PRINT *,f( [ t2('short'),t2('this is much longer') ] ) CONTAINS ELEMENTAL FUNCTION f(x) TYPE(t2),INTENT(IN) :: x TYPE(t1(x%string%len)) f INTEGER j f%istring = [ (ICHAR(x%string(j:j),j=1,f%n)) ] END FUNCTION END The invocation of F in the PRINT statement will return an array whose elements have different length type parameters, something that is supposed to be impossible. Is this restriction still correct and useful? That is, (a) was example1 intended to be standard-conforming, (b) should example2 be standard-conforming, (c) was example3 intended to be standard-conforming. ANSWER: Although there is no technical (implementation) reason for prohibiting example2 while allowing example1, doing so is not a defect in the standard. However, allowing elemental functions to produce arrays whose elements have different length type parameters would be a defect. Thus, example1 is standard-conforming as argued; example2 is not conforming, because it violates constraint C1279; example3 was intended to be prohibited: an edit is supplied to fix this defect in the standard. EDIT: In 12.7.1, constraint C1278, [287:17] After "scalar" change "and" to a comma. [288:1] At the end of the sentence insert ", and shall not have a type parameter that is defined by an expression that is not an initialization expression". SUBMITTED BY: Malcolm Cohen HISTORY: 08-258 m185 Submitted F03/0119 08-299r1 m186 Revised answer, passed by J3 meeting 09-103 m187 Revised, passed by J3 meeting + F08 fix ---------------------------------------------------------------------- NUMBER: F03/0122 TITLE: When do objects of sequence derived type have the same type? KEYWORDS: SEQUENCE type DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTION: Consider the following program: MODULE MOD TYPE, PRIVATE :: T SEQUENCE INTEGER :: I END TYPE TYPE(T) :: X, Y CONTAINS SUBROUTINE S X = Y END SUBROUTINE S END PROGRAM MAIN USE MOD CALL S X = Y END The first sentence of subclause 4.5.1.3 of the 2003 Fortran standard says the program conforms because the objects X and Y have the same type, because they are declared by reference to the same type definition. The last sentence of that subclause says they do not have the same type because the type definition is declared to be PRIVATE. Does the program conform to the 2003 Fortran standard? If not, which assignment statement causes the program not to conform? ANSWER: The program conforms to the 2003 Fortran standard. ANALYSIS: The determination that an object cannot have the same type as another one that is declared by reference to a type that is declared to be PRIVATE cannot possibly refer to an object declared in a scope where the type is not accessible. Therefore the objects must be declared in scopes where the type is accessible. It is irrelevant whether the type is "declared to be PRIVATE" in that scope, because accessibility attributes determine whether a name is accessible in a different scope. It would be absurd if the assignment statement in the module subprogram were not standard conforming. Given that it must be standard conforming, it would be absurd if the assignment statement in the main program were not standard conforming. Edits are provided to clarify this conclusion. EDITS: In subclause 4.5.1.3 [47:11], remove "declared to be PRIVATE or" from the last sentence. SUBMITTED BY: Van Snyder HISTORY: 08-270 m185 F03/0122 submitted 08-270r1 m185 Passed by J3 meeting F2008 note: edit is 09-007 [61:11] 4.5.2.4 "Determination of derived types" remove "declared to be PRIVATE or" --------------------------------------------------------------------- NUMBER: F03/0125 TITLE: Definitions of EXTENDS_TYPE_OF and SAME_TYPE_AS KEYWORDS: EXTENDS_TYPE_OF SAME_TYPE_AS DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTION: The arguments of EXTENDS_TYPE_OF and SAME_TYPE_AS are required to be of extensible type. Does this restriction apply to the declared type, the dynamic type, or both? ANSWER: This restriction was intended to apply to the dynamic type; this is clear from the existing text. However, the restriction is stronger than required or useful, and so an edit is supplied to weaken it. DISCUSSION: For EXTENDS_TYPE_OF, this is clear from the Result Value paragraph which explicitly specifies the result when either the A or MOLD argument to the intrinsic is unlimited polymorphic. For SAME_TYPE_AS, this is clear from Note 13.17 which explains how to work out the result when one or both arguments is a disassociated pointer (or unallocated allocatable), including that of an unlimited polymorphic entity. However, in the case of unlimited polymorphic, it is unreasonable to require the program to somehow know that the dynamic type is extensible; these functions should return the right result whenever either argument is of extensible type, and otherwise it should be processor dependent, i.e. the restriction should be weakened. EDITS: [316:16-17] In 13.7.38, EXTENDS_TYPE_OF, arguments A and MOLD, after "of extensible" change "type" to "declared type or unlimited polymorphic", twice. [316:21] Change the last "otherwise" to "if the dynamic type of A or MOLD is extensible,". [316:22] At the end of the sentence insert "; otherwise the result is processor dependent". [347:30,348:1] In 13.7.101, SAME_TYPE_AS, arguments A and B, after "of extensible" change "type" to "declared type or unlimited polymorphic", twice. [348:3] Change "The" to "If the dynamic type of A or B is extensible, the" [348:4] Append new sentence to paragraph "If neither A nor B have extensible dynamic type, the result is processor dependent." SUBMITTED BY: John Reid HISTORY: 08-281 m186 F03/0125 submitted 08-281r2 m186 Passed by J3 meeting + F08 fix ---------------------------------------------------------------------- NUMBER: F03/0126 TITLE: References to VOLATILE variables in pure procedures KEYWORDS: VOLATILE, PURE DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTION: Was it intended to allow a VOLATILE variable to be referenced in a pure procedure? ANSWER: No. It was intended that the result of invoking a pure function in a FORALL assignment statement should never depend on the order in which the invocations are executed, see NOTE 12.44. The value of a variable with the VOLATILE attribute might change between invocations of the function in ways incompatible with this design. EDIT: [286:22+] In 12.6, Pure procedures, add a new constraint: "C1271a The of a variable with the VOLATILE attribute shall not appear in a pure subprogram." SUBMITTED BY: John Reid and Bill Long HISTORY: 08-284 m186 F03/0126 submitted in response to N1745 by Nick Maclaren noting the problem 08-284r1 m186 Passed by J3 meeting {F08 fixed in 12.7 "Pure procedures" 09-007 [317:14] C1281} ---------------------------------------------------------------------- NUMBER: F03/0127 TITLE: Duration of procedure execution KEYWORDS: argument association, procedure DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTION: In the following questions, the following type definition and procedure are assumed: TYPE T INTEGER :: C = 17 END TYPE SUBROUTINE S(A,B) TYPE(T),INTENT(IN) :: A TYPE(T),INTENT(OUT) :: B ... END (1) Consider TYPE(T) X X%C = 3 CALL S(X,X) Q1. Is this valid, and if so, is A%C equal to 3 or 17? Discussion: B is default-initialized "on invocation", and A is not permitted to be changed "during execution", so this depends on whether "during execution" was intended to include the process of invocation. (2) Consider TYPE(T) X X%C = 3 CALL S(F(),X) where F is the internal function TYPE(T) FUNCTION F() F = X END FUNCTION Q2. Is this valid? If so, what is the value of B%C (3 or 17)? Discussion: The reference to procedure F is not permitted to "affect or be affected by the evaluation of any other entity within the statement" (7.1.8 paragraph 3). However, X is not being affected by "evaluation" (it is not being evaluated by becoming argument-associated with dummy argument A). A becomes defined "on invocation" of S and it is not clear whether that precedes argument evaluation or not. (3) Consider SUBROUTINE V(AA,BB) TYPE(T),VALUE :: AA TYPE(T),INTENT(OUT) :: BB ... END TYPE(T) X X%C = 3 CALL V(X,X) Q3. Is this valid? If so, what is the value of AA%C (3 or 17)? Discussion: AA gets its value by argument association, so happens at the same time as the definition of BB (which defines the actual argument). It is not clear what the semantics are here. Q4. It is similarly unclear as to what is or is not permitted during invocation of a procedure when an actual argument might be modified by some other activity, for example if it has the VOLATILE or ASYNCHRONOUS attribute. ANSWER: The standard does not unambiguously supply an interpretation of these, and therefore they are invalid by subclause 1.5, first sentence. Edits are supplied to clarify this. EDITS: [81:15] 5.1.2.7, paragraph beginning "The INTENT(IN)", change "during the execution" to "during the invocation and execution". {Makes example 1 clearly invalid, and makes it clear that INTENT(IN) variables are unchanged from the start of invocation.} [81:26] Append to the INTENT(OUT) paragraph "Any undefinition or definition implied by association of an actual argument with an INTENT(OUT) dummy argument shall not affect any other entity within the statement that invokes the procedure." {Makes examples 2 and 3 clearly invalid.} [275:2,5] Change "during the execution" To "during the invocation and execution", Twice. {Makes it clear that the anti-aliasing rules apply for the whole process of procedure invocation and execution, not just the execution part.} SUBMITTED BY: Malcolm Cohen HISTORY: 08-298r1 m186 F03/0127 submitted 08-298r2 m186 Passed by J3 meeting + F08 edit ---------------------------------------------------------------------- NUMBER: F03/0128 TITLE: Subobjects in namelist output KEYWORDS: NAMELIST DEFECT TYPE: Error STATUS: Passed by J3 meeting QUESTION: Was it intended to disallow vendors to provide namelist output that includes a subobject designator followed by a value? ANSWER: No, it was intended that vendors should have the same choice as users writing namelist input as to whether to provide the name of an object followed by a list of values that give the value of the object or to provide a sequence of subobject designators, each followed by a list giving the value of the subobject. DISCUSSION: At the start of clause 10.10.2 (Namelist Output) of the Fortran 2003 standard, as amended by Corrigendum 3, is the text "The form of the output produced is the same as that required for input, except for the forms of real, character, and logical values, and output produced with user-defined derived-type output". There is no exception for the freedom on input to use subobject designators. The text in the second paragraph of clause 10.10.2.2, says "The name of each namelist group object list item is placed in the output record followed by an equals and a list of values of the namelist group object list item.". The intention here was to use "name" in the generalized sense of name or designator, as in paragraph 1 of clause 10.10.1.1: "If a namelist group object is an array, the input record corresponding to it may contain either the array name or the designator of a subobject of that array, using the syntax of object designators (R603). If the namelist group object name is the name of a variable of derived type, the name in the input record may be either the name of the variable or the designator of one of its components, indicated by qualifying the variable name with the appropriate component name." Because of the meaning attached to "name", in the rest of the standard, it should not be used in this way in clause 10.10.2.2. EDIT: [247:17] In 10.10.2.2, Namelist output records, paragraph 2, change "The name" to "The name or designator". SUBMITTED BY: John Reid HISTORY: 09-115 m187 Submitted F03/0128 09-115r1 m187 Passed by J3 meeting + F2008 fix ---------------------------------------------------------------------- NUMBER: F03/0129 TITLE: C_LOC of character substrings KEYWORDS: interoperability DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTION: Consider SUBROUTINE S(A,I,K) USE ISO_C_BINDING CHARACTER(*),TARGET :: A CHARACTER(:),ALLOCATABLE,TARGET :: B TYPE(C_PTR) P1,P2,P3,P4,P5 P1 = C_LOC(A(1:1)) ! *1 P2 = C_LOC(A(I:I)) ! *2 P3 = C_LOC(A(1:)) ! *3 P4 = C_LOC(A(I:K)) ! *4 ALLOCATE(CHARACTER(1)::B) P5 = C_LOC(B) ! *5 END SUBROUTINE C_LOC (case 1) requires of its argument that it have interoperable type and type parameters (15.1.2.5, p395). Case 2 does not apply because character type has a length type parameter. 15.2.1 states "if the type is character, interoperability also requires that the length type parameter be omitted or be specified by an initialization expression whose value is one". However, a substring does not have a declared type parameter that can be omitted or specified by an initialization expression. Even in the reference marked *1, it is the substring starting and ending positions that are specified by initialization expressions, not the substring length. In any case, if *1 satisfied the quoted requirement then *3 also has its starting and ending positions specified by by initializations "or omitted". In case *2, it must be totally obvious that the length has to be 1 since the expressions are lexically identical with no user function references, but neither are initialization expressions. If I==K, it would be reasonable to expect *4 to be interoperable but it certainly does not satisfy the stated requirements. Or, another interpretation would be that for substrings the length type parameter is by definition "omitted" since they have no syntax for its specification: in which case the question would arise as to what happens for zero-length substrings. It seems that the authors of the requirement forgot that "variables" include "substrings". Finally, case *5 is totally ambiguous because B has multiple length specifications, one which does not satisfy the requirement (the declaration) and one which does (the ALLOCATE statement). ANSWER: C_LOC should only require nonzero length, which corresponds to the requirement we make for arrays. Furthermore, the description of interoperability of intrinsic types is confusing for type CHARACTER. Edits are provided to fix the defects. EDITS: [395:8(16.1.2.5)] In the <> paragraph, Before "type parameters" insert "kind". [395:16+] Insert new sentence after list: "X shall not be a zero-length string." [396:5-7] Replace "; if ... one." with ". If the type is character, the length type parameter is interoperable if and only if its value is one." {Reword so that the type/kind can be interoperable even if the length is not.} [399:2-2(15.2.4p1)] Before "scalar" insert "named", {I think this is supposed to be talking about named variables only, not about subobjects.} Change "if" to "if and only if" {Seems to be broken...} Change "and" to a comma, At the end of the sentence insert ", and if it is of type character its length is not assumed or declared by an expression that is not an initialization expression". {It seems more straightforward to forbid the invalid than to require the valid.} [399:7-8(15.2.5)] Change "An array Fortran variable" to "A Fortran variable that is a named array", Change "if" to "if and only if", Change "and" to a comma, At the end of the sentence insert ", and if it is of type character its length is not assumed or declared by an expression that is not an initialization expression". SUBMITTED BY: Malcolm Cohen HISTORY: 09-121r1 m187 Submitted F03/0129 09-121r1 m187 Passed by J3 meeting + F2008 fix ----------------------------------------------------------------------