J3/07-279 Date: 7-Sep-2007 To: J3 Members From: interp/Stan Whitlock Subj: J3 Fortran interp letter ballot #14 - due 8-Oct-2007 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. 9 Fortran 2003 interpretations are currently "Passed by J3 meeting" after J3 meeting #181. This is the letter ballot phase to go from "Passed by J3 meeting" to "Passed by J3 letter ballot". The following Fortran interpretations are being balloted: Yes No Number Title --- --- F03/0092 Procedure characteristics and unlimited polymorphic --- --- F03/0093 Allocatable array on intrinsic assignment with scalar expr --- --- F03/0094 Final subroutine and VALUE attribute --- --- F03/0095 Bounds remapped pointer assignment and ASSOCIATED --- --- F03/0097 Blanks as separators in NAMELIST input --- --- F03/0098 Does allocate with source= define subcomponents? --- --- F03/0099 Clause 16 does not account for volatile variable --- --- F03/0100 Error in field width for special cases of signed INFINITY output --- --- F03/0101 Is UDDTIO output suitable for namelist and list-directed input 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, PST, Monday, 8-Oct-2007, in order to be counted. Thanks /Stan ---------------------------------------------------------------------- NUMBER: F03/0092 TITLE: Procedure characteristics and unlimited polymorphic KEYWORDS: Procedure, unlimited polymorphic DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTION: Consider abstract interface function foo (x) class(*) x class(*), pointer :: foo end function end interface procedure (foo), pointer :: proc_ptr procedure (foo) proc_tgt proc_ptr => proc_tgt According to the rules of procedure pointer assignment at [144:39-41], proc_ptr and proc_tgt are required to have the same interface characteristics. However because an unlimited polymorphic entity is not considered to have a declared type, the rules for characteristics of dummy data objects [256:26-32] and characteristics of function results [257:2-8] are not applicable. In addition, rules at [145:5-6] require that proc_ptr and proc_tgt have the same function return type. This also does not apply to unlimited polymorphic data. Is the example intended to be standard-conforming? ANSWER: Yes, the example was intended to be standard-conforming. An edit is provided to clarify this. The characteristics however are adequately defined. FOO, and thus both PROC_PTR and PROC_TGT have no type, but are polymorphic; this precisely characterises an unlimited polymorphic entity. Only the requirement of type matching in 7.4.2.2 is incorrect. EDITS to 04-007: [145:5] After "the same type" insert " or both be unlimited polymorphic". SUBMITTED BY: Jim Xia HISTORY: 07-247 m181 F03/0092 Submitted 07-247r1 m181 Passed by J3 meeting ---------------------------------------------------------------------- NUMBER: F03/0093 TITLE: Allocatable array on intrinsic assignment with scalar expr KEYWORDS: allocatable array, intrinsic assignment DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTION: Consider CHARACTER(:), ALLOCATABLE :: str(:) ALLOCATE (CHARACTER(1) :: str(0:9)) str = 'reallocate?' According to the third paragraph of 7.4.1.3, the variable STR should be deallocated on this assignment because it has a deferred length type parameter different from the ('reallocate?'); it should then be allocated with its length type parameter the same as that of the and with the shape and bounds of . But the STR cannot be allocated with the shape and bounds of the since it is a scalar. The standard, however, provides a possible interpretation for the shape of two paragraphs later where it says "If is a scalar and is an array, the is treated as if it were an array of the same shape as with every element of the array equal to the scalar value of ." Q(1). Should the variable STR be reallocated in this case? Q(2). If so, what are the values of its length type parameter, shape and bounds? ANSWER: (1) Yes, STR should be reallocated - that is the purpose of the combination of ALLOCATABLE and deferred type parameters. If the user does not wish for automatic reallocation he can use "str(:) = 'do not reallocate'" instead. (2) The length parameter of str after the assignment is 11 (the value returned by LEN('reallocate?')). The shape and bounds should be unchanged. An edit is provided to clarify this. Note that the standard does not forbid, but does not specify semantics for, str = 'oops' when STR is an unallocated array with a deferred length parameter. An edit is supplied to make it clear that this is not allowed. Note also that this applies to parameterized derived types with deferred type parameters. EDITS: [139:22-] Insert new sentence at beginning of paragraph "If is an unallocated allocatable array, shall be an array." [139:25] Change "corresponding type parameters of ," to "corresponding type parameter of ." {Note to J3: fix singular/plural correspondence} [139:25] Before ", with the shape of " Insert ". If is an array and is scalar it is allocated with the same bounds as before, otherwise it is allocated". {Note to J3: Malcolm thinks it is clear from context what "it" and "before" mean, but further wordsmithing could be done.} SUBMITTED BY: Jim Xia HISTORY: 07-248 m181 F03/0093 Submitted 07-248r2 m181 Passed by J3 meeting ---------------------------------------------------------------------- NUMBER: F03/0094 TITLE: Final subroutine and VALUE attribute KEYWORDS: Final subroutine, VALUE DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTION: Currently, the F03 standard allows the VALUE attribute to be specified for the dummy argument of a final subroutine. This seems to defeat the purpose of final subroutine, which is intended to apply to the finalizable entity (the actual argument) itself. Should the dummy argument of a final subroutine be allowed to have the VALUE attribute? ANSWER: No, the VALUE attribute should not be allowed. An edit is provided to correct this oversight. EDITS to 04-007: [58:14] Replace "not be INTENT(OUT)" with "not have the INTENT(OUT) or VALUE attribute". SUBMITTED BY: Jim Xia HISTORY: 07-249 m181 F03/0094 Submitted 07-249r1 m181 Passed by J3 meeting ---------------------------------------------------------------------- NUMBER: F03/0095 TITLE: Bounds remapped pointer assignment and ASSOCIATED KEYWORDS: pointer assignment, bounds-remapping, ASSOCIATED DEFECT TYPE: Interpretation STATUS: Passed by J3 meeting QUESTION: Case (v) of intrinsic inquiry function ASSOCIATED [305:5-9] says If TARGET is present and is an array target, the result is true if the target associated with POINTER and TARGET have the same shape, are neither of size zero nor arrays whose elements are zero-sized storage sequences, and occupy the same storage units in array element order. Otherwise, the result is false. If POINTER is disassociated, the result is false. This will cause the intrinsic to return false if the POINTER is pointer assigned to the TARGET with bounds-remapping (POINTER and TARGET can be of different ranks). The same issue also exists for case (vii). Is the POINTER associated with the TARGET if the POINTER is pointer assigned to the TARGET with bounds-remapping? ANSWER: No, it is not intended that ASSOCIATED(POINTER, TARGET) return true after pointer assignment using a bounds-remapping that changes the shape or rank. This was a conscious decision made in response to a Fortran 90 interpretation request concerning dummy arguments that are different shaped versions of the same array in the calling procedure. EDITS to 04-007: none SUBMITTED BY: Jim Xia HISTORY: 07-259 m181 F03/0095 Submitted 07-259r2 m181 Passed by J3 meeting ---------------------------------------------------------------------- NUMBER: F03/0097 TITLE: Blanks as separators in NAMELIST input KEYWORDS: Namelist input, blanks, separators DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTION: 1) Was in intended that blanks be allowed as separators in Namelist Input? Consider a namelist input fragment: I = 3 J = 4 Page 243:5 says that namelist value separators are the same as list directed value separators. Page 239:7 says those value separators are "...blanks between values" and then defines what the values are. The "J" above isn't a value, so the blanks aren't separators and the fragment is illegal for namelist input 2) Is there a similar problem with namelist comments as in this fragment? I = 3 ! this is a namelist comment ANSWER: 1) Yes, it was intended to allow blanks as separators for namelist input. Edits are supplied to correct the wording in the standard 2) Yes, there is a similar problem with comments. The fragment is intended to be legal. The edits correct the error. EDITS: [243:5] Replace the paragraph by "A value separator for list-directed formatting (10.9) is also a value separator for namelist formatting. In addition, one or more contiguous blanks between a nonblank value and the following object designator or "!" comment initiator is a value separator." SUBMITTED BY: Dick Hendrickson HISTORY: 07-267 m181 F03/0097 Submitted 07-267r2 m181 Passed by J3 meeting ---------------------------------------------------------------------- NUMBER: F03/0098 TITLE: Does allocate with source= define subcomponents? KEYWORDS: allocate, source, define DEFECT TYPE: Erratum STATUS: Passed by J3 meeting 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 they are defined by a SOURCE= specifier" [421:27-28] 16.5.6, list item 19, modify by adding after "Allocation of an object", "except by an ALLOCATE statement with a SOURCE= specifier". [421:28+] 16.5.6, 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] 16.5.6, list item (11) insert "with no SOURCE= specifier" after "ALLOCATE statement" [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 ---------------------------------------------------------------------- NUMBER: F03/0099 TITLE: Clause 16 does not account for volatile variable KEYWORDS: volatile, defined, undefined DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTION: Should the various lists in clause 16 that describe definition and association be modified to include the effects of volatile variables? In particular, 16.4.2.1.1 through 16.4.2.1.2 do not mention the fact that pointer association status can be volatile and change by other means. 16.5.4 says "all other variables are initially undefined.? Can a volatile variable be initially defined by other means? 16.5 (26) says volatile variables "become defined", but they also can become undefined, by other means. Allocatable volatile variables can become allocated or unallocated by other means also. ANSWER: Yes, the lists in clause 16 should be modified to include the effects of volatility. In addition, the effects of volatile on pointer objects are not completely specified in clause 5. The effect on allocatable objects is not complete in clause 6. EDITS: [85:10] In the paragraph between note 5.21 and note 5.22, change "association status and array bounds" to "association status, dynamic type and type parameters, and array bounds" [113:21+] Add a new paragraph at the end of 6.3.1.1 "The allocation status of an object with the VOLATILE attribute may change by means not specified by the program." [415:27] Add a new paragraph at the end of 16.4.2.1.4 "When a pointer object with the VOLATILE attribute is changed by a means not specified by the program it may become defined or undefined. In addition, its array bounds and association status may change. If it is polymorphic, its dynamic type and type parameters may change." [421:42-43] 16.5.5 Replace list item (26) with as text, not a list item "In addition, an object with the VOLATILE attribute (5.1.2.16) might become defined by a means not specified by the program." [423:28+] 16.5.6 insert as text after the last list item "In addition, an object with the VOLATILE attribute (5.1.2.16) might become undefined by a means not specified by the program." SUBMITTED BY: Dick Hendrickson HISTORY: 07-269 m181 F03/0099 Submitted 07-269r2 m181 Passed by J3 meeting ---------------------------------------------------------------------- NUMBER: F03/0100 TITLE: Error in field width for special cases of signed INFINITY output KEYWORDS: formatted output, signed infinity DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTION: Is there an error in the description for the output of a IEEE infinity with a sign and a field width of 3 or 8? 228:36-37 describes the output for an IEEE infinity and special cases field widths of 3 and 8. But, the special casing doesn't consider the possibility of a plus or minus sign in the field. A signed infinity should be special cased for field widths of 9 and 4. ANSWER: Yes, there is an error in the special cases. Edits are provided to correctly describe the required field widths for signed infinities. EDITS: [228:36-37] In the paragraph beginning "For an internal value that is an IEEE infinity." in 10.6.1.2.1 change "If is less than 3" to "If no sign is produced and is less than 3". Add after that sentence: "If a sign is produced and is less than 4, the field is filled with asterisks; otherwise, if is less than 9, the sign followed by 'Inf' is produced. " SUBMITTED BY: Dick Hendrickson HISTORY: 07-271 m181 F03/0100 Submitted 07-271r2 m181 Passed by J3 meeting ---------------------------------------------------------------------- NUMBER: F03/0101 TITLE: Is UDDTIO output suitable for namelist and list-directed input KEYWORDS:UDDTIO, list-directed I/O, namelist I/O DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTION: The first paragraph of 10.9.2 says that the form of the values produced by list-directed output is the same as that required for input. It also says values are separated blanks or commas, etc. The first paragraph of 10.10.2 has similar words for namelist output. It also requires that the variable name be produced in upper case and that the output consist of name-value pairs. Is it intended that output produced by used defined derived type routines conform to these rules? ANSWER: No, it was not intended to constrain the user derived type output values. There should be an exception similar to the one for adjacent un-delimited character values. User derived type output fields do not need to be readable by either namelist nor list-directed input EDITS: [241:5] Add at the end of the paragraph "The form of the output produced by a used-defined derived type output routine invoked during list-directed output is specified by the invoked routine. It need not be compatible with list-directed input or output." [246:4] After "and logical values" add ", and output produced by user-defined derived type output" [246:7] Add at the end of the paragraph "The form of the output produced by a used-defined derived type output routine invoked during namelist output is specified by the invoked routine. It need not be compatible with namelist input or output." SUBMITTED BY: Dick Hendrickson HISTORY: 07-275 m181 F03/0101 Submitted 07-275r2 m181 Passed by J3 meeting ----------------------------------------------------------------------