J3/00-328 Date: 2-Dec-2000 To: J3 Members From: interp/Stan Whitlock Subj: F95 interp letter ballot #3 - due 3-Nov-2000 Enclosed in the third letter ballot on Fortran 95 interpretations. The rules we operate on 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. 23 Fortran 95 interpretations were passed at J3 meeting #154. This is the letter ballot phase to go from "passed by J3 meeting" to "passed by J3 letter ballot". The following Fortran 95 interpretations are being balloted: Yes No Number Title --- --- 000014 Format of complex numbers in list-directed and namelist output --- --- 000015 Commas in list-directed output --- --- 000024 Termination of a partial record by a CLOSE, BACKSPACE, ENDFILE, or REWIND statement --- --- 000031 Association of pointer function result with INTENT(OUT) dummy argument --- --- 000032 Is the TRANSFER function result undefined? --- --- 000073 Is padding allowed in storage sequences? --- --- 000074 TARGET dummy arguments and POINTER expressions --- --- 000075 Defined assignment and INTENT(IN) dummy arguments in PURE procedures --- --- 000085 Public components of private types --- --- 000086 Definition status requirements for defined operations --- --- F90/000197 Relationship of NEAREST and SPACING --- --- F90/000205 Restrictions on EXTERNAL --- --- F90/000206 Collating sequence inconsistencies --- --- F90/000207 Integer bit-model inconsistency --- --- F90/000208 nonadvancing output followed by list directed output --- --- F90/000210 nonadvancing write followed by list directed write --- --- JP-04 Construction of derived-type values --- --- JP-05 Construction of array values --- --- JP-08 Type declaration statements --- --- JP-12 Bounds of each dimension of an array pointer --- --- JP-16 Multiple occurrence of namelist-group-name in NAMELIST statement --- --- JP-17 Multiple occurrence of namelist group object in namelist group --- --- JP-31 Signs of literal constants The text of these interpretetions is attached. Each interpretation starts with a row of "-"s. Please mark the above "yes" or "no" answer {be sure to include your reasons with "no"} and send only the above text {not this entire mail mail message} to x3j3@ncsa.uiuc.edu by Midnight, PDT, Friday, 3-Nov-2000, in order to be counted. Thanks /Stan --------------------------------------------------------------------- NUMBER: 000014 TITLE: Format of complex numbers in list-directed and namelist output KEYWORDS: DEFECT TYPE: STATUS: Passed by J3 meeting QUESTION: 1. The seventh paragraph of Section 10.8.2 of the Fortran 90 standard states that complex numbers must be written with no embedded blanks unless the complex constant is broken across two records. Some of the implementations I tested put a blank after the comma even when the entire constant fit in a single record. Is an implementation permitted to include a blank after the comma in a complex constant produced by list-directed output when the constant fits in a single record? 2. Is a blank permitted after the comma in a complex constant produced by namelist output when the constant fits in a single record? ANSWER: 1. No. Section 10.8.2 [178:2-3] states: "The only embedded blanks permitted within a complex constant are between the comma and the end of a record and one blank at the beginning of the next record." 2. No. Section 10.9.2.1 [182:40-41] states: "The only embedded blanks permitted within a complex constant are between the comma and the end of a record and one blank at the beginning of the next record." SUBMITTED BY: HISTORY: 97-165 m143 Submitted WG5/N1410 Draft answer 00-260 m154 Passed by J3 meeting --------------------------------------------------------------------- NUMBER: 000015 TITLE: Commas in list-directed output KEYWORDS: DEFECT TYPE: STATUS: Passed by J3 meeting QUESTION: 5. The first paragraph of Section 10.8.2 of the Fortran 90 standard states: With the exception of adjacent nondelimited character constants, the values are separated by one or more blanks or by a comma optionally preceded by one or more blanks and optionally followed by one or more blanks. I have yet to find a Fortran implementation, other than my own, that satisfies this requirement. In particular, the statement PRINT *, 1, ',', 2 prints a comma immediately following the 1 on every implementation I tried. The comma was followed by zero, one, or two blanks in different implementations. 1. Is a separator required between a constant other than a nondelimited character constant and a following nondelimited character constant in list-directed output? 2. Is a separator required between a nondelimited character constant and a following constant that is not a nondelimited character constant? DISCUSSION: It is not clear in the question if the comma which is output is the optional separator or is the character constant from the list. ANSWER: 1. Yes. 2. Yes. A separator is required in both cases. The text quoted, which is at page 177:31-33, is quite explicit. The key word is "adjacent". SUBMITTED BY: HISTORY: 97-165 m143 Submitted WG5/N1410 Draft answer 00-260 m154 Passed by J3 meeting ---------------------------------------------------------------------- NUMBER: 000024 TITLE: Termination of a partial record by a CLOSE, BACKSPACE, ENDFILE, or REWIND statement KEYWORDS: DEFECT TYPE: STATUS: Passed by J3 meeting QUESTION: Suppose a partial record has been written as a result of a nonadvancing WRITE. If the file is closed, or a BACKSPACE, ENDFILE, or REWIND statement is performed on the file, must the partial record be terminated? ANSWER: After a nonadvancing WRITE there is always a current record in a file. Existing descriptions of file closure and of the BACKSPACE, ENDFILE and REWIND statements define subsequent operations on the file. The standard does not have the concept of 'terminating' a partial record - the external representation of any file written by Fortran is processor dependent, including the means of determining record boundaries. However, a 'partial' record that has been written by a Fortran program ought to be readable by a Fortran program. Therefore, on a processor that uses line-feed characters to terminate records, either (i) the processor should emit a terminating line-feed in the situation described, or (ii) the processor should contain the capability to read an 'unterminated' partial record at the end of the file. EDIT: SUBMITTED BY: Robert Corbett HISTORY: 98-155 m145 Submitted (part 2) WG5/N1410 Draft answer 00-260 m154 Passed by J3 meeting ---------------------------------------------------------------------- NUMBER: 000031 TITLE: Association of pointer function result with INTENT(OUT) dummy argument KEYWORDS: Pointer association, dummy argument association, intent attribute DEFECT TYPE: STATUS: Passed by J3 meeting QUESTION: Consider the following program. PROGRAM P INTEGER, TARGET :: T CALL SUB(FPTR()) CONTAINS FUNCTION FPTR() INTEGER, POINTER :: FPTR FPTR => T END FUNCTION FPTR SUBROUTINE SUB(IO) INTEGER, INTENT(OUT) :: IO IO = 17 END SUBROUTINE SUB END PROGRAM P According to 12.4.1 [200:30-32], "If a dummy argument is not a pointer and the corresponding actual argument is a pointer, the actual argument shall be currently associated with a target and the dummy argument becomes argument associated with that target." According to 12.4.1 [201:19-21], "If a dummy argument has INTENT(OUT) or INTENT(INOUT), the actual argument shall be definable." According to 5.1.2.3 [53:29-31], "The INTENT(OUT) attribute specifies that. . . any actual argument that becomes associated with such a dummy argument shall be definable." The definition of "definable" supplied in Annex A (the term does not appear to be defined in normative text) is: "A variable is <> if its value may be changed by the appearance of its or on the left of an ." According to this definition, "definable" is a property of variables only. In the example above, the actual argument is not a variable. However, the actual argument is pointer associated with an object that is definable. The text cited from 5.1.2.3 refers to the "actual argument that becomes associated with the dummy argument", but the first piece of text cited from 12.4.1 makes it clear that when the actual argument is a pointer, it is the target with which it is associated that becomes argument associated with the dummy argument, and not the actual argument itself. Was it the intent of the committee that this program should not be standard-conforming? ANSWER: The program does not conform to the Standard. 12.4.1.1 [201:19-21] requires the actual argument to be definable and a function result is not definable. For example, it is not permitted on the left-hand side of an assignment statement, since it is not a variable. EDIT: None. SUBMITTED BY: Henry Zongaro HISTORY: 98-177 m146 Submitted WG5/N1414 Draft answer 00-260 m154 Passed by J3 meeting --------------------------------------------------------------------- NUMBER: 000032 TITLE: Is the TRANSFER function result undefined? KEYWORDS: transfer function, undefined, processor dependent DEFECT TYPE: STATUS: Passed by J3 meeting The result value section of the TRANSFER function says "...If the physical representation of the result is longer than that of SOURCE, the physical representation of the leading part is that of SOURCE and the remainder is undefined." ^^^^^^^^^^^^^^^^^^^^^^^^^^ and case (ii) gives an example of a transfer of 3 reals to 2 complexes with the imaginary part of the second complex being undefined. Where can you use this form of TRANSFER. There's a general prohibition about referencing undefined things. Doesn't that apply to expressions containing TRANSFER as well? Something like X = transfer (four_bytes,eight_bytes) or X = transfer(transfer(four_bytes,eight_bytes), four_bytes) reference the undefined part. Maybe in the latter case we could say that the "reference" in the outer transfer doesn't "require the value" of all of its argument. But that seems like an odd reading to me. We can't use it for functions like SIZE, because they only allow their argument to be undefined if it is a single variable name (13.8.5). The only thing I can think of is passing to a procedure argument that has no INTENT specified but that uses the defined part of the argument as if it were INTENT(IN). The intent can't be specified because INTENT(IN) arguments must be defined on entry. Question: Should the phrase be changed from "the remainder is undefined" to "the remainder is processor dependent"? DISCUSSSION: This is made more confusing by: "Any variable or function reference used as an operand shall be defined at the time the reference is executed." [97:1] The mention of function reference is confusing, because a function is not allowed to return without fully defining its result, viz "If the result variable is not a pointer, its value shall be defined by the function." [207:28] ANSWER: Yes, for the reasons given. Edits are provided. EDITS: Clause 13.14.110 Page 272, line 4. Change 'undefined' to 'processor dependent'. Page 272, line 17. Change 'undefined' to 'processor dependent'. SUBMITTED BY: Dick Hendrickson HISTORY: 98-183 Submitted WG5/N1414 Draft answer 00-260 m154 Passed by J3 meeting ---------------------------------------------------------------------- NUMBER: 000073 TITLE: Is padding allowed in storage sequences? KEYWORDS: alignment, padding, storage sequence DEFECT TYPE: STATUS: Passed by J3 meeting QUESTION: 1. Is padding allowed in storage sequences? Consider the common block CHARACTER C INTEGER I COMMON /CBLK/ C, I 2. Is padding allowed between the variables C and I? Consider the sequence type TYPE T SEQUENCE CHARACTER C INTEGER I END TYPE 3. Is padding allowed between component C and component I? Discussion: A user recently complained that Sun f90 adds pad for alignment to sequence types and common blocks. He asserted that the Fortran standard forbids padding storage sequences. I have tested seven different implementations, and I found that all but one use padding in the examples given. The user based his assertion on the text of Section 14.6.3.1 of the Fortran 95 standard. He claimed the statements (7) A nonpointer scalar object of sequence type occupies a sequence of storage sequences corresponding to the sequence of its ultimate components and The order of the storage units in such a composite storage sequence is that of the individual storage units in each of the constituent storage sequences taken in succession, ignoring any zero-sized constituent sequences. made his case. I pointed out that where the standard intends to require storage units to be contiguous, it uses the word "contiguous". He was not satisfied by that answer. The user pointed out that the definition of the size of a storage sequence supports his assertion. He claimed that the size of the common block given above is one character storage unit plus one numeric storage unit, and that that is the size of the common block INTEGER J CHARACTER D COMMON /CBLK/ J,D which Sun f90 does not pad. While that arithmetic of sizes makes sense, I have been told informally by a committee member that that was not the intent of the committee. Note 5.33 lends support to his statement. I have been unable to find any for the first paragraph of Note 5.33 in the normative part of the standard. I suggest moving the first paragraph of Note 5.33 to the normative part of the standard. I tried to provide a definition of addition of sizes of different storage units that would imply the effect stated in Note 5.33, but I failed. ANSWER: 1. Yes. Padding between storage units is allowed unless those storage units are explicitly required to be contiguous in Section 14.6.3.1 or they are required to be contiguous in order to satisfy the storage association rules given in Sections 14.6.3.2 and 14.6.3.3. Note 5.33 (page 70) states: 'A common block is permitted to contain sequences of different storage units'. This is a consequence of the absence of any requirement on the types of the variables in a common block. It further states 'provided each scoping unit that accesses the common block specifies an identical sequence of storage units for the common block'. This is an informal rewording of the rules on common association which are found in sections 5.5.2.1 and 5.5.2.3, and the rules on storage association which are in 14.6.3. Note 5.33 does not prohibit padding between sequences of storage units, but any such padding is required to be consistent between scoping units. 2. Yes. 3. Yes. REFERENCES: ISO/IEC 1539-1:1997(E), Note 5.33 and Section 14.6.3. EDITS: None. SUBMITTED BY: Robert Corbett HISTORY: 99-190 m150 submitted (straw vote to allow padding 11-0-0) WG5/N1414 Draft answer 00-260 m154 Passed by J3 meeting ---------------------------------------------------------------------- NUMBER: 000074 TITLE: TARGET dummy arguments and POINTER expressions KEYWORDS: TARGET, POINTER, dummy arguments DEFECT TYPE: STATUS: Passed by J3 meeting 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: 1. The call to s1 is not standard conforming. 12.5.2.1 says: 'A dummy data object whose intent is not specified is subject to the limitations of the data entity that is the associated actual argument. That is, a reference to the dummy data object may occur if the actual argument is defined and the dummy data object may be defined if the actual argument is definable.' Here the actual argument is a function result, which is not definable. For example, it is not permitted on the left-hand side of an assignment statement, since it is not a variable. 2. The call to s2 is not standard conforming. 12.4.1.1 says: 'If a dummy argument has INTENT(OUT) or INTENT(INOUT), the actual argument shall be definable.' Again the actual argument is a function result, 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.1, which says [200:38-42]: 'If the dummy argument has the TARGET attribute and is either scalar or is an assumed-shape array, and the corresponding actual argument has the TARGET attribute but is not an array section with a vector subscript (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 submitted WG5/N1414 Draft answer 00-260 m154 Passed by J3 meeting ---------------------------------------------------------------------- NUMBER: 000075 TITLE: Defined assignment and INTENT(IN) dummy arguments in PURE procedures KEYWORDS: INTENT(IN), PURE, defined assignment, dummy arguments DEFECT TYPE: STATUS: Passed by J3 meeting QUESTION: Consider the following module: MODULE m TYPE t REAL,POINTER :: value END TYPE INTERFACE ASSIGNMENT(=) MODULE PROCEDURE t_asgn_t END INTERFACE CONTAINS PURE SUBROUTINE t_asgn_t(lhs,rhs) TYPE(t),INTENT(OUT) :: lhs TYPE(t),INTENT(IN) :: rhs ALLOCATE(lhs%value) lhs%value = rhs%value END SUBROUTINE PURE FUNCTION t_plus_t(a,b) TYPE(t) t_plus_t,a,b INTENT(IN) a,b t_plus_t = a !defined assignment !Alternative: CALL t_asgn_t(a,b) t_plus_t%value = t_plus_t%value + b%value END FUNCTION END According to F95 [212:33-45] "Constraint: In a pure subprogram any variable which ... is a dummy argument to a pure function ... shall not be used in the following contexts: ... (8) As the of an in which the is of a derived type if the derived type has a pointer component at any level of component selection; ..." Therefore it appears that the statement labelled "defined assignment" is not allowed. However, it is semantically equivalent to the commented-out statement in the following line, which would have been allowed. Clearly intrinsic assignment in that context must be disallowed as it implicitly does a pointer assignment which could be used to produce a side-effect, but the standard appears to rule out defined assignment as well (which if pure cannot cause any side-effect). Is this intentional? ANSWER: No. (8) should apply only to intrinsic assignment so the example is correct. EDIT: Clause 12.6. Penultimate line of page 212 [212:44]. Change to 'intrinsic assignment statement'. SUBMITTED BY: Malcolm Cohen HISTORY: 99-201 m150 submitted WG5/N1414 Draft answer 00-260 m154 Passed by J3 meeting ---------------------------------------------------------------------- NUMBER: 000085 TITLE: Public components of private types KEYWORDS: Accessibility, Derived Types, Components DEFECT TYPE: STATUS: Passed by J3 meeting QUESTION: F90 interpretation 32 indicated that components of a derived type may be accessible even in scopes where the derived type name is inaccessible. It added an edit to 12.1.2.2.1 of f90 (14.6.1.3 of f95) saying "If a derived type name of a host is inaccessible, data entities of that type or subobjects of such data entities can still be accessible." The discussions in the last 2 paragraphs of 4.4.1 of f95 appear to treat the accessibility of the derived type and its components as independent issues. Drafts of f2k added a note to make the independence clear. However, 14.1.2.5 of f95 says "If the type is accessible...and the definition of the type does not contain the PRIVATE statement (4.4.1), the component name is accessible...." This statement appears to make accessibility of the type a condition for accessibility of the component names, in contradiction with the above cited edit from f90 interpretation 32. The following code sample illustrates the issue. This sample works on several f90 compilers. module m type t integer :: i end type t type (t) :: a end module m program p use m, only: a a%i = 2 write (*,*) a%i end program p Question 1. Is it allowed to access public components of a derived type object when the type name is inaccessible as illustrated in the above sample code? Question 2. Should there be an edit in 14.1.2.5 of f95 to clarify this? ANSWER: (1) Yes. (2) No. DISCUSSION: The quoted text from 14.1.2.5 specifies the accessibility of components when a type does not contain the PRIVATE statement. It does not specify the accessibility of components when a type does contain the PRIVATE statement; this is specified in the referenced section 4.4.1. Deleting the text in 14.1.2.5 [280:25-28] would result in the accessibility of components of non-opaque types being undefined in the standard. EDIT: None. SUBMITTED BY: Richard Maine HISTORY: 99-101 m148 Submitted WG5/N1404 Draft answer 00-260 m154 Passed by J3 meeting ---------------------------------------------------------------------- NUMBER: 000086 TITLE: Definition status requirements for defined operations KEYWORDS: Defined operations DEFECT TYPE: STATUS: Passed by J3 meeting QUESTION: 7.1.7 "Evaluation of operations" states "This section applies to both intrinsic and defined operations. Any variable ... used as an operand in an expression shall be defined at the time the reference is executed." (1) Was this particular requirement intended to apply to defined operations? I.e., is the following example program invalid: MODULE m INTERFACE OPERATOR (.cand.) MODULE PROCEDURE default_cand END INTERFACE CONTAINS LOGICAL FUNCTION default_cand(a,b) RESULT(r) LOGICAL,INTENT(IN) :: a,b IF (a) THEN r = b ELSE r = .FALSE. END IF END FUNCTION END PROGRAM example1 USE m LOGICAL :: false = .FALSE. LOGICAL :: undefined PRINT *, false .cand. undefined END (2) If the answer to the question is Yes (and the program is therefore invalid), would the program be standard-conforming if the penultimate line were changed to PRINT *, default_cand(false,undefined) ? (3) 7.1.7 goes on to state "When a structure is referenced, all of the components shall be defined." Does this mean that pointer components must be associated with a defined target? I.e. is the following program non-conforming? MODULE m2 TYPE my_iptr PRIVATE INTEGER,POINTER :: ptr => NULL() END TYPE INTERFACE OPERATOR(.isnull.) MODULE PROCEDURE isnull_myip END INTERFACE CONTAINS LOGICAL FUNCTION isnull_myip(x) TYPE(my_iptr),INTENT(IN) :: x isnull_myip = ASSOCIATED(x%ptr) END FUNCTION END PROGRAM example2 TYPE(my_iptr) a PRINT *,.isnull.a END (4) If the program is not standard-conforming, would changing the penultimate line to "PRINT *,isnull_myip(a)" make it standard-conforming. ANSWER: (1) No, the requirement was not intentional. (3) No, this was a mistake. Discussion: Usage of defined operations is intended to be equivalent to ordinary function references. All of the examples given above are standard-conforming. EDITS: [97:1] Replace "in an expression" with "of an intrinsic operation". {Only require operands to be defined for intrinsic operations.} [97:5] Replace "all of its components" with "it". {A structure may be referenced whenever it is defined.} HISTORY: 00-292 m154 Submitted; Passed by J3 meeting ---------------------------------------------------------------------- NUMBER: F90/000197 TITLE: Relationship of NEAREST and SPACING KEYWORDS: NEAREST, SPACING, "machine representable" DEFECT TYPE: STATUS: Passed by J3 meeting QUESTION: The example in the SPACING intrinsic function description states: SPACING(3.0) has the value 2**(-22) for reals whose model is as at the end of 13.7.1. The example in the NEAREST intrinsic function description states: NEAREST(3.0, 2.0) has the value 3 + 2**(-22) on a machine whose representation is that of the model at the end of 13.7.1. Must the delta computed by NEAREST (the 2**(-22) shown in the example) be the value SPACING would return if given the same (first) argument as passed to NEAREST? ANSWER: No. DISCUSSION: The result of NEAREST depends on the characteristics of machine numbers, whereas the result of SPACING depends on the characteristics of model numbers. If there are one or more machine numbers in between two adjacent model numbers, the results of SPACING and NEAREST will not be consistent with each other. EDIT(S): None. SUBMITTED BY: Larry Rolison HISTORY: 95-030 m132 submitted WG5/N1404 Draft answer 00-260 m154 Passed by J3 meeting ---------------------------------------------------------------------- NUMBER: F90/000205 TITLE: Restrictions on EXTERNAL KEYWORDS: EXTERNAL attribute, external subprogram DEFECT TYPE: STATUS: Passed by J3 meeting QUESTION: Let the following two procedures not be contained within a main program, a module, or another subprogram. In this case they are <>s by the definitions of Fortran 90, section 2.2: SUBROUTINE subroutine_subprogram ( ) ! ... END SUBROUTINE subroutine_subprogram FUNCTION function_subprogram ( ) INTEGER :: function_subprogram ! ... END FUNCTION function_subprogram They are also external procedures, since F90 section 2.2.3.1 (and 12.1.2.2) states that "An <> is a procedure that is defined by an external subprogram or by means other than Fortran." External functions may be given the EXTERNAL attribute in form of an (R503), external procedures may be given the EXTERNAL attribute by an (R1207) [F95: R1208]. QUESTION 1: Is it correct that the current definitions in F90 do allow the EXTERNAL attribute to be specified for the name of the external subprogram in which such a declaration is contained? In other words, is the following code standard-conforming? SUBROUTINE subroutine_subprogram ( ) EXTERNAL subroutine_subprogram ! ... END SUBROUTINE subroutine_subprogram FUNCTION function_subprogram ( ) INTEGER, EXTERNAL :: function_subprogram ! ... END FUNCTION function_subprogram QUESTION 2: If the answer to question 1 is YES: was this the intention, or should it be prohibited that an EXTERNAL attribute is given to the name of an external subprogram by declarations within that subprogram? ANSWER: 1. No, the EXTERNAL attribute may not be specified for the name of an external subprogram within that subprogram. 2. Not applicable. DISCUSSION: Appearance of a name as the in a or the in a , that is not in an or a , explicitly specifies that the name is that of an external procedure and has the EXTERNAL attribute. The second constraint in 5.1 states "An entity shall not be explicitly given any attribute more than once in a scoping unit." Section 5.2 makes it clear that this applies to EXTERNAL statements. Therefore, the EXTERNAL statements in the example are duplicate specifications and so not standard-conforming. EDIT: None. SUBMITTED BY: Michael Hennecke (hennecke@rz.uni-karlsruhe.de) HISTORY: 96- m136 submitted WG5/N1404 Draft answer 00-260 m154 Passed by J3 meeting ---------------------------------------------------------------------- NUMBER: F90/000206 TITLE: Collating sequence inconsistencies KEYWORDS: Collating sequence, ACHAR, CHAR, ICHAR DEFECT TYPE: STATUS: Passed by J3 meeting [F95 CD 36:28+] says that "A <> is a one-to-one mapping of the characters into the nonnegative integers such that each character corresponds to a different nonnegative integer." QUESTION 1: Does this definition imply that the one-to-one mapping is dense? That is, is there a requirement that if the default CHARACTER type has characters, the corresponding collating sequence maps to 0..-1 ? QUESTION 2: If the answer to question 1 is NO: is it correct that the restriction 0 <= i <= -1 on argument I of the intrinsic procedure CHAR (13.14.19) is inappropriate? QUESTION 3: If the answer to question 1 is NO: is it correct that the description of the <> of the intrinsic procedure ICHAR (13.14.45), 0 <= ICHAR(C) <= -1 is inappropriate? QUESTION 4: Shouldn't argument I of the intrinsic procedure ACHAR (13.14.2) be restricted to the nonnegative integers? ANSWER: (1) No, the definition in isolation would not require a "dense" mapping. However, in conjunction with the requirements on the CHAR and ICHAR intrinsic functions, the mapping is required to be "dense". (2) No, they are part of the specification of the required mapping. (3) No. (4) No. For characters that are not part of the ASCII character set, IACHAR returns a processor-dependent value that need not be in the ASCII collating sequence. ACHAR, being the inverse of IACHAR, should accept such values. EDIT: None. SUBMITTED BY: Michael Hennecke (hennecke@rz.uni-karlsruhe.de) HISTORY: submitted Feb. 17, 1996 (first appeared in 96-006r2) WG5/N1404 Draft answer 00-260 m154 Passed by J3 meeting ---------------------------------------------------------------------- NUMBER: F90/000207 TITLE: Integer bit-model inconsistency KEYWORDS: Bit manipulation procedures, models for integer data DEFECT TYPE: STATUS: Passed by J3 meeting QUESTION: Is the following observation true? [F90 185:last sentence of 13.5.7] and [WG5/N1176, 219:22+] says ``In particular, whereas the models are identical for w_{z-1}=0, they do not correspond for w_{z-1}=1 and ...'' This statement assumes r==2 in the model for integer data defined in 13.7.1, it is not true for general r. The above sentence should be changed to something like ``In particular, whereas the models are identical for r=2 and w_{z-1}=0, they do not correspond for r/=2 or w_{z-1}=1, and ...'' ANSWER: Yes. DISCUSSION: We want to allow BCD machines to be able to do bit manipulation efficiently, without requiring them to perform binary-decimal conversions around each use of a bit manipulation intrinsic. This will necessarily lose the connection between the bit settings and the values. EDIT: [219:23] Insert "r==2 and" at the beginning of the line, and Insert "r/=2 or" after "for". SUBMITTED BY: Michael Hennecke (hennecke@rz.uni-karlsruhe.de) HISTORY: submitted Mar. 12, 1996 (first appeared in 96-006r2) WG5/N1404 Draft answer 00-260 m154 Passed by J3 meeting ---------------------------------------------------------------------- NUMBER: F90/000208 TITLE: nonadvancing output followed by list directed output KEYWORDS: DEFECT TYPE: STATUS: Passed by J3 meeting QUESTION: Section 10.8.2, last sentence. If nonadvancing output is followed by list-directed output, is a blank required before the first character written? (I assume that if the first character of the current record is not a blank, list-directed output is not required, though possibly permitted, to replace that character with a blank.) ANSWER: No. DISCUSSION: If the list-directed WRITE does not start a new record before output of the first list item, it need not output a blank. [178:24] states "each output record begins with a blank". If the first character of the current record is not a blank, the processor must ensure that compliance with [178:24] is achieved by beginning a new record before the output of any list item. EDIT: None. SUBMITTED BY: Robert Paul Corbett (robert.corbett@Eng.sun.com) HISTORY: submitted Mar. 13, 1996 (first appeared in 96-006r2) WG5/N1404 Draft answer 00-260 m154 Passed by J3 meeting ---------------------------------------------------------------------- NUMBER: F90/000210 TITLE: nonadvancing write followed by list directed write KEYWORDS: DEFECT TYPE: STATUS: Passed by J3 meeting QUESTION: If a program does a nonadvancing WRITE followed by a list-directed WRITE, must the list-directed WRITE write to the current record or may it start a new record? For what it's worth, CRI f90 starts a new record. ANSWER: The processor may start a new record whenever it deems it necessary, subject to the restrictions at [177:34-36], which states "The processor may begin new records as necessary ..." This includes at the beginning of a list-directed WRITE. EDIT: None. SUBMITTED BY: Robert Paul Corbett (robert.corbett@Eng.sun.com) HISTORY: submitted Mar. 13, 1996 (first appeared in 96-006r2) WG5/N1404 Draft answer 00-260 m154 Passed by J3 meeting ---------------------------------------------------------------------- NUMBER: JP-04 TITLE: Construction of derived-type values KEYWORDS: DEFECT TYPE: STATUS: Passed by J3 meeting QUESTION: JP-4) 4.4.4 Construction of derived-type values Before NOTE 4.34: "Where a component in the derived type is a pointer, the corresponding constructor expression shall evaluate to an object that would be an allowable target for such a pointer in a pointer assignment statement(7.5.2)." Change `an object' to `a result value'. A value of an expression can not be an object, by definition. ANSWER: Agreed. EDIT: [45:8] Replace "an object" by "a result value". SUBMITTED BY: Japan HISTORY: 99-208 Submitted 99-221 Classed as Fortran 95 Interpretation. WG5-N1411 Draft answer 00-260 m154 Passed by J3 meeting ---------------------------------------------------------------------- NUMBER: JP-05 TITLE: Construction of array values KEYWORDS: DEFECT TYPE: STATUS: J3 consideration in progress QUESTION: JP-5) 4.5 Construction of array values, "The ac-do-variable of an ac-implied-do that is in another ac-implied-do shall not appear as the ac-do-variable of the containing ac-implied-do." This sentence should be a Constraint. ANSWER: Agreed. EDIT: [45:36+] Add: "Constraint: The ac-do-variable of an ac-implied-do that is in another ac-implied-do shall not appear as the ac-do-variable of the containing ac-implied-do." [46:3-5] Delete the sentence "The ac-do-variable ... ac-implied-do.". SUBMITTED BY: Japan HISTORY: 99-208 Submitted 99-221 Classed as Fortran 95 Interpretation. WG5-N1411 Draft answer 00-260 m154 Passed by J3 meeting ---------------------------------------------------------------------- NUMBER: JP-08 TITLE: Type declaration statements KEYWORDS: DEFECT TYPE: STATUS: Passed by J3 meeting QUESTION: JP-8) 5.1 Type declaration statements After NOTE 5.3 [49:8]: "If a length-selector (5.1.1.5) is a nonconstant expression, ..." Change `length-selector' to `char-selector', `char-len-selector' or `character-length'. ANSWER: Agreed, but with 'char-length' as the substitute text. EDIT: [49:5] Replace "length-selector" by "char-length or char-len-param-value". SUBMITTED BY: Japan HISTORY: 99-208 Submitted 99-221 Classed as Fortran 95 Interpretation. WG5-N1411 Draft answer 00-260 m154 Passed by J3 meeting ---------------------------------------------------------------------- NUMBER: JP-12 TITLE: Bounds of each dimension of an array pointer KEYWORDS: DEFECT TYPE: STATUS: Passed by J3 meeting QUESTION: JP-12) 5.1.2.4.3 (2) after R518 (Page 55 Line 41) states that: "(2) They are specified in a pointer assignment statement. ..." In this description, the term "pointer assignment statement" should be changed to "pointer assignment". Reason : The bounds of each dimension of an array pointer may be specified not only in a pointer assignment statement but also in a derived-type intrinsic assignment statement with a component of an array pointer. ANSWER: Agreed EDIT: [55:41] Delete "statement" and replace "in a" with "by". SUBMITTED BY: Japan HISTORY: 99-208 Submitted 99-221 Classed as Fortran 95 Interpretation. WG5-N1411 Draft answer 00-260 m154 Passed by J3 meeting ---------------------------------------------------------------------- NUMBER: JP-16 TITLE: Multiple occurrence of namelist-group-name in NAMELIST statement KEYWORDS: DEFECT TYPE: STATUS: Passed by J3 meeting QUESTION: JP-16) 5.4 2nd paragraph after R545 and constraints (Page 66 Line 11) states that: "Any namelist-group-name may occur in more than one NAMELIST statement in a scoping unit." Can a namelist-group-name occur more than once in one NAMELIST statement ? Is the following NAMELIST statement standard conforming ? NAMELIST /NLIST/ A, B /NLIST/ C, D If this is standard conforming, is it the same as the following ? NAMELIST /NLIST/ A, B, C, D ANSWER: Yes, the rules should be analogous to those for named common blocks at [69:16-19]. EDIT: [66:11] Replace "in more than one" by "more than once in one or more" [66:11] Replace "statement" by "statements" SUBMITTED BY: Japan HISTORY: 99-208 Submitted 99-221 Classed as Fortran 95 Interpretation. WG5-N1411 Draft answer 00-260 m154 Passed by J3 meeting ---------------------------------------------------------------------- NUMBER: JP-17 TITLE: Multiple occurrence of namelist group object in namelist group KEYWORDS: DEFECT TYPE: STATUS: Passed by J3 meeting QUESTION: JP-17) 5.4 3rd paragraph after R545 and constraints states that: "A namelist group object may be a member of more than one namelist group." Can a namelist group object occur more than once in one namelist group? Is the following NAMELIST statement standard conforming? NAMELIST /NLIST/A,B,A ANSWER: No. EDIT: [66:14] Add new sentence at the end of the line: "A namelist group object shall not appear more than once in a single namelist group." SUBMITTED BY: Japan HISTORY: 99-208 Submitted 99-221 Classed as Fortran 95 Interpretation. WG5-N1411 Draft answer 00-260 m154 Passed by J3 meeting ---------------------------------------------------------------------- NUMBER: JP-31 TITLE: Signs of literal constants KEYWORDS: DEFECT TYPE: STATUS: Passed by J3 meeting QUESTION: JP-31) The fourth sentence of 10.8 and sixth sentence of 10.9: "Each value is either a null value or one of the forms: c r*c r* where c is a literal constant or a nondelimited character constant and r is an unsigned, nonzero, integer literal constant." "a literal constant" should be "an optionally signed literal constant" ANSWER: Add the phrase, "if integer or real" to that last phrase above. EDIT: [175:5] Replace "constant or" by "constant, optionally signed if integer or real, or" [178:40] Replace "constant or" by "constant, optionally signed if integer or real, or" Note for F2000: The phrase "literal constant" [73:34] in F95 is not the BNF term but F95 doesn't say if "literal constant" is signed. SUBMITTED BY: Japan HISTORY: 99-208 Submitted 99-221 Classed as Fortran 95 Interpretation. WG5-N1411 Draft answer 00-260 m154 Passed by J3 meeting