ISO/IEC JTC1/SC22/WG5 N1404 Draft responses to interpretations Malcolm Cohen 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. ----------------------------------------------------------------------