J3/00-260 To: J3 From: John Reid Date: 23-August-2000 Subject: Draft interpretations from WG5 WG5 offers J3 the following draft interpretations. They are reproduced from ISO/IEC JTC1/SC22/WG5 papers N1404, N1410, N1411 and N1414. In the case of JP-39, the Japanese member body wishes to withdraw the interpretation request, so this one can be closed. In the following cases, WG5 is aware that these are very preliminary drafts: 023. 025. 026. 074, statement 3 I will start an email discussion of the issues soon. WG5 also considered 021 without deciding how best to respond. I will start an email discussion of this, too. ---------------------------------------------------------------------- NUMBER: 000013 TITLE: Format of zero in list-directed and namelist output KEYWORDS: DEFECT TYPE: STATUS: J3 consideration in progress QUESTION: 1. The fifth paragraph of Section 10.8.2 of the Fortran 90 standard clearly indicates that in list-directed output zero must be formatted according to exponential format. Most, though not all, of the implementations I tried use fixed format. Even the FCVS test suite assumes fixed format. Should exponential format be used for zero in list-directed output? 2. The same issue raised in question 1 applies to namelist output (see Section 10.9.2.1, paragraph 3). Should exponential format be used for zero in namelist output? ANSWER: These questions are duplicated in interpretation number 000067. See the answer to that query. HISTORY: 97-165 m143 Submitted WG5/N1410 Draft answer ---------------------------------------------------------------------- NUMBER: 000014 TITLE: Format of complex numbers in list-directed and namelist output KEYWORDS: DEFECT TYPE: STATUS: J3 consideration in progress QUESTION: 3. 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? 4. Is a blank permitted after the comma in a complex constant produced by namelist output when the constant fits in a single record? ANSWER: 3. 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." 4. 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 ---------------------------------------------------------------------- NUMBER: 000015 TITLE: Commas in list-directed output KEYWORDS: DEFECT TYPE: STATUS: J3 consideration in progress 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. Is a separator required between a constant other than a nondelimited character constant and a following nondelimited character constant in list-directed output? 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: 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 ---------------------------------------------------------------------- NUMBER: 000023 TITLE: Termination of the previous record by a WRITE statement KEYWORDS: DEFECT TYPE: STATUS: J3 consideration in progress QUESTION: Suppose a sequential formatted file is positioned within a record as a result of a nonadvancing READ. 1. If the next operation performed on the file is a WRITE, can the current record be terminated at its current position before the next record is written? Section 9.2.1.3.2 appears to preclude the record from being terminated, but at least one Fortran 90 implementation does the record in such an instance. 2. If next operation is a nonadvancing WRITE and the number of characters written does not extend to the end of the current record, are the remaining characters at the end of the record preserved? ANSWER: 1. No. If the current record were to be terminated, the file position would be changed. Section 9.2.1.3.2 [136:37-39] states: "For sequential access on input, if there is a current record, the file position is not changed. Otherwise, the file is positioned at the beginning of the next record and this record becomes the current record." 2. No, the remaining characters in the record are not preserved. The characters are inaccessible. An edit to section 9.2.1.3.2 to clarify the situation is given below. EDIT: [136:44] Change "record becomes" to "record, excluding any data beyond the current point, becomes" SUBMITTED BY: Robert Corbett HISTORY: 98-155 m145 Submitted (part 1) WG5/N1410 Draft answer ---------------------------------------------------------------------- NUMBER: 000024 TITLE: Termination of a partial record by a CLOSE, BACKSPACE, ENDFILE, or REWIND statement KEYWORDS: DEFECT TYPE: STATUS: J3 consideration in progress 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 ---------------------------------------------------------------------- NUMBER: 000025 TITLE: List-directed input: types of variables corresponding to repeated values KEYWORDS: DEFECT TYPE: STATUS: J3 consideration in progress QUESTION: When a repeat count is used in list-directed input, must all the variables into which the repeated value is read have the same type? I see no reason in the standard to assume that restriction, but at least one Fortran 90 implementation assumes it ANSWER: DISCUSSION: Section 10.8 [175:7-9] states: "The r*c form is equivalent to r successive appearances of the constant c, and the r* form is equivalent to r successive appearances of the null value." WG5/interp was unable to agree on whether r*c implied r copies of the characters in c or r copies of the constant implied by c, possibly after the association of the first copy in the input record with its associated list item. Both interpretations are possible from the text. The answer to the question is accordingly no or yes. SUBMITTED BY: Robert Corbett HISTORY: 98-155 m145 Submitted (part 3) WG5/N1410 Draft answer ---------------------------------------------------------------------- NUMBER: 000026 TITLE: List-directed input: types of variables corresponding to repeated values KEYWORDS: DEFECT TYPE: STATUS: J3 consideration in progress QUESTION: Consider the example CHARACTER*80 STRING COMPLEX Z READ (*, *) Z, STRING Support the input consists of 2*(1.0, 0.0) After the READ, should Z contain (1.0,0.0) and should STRING contain '(1.0,'? ANSWER: (If the first interpretation of r*c in 000025 is correct) No. Z should contain (1.0,0.0) but STRING should contain '(1.0'. The form of the value separator generated by the r*c form is not defined, but any blanks which might notionally be inserted in the input record would be part of the separator and could not be part of the nonlimited character constant read into STRING (Note 10.28). Hence the first character in string is '('. Section 10.8.1 [176:19-20] states: "If the delimiters are omitted, the character sequence is terminated by the first blank, comma, slash, or end of record". Hence the last character in STRING is '0'. (If the second interpretation of r*c in 000025 is correct) No. This is a non- standard conforming statement. SUBMITTED BY: Robert Corbett HISTORY: 98-155 m145 Submitted (part 4) WG5/N1410 Draft answer ---------------------------------------------------------------------- NUMBER: 000031 TITLE: Association of pointer function result with INTENT(OUT) dummy argument KEYWORDS: Pointer association, dummy argument association, intent attribute DEFECT TYPE: STATUS: J3 consideration in progress 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 ---------------------------------------------------------------------- NUMBER: 000032 TITLE: Is the TRANSFER function result undefined? KEYWORDS: transfer function, undefined, processor dependent DEFECT TYPE: STATUS: J3 consideration in progress 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 ---------------------------------------------------------------------- NUMBER: 000073 TITLE: Is padding allowed in storage sequences? KEYWORDS: alignment, padding, storage sequence DEFECT TYPE: STATUS: J3 consideration in progress QUESTION: Is padding allowed in storage sequences? Consider the common block CHARACTER C INTEGER I COMMON /CBLK/ C, I Is padding allowed between the variables C and I? Consider the sequence type TYPE T SEQUENCE CHARACTER C INTEGER I END TYPE 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: 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. 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 ---------------------------------------------------------------------- NUMBER: 000074 TITLE: TARGET dummy arguments and POINTER expressions KEYWORDS: TARGET, POINTER, dummy arguments DEFECT TYPE: STATUS: J3 consideration in progress 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 ---------------------------------------------------------------------- NUMBER: 000075 TITLE: Defined assignment and INTENT(IN) dummy arguments in PURE procedures KEYWORDS: INTENT(IN), PURE, defined assignment, dummy arguments DEFECT TYPE: STATUS: J3 consideration in progress 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. 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 ---------------------------------------------------------------------- NUMBER: 000085 TITLE: Public components of private types KEYWORDS: Accessibility, Derived Types, Components DEFECT TYPE: STATUS: J3 consideration in progress 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.1.6.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? FIX TYPO: Fix typo in question "14.1.6.3" -> "14.6.1.3". 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 ---------------------------------------------------------------------- NUMBER: F90/000197 TITLE: Relationship of NEAREST and SPACING KEYWORDS: NEAREST, SPACING, "machine representable" DEFECT TYPE: STATUS: J3 consideration in progress 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 ---------------------------------------------------------------------- NUMBER: F90/000205 TITLE: Restrictions on EXTERNAL KEYWORDS: EXTERNAL attribute, external subprogram DEFECT TYPE: STATUS: J3 consideration in progress 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: No, the EXTERNAL attribute may not be specified for the name of an external subprogram within that subprogram. 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 ---------------------------------------------------------------------- NUMBER: F90/000206 TITLE: Collating sequence inconsistencies KEYWORDS: Collating sequence, ACHAR, CHAR, ICHAR DEFECT TYPE: STATUS: J3 consideration in progress [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 ---------------------------------------------------------------------- NUMBER: F90/000207 TITLE: Integer bit-model inconsistency KEYWORDS: Bit manipulation procedures, models for integer data DEFECT TYPE: STATUS: J3 consideration in progress 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 ---------------------------------------------------------------------- NUMBER: F90/000208 TITLE: nonadvancing output followed by list directed output KEYWORDS: DEFECT TYPE: STATUS: J3 consideration in progress 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 ---------------------------------------------------------------------- NUMBER: F90/000210 TITLE: nonadvancing write followed by list directed write KEYWORDS: DEFECT TYPE: STATUS: J3 consideration in progress 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. ---------------------------------------------------------------------- NUMBER: JP-4 TITLE: Construction of derived-type values KEYWORDS: DEFECT TYPE: STATUS: J3 consideration in progress 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 ---------------------------------------------------------------------- NUMBER: JP-5 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 ---------------------------------------------------------------------- NUMBER: JP-6 TITLE: Type declaration statements KEYWORDS: DEFECT TYPE: STATUS: J3 consideration in progress QUESTION: JP-6) 5.1 Type declaration statements As for the 16th and 19th constraint after R506: the 16th: "Constraint: The function-name shall be the name of an external function, an intrinsic function, a function dummy procedure, or a statement function." Because the syntactic class `object-name' is only defined as a `name' in the standard, the following constraint should be added here: Constraint: The object-name shall be the name of a data object. After that, in the 19th: "Constraint: initialization shall not appear if object-name is dummy argument, a dummy argument, a function result, an object in a named common block unless the type declaration is in a block data program unit, an object in blank common, an allocatable array, an external name, an intrinsic name, or an automatic object." In the above, `a function result,' should be removed. If we can not add the constraint above, `a statement function' should be added in the 19th constraint. DISCUSSION: There is a typographical error in the quoted 19th constraint in the question in that "dummy argument" appears twice. ANSWER: Agreed. EDIT: [48:26+] Add: "Constraint: The object-name shall be the name of a data object." [48:31] Delete "a function result,". SUBMITTED BY: Japan HISTORY: 99-208 Submitted 99-221 Classed as Fortran 95 Interpretation. WG5-N1411 draft answer ---------------------------------------------------------------------- NUMBER: JP-8 TITLE: Type declaration statements KEYWORDS: DEFECT TYPE: STATUS: J3 consideration in progress QUESTION: JP-8) 5.1 Type declaration statements After NOTE 5.3: "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". SUBMITTED BY: Japan HISTORY: 99-208 Submitted 99-221 Classed as Fortran 95 Interpretation. WG5-N1411 draft answer ---------------------------------------------------------------------- NUMBER: JP-12 TITLE: Bounds of each dimension of an array pointer KEYWORDS: DEFECT TYPE: STATUS: J3 consideration in progress 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". SUBMITTED BY: Japan HISTORY: 99-208 Submitted 99-221 Classed as Fortran 95 Interpretation. WG5-N1411 draft answer ---------------------------------------------------------------------- NUMBER: JP-16 TITLE: Multiple occurrence of namelist-group-name in NAMELIST statement KEYWORDS: DEFECT TYPE: STATUS: J3 consideration in progress 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 ---------------------------------------------------------------------- NUMBER: JP-17 TITLE: Multiple occurrence of namelist group object in namelist group KEYWORDS: DEFECT TYPE: STATUS: J3 consideration in progress 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 ---------------------------------------------------------------------- NUMBER: JP-24 TITLE: The bnf term shared-term-do-construct KEYWORDS: DEFECT TYPE: STATUS: J3 consideration in progress QUESTION: JP-24) In 8.1.4.2, second constraint below R833 states that: "The do-term-shared-stmt shall be identified with a label and all of the label-do-stmts of the shared-term-do-construct shall refer to the same label." This implies a label-do-stmts of the outer-most outer-shared- do-construct will permit not to refer to the same label, because shared-term-do-construct does not include outer-most outer- shared-do-construct. So the term "shared-term-do-construct" should be changed to "inner-share-do-construct and outer-shared-do-construct." DISCUSSION: There is a typographical error in the question - "8.1.4.2" should read "8.1.4.1.2". The following amplification of the question was provided at the August 2000 WG5 meeting: The present BNF does not preclude the following as a single construct: do 10 i=1,5 ! outer do 20 j=1,5 ! outer do 20 k=1,5 ! outer do 20 l=1,5 ! inner ... 20 continue ! shared ANSWER: Agreed. There is a minor typo in the suggested replacement text. EDIT: [127:29.5] Replace "shared-term-do-construct" by "inner-shared-do-construct and outer-shared-do-construct". {The intention is to alter the second line of the second constraint following R833. The line numbering is awry in the F95 copy being used.} SUBMITTED BY: Japan HISTORY: 99-208 Submitted 99-221 Classed as Fortran 95 Interpretation. WG5-N1411 draft answer ---------------------------------------------------------------------- NUMBER: JP-31 TITLE: Signs of literal constants KEYWORDS: DEFECT TYPE: STATUS: J3 consideration in progress 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" SUBMITTED BY: Japan HISTORY: 99-208 Submitted 99-221 Classed as Fortran 95 Interpretation. WG5-N1411 draft answer ---------------------------------------------------------------------- NUMBER: JP-39 TITLE: Note 12.20 KEYWORDS: DEFECT TYPE: STATUS: J3 consideration in progress QUESTION: JP-39) Page 204/ line 17 (NOTE 12.20): In 6.3.3.2, "If a pointer is currently associated with an allocatable array, the pointer shall not be deallocated". So "DEALLOCATE (B)" would NOT be permitted. DISCUSSION: This question was written on the mistaken reading that A was an allocatable array. The Japanese member body wishes to withdraw the interpretation request (WG5 meeting, August 2000). ANSWER: EDIT: SUBMITTED BY: Japan HISTORY: 99-208 Submitted 99-221 Classed as Fortran 95 Interpretation. WG5-N1411 Interpretation withdrawn