PC File: 95-006a4.180 Archive: 95-006r4.A180 -------------------------------------------------------------------------------- NUMBER: 000180 TITLE: Unambiguous generic references KEYWORDS: host association, generic name DEFECT TYPE: Erratum STATUS: X3J3 consideration in progress QUESTION: Consider the following example: SUBROUTINE S() INTERFACE GEN1 FUNCTION F1(I) END FUNCTION FUNCTION F2(I,J) END FUNCTION END INTERFACE INTERFACE GEN2 FUNCTION G1() END FUNCTION FUNCTION G2(I) END FUNCTION END INTERFACE CALL SS() CONTAINS SUBROUTINE SS() INTERFACE GEN1 FUNCTION F3(I,J,K) END FUNCTION FUNCTION F4(II) END FUNCTION END INTERFACE INTERFACE GEN2 SUBROUTINE G3() END SUBROUTINE END INTERFACE A = GEN1(1,2,3) ! CALL TO F3 A = GEN1(1,2) ! CALL TO F2 A = GEN1(1) ! CALL TO F4 CALL GEN2() ! CALL TO G3 END SUBROUTINE END There are rules in section 14.1.2.3 that determine within a scoping unit what procedures can have the same generic specification. These rules directly mention access of a generic procedure via use association, but they make no mention of generic names accessed via host association. There is evidence that the rules in section 14.1.2.3 were not intended to apply to generic interfaces accessed by host association. Section 14.1.2.4.1 indicates that a call to a generic name can be resolved to a generic name in the host if the scoping unit and the host scoping unit both agree that the generic name is the name of a function or a subroutine. This indicates that in the example above, the definition of 'GEN2' is valid, even though 'G1' and 'G2' are functions while 'G3' is a subroutine. If the rules set out in 14.1.2.3 were to apply then the definition of 'GEN2' would be invalid. Do the rules in 14.1.2.3 apply to generic procedures accessed via host association? ANSWER: No. The rules in 14.1.2.3 were intended to apply to only those specific procedures declared to be generic in a scoping unit and those accessed via use association. Edits are included to clarify this. EDITS: 1. Add to the end of the first sentence of section 14.1.2.3 [242:27] "when the generic interfaces for each of the specific procedures are declared in the same scoping unit or accessed via use association." 2. Add to the end of the first paragraph of section 14.1.2.3 [242:32] "When a generic procedure is accessed from a host scoping unit, the steps for resolving a procedure reference as described in 14.1.2.4.1 have the same effect as if the rules restricted which specific versions from the host scoping unit can be accessed via the generic reference." SUBMITTED BY: Janice C. Shepherd HISTORY: 94-239r3 m130 submitted with suggested answer, approved u.c. 94-306 m131 X3J3 ballot, failed 15-4 -------------------------------------------------------------------------------- NUMBER: 000183 TITLE: Unambiguous procedure overloading KEYWORDS: generic interface, interface - generic, argument - dummy DEFECT TYPE: Erratum STATUS: X3J3 approved; ready for WG5 QUESTION: The standard considers (14.1.2.3) the following example to be ambiguous: INTERFACE BAD SUBROUTINE S1(A) END SUBROUTINE SUBROUTINE S2(B,A) END SUBROUTINE END INTERFACE ! BAD because it requires a single argument which disambiguates both by position and by keyword (A of S2 disambiguates by position but not by keyword; B of S2 disambiguates by keyword but not by position). Note that the above is the simplest example of unambiguous overloading which the standard disallows; other cases exist where the number of nonoptional arguments is the same, e.g. INTERFACE DOUBLE_PLUS_UNGOOD SUBROUTINE S1(I,P,A) END SUBROUTINE SUBROUTINE S2(J,A,I) END SUBROUTINE END INTERFACE where S2 takes two nonoptional integer arguments and S1 takes one nonoptional integer argument, but there is still no single argument which disambiguates between them. A third example shows an (apparently forbidden) unambiguous overloading where the number of arguments of each data type are the same: INTERFACE BAD3 SUBROUTINE S1(I,J,A,B) END SUBROUTINE SUBROUTINE S2(J,I,B,A) REAL I INTEGER A END SUBROUTINE END INTERFACE Was the overly strict nature of the disambiguation rules an unintentional oversight? ANSWER: Yes. A change is needed to the rules in 14.1.2.3 to avoid rejecting examples such as the first example shown. While the first example can be considered to have been incorrectly rejected by the text in the standard, the text necessary to avoid rejecting the other two examples is sufficiently complicated to indicate that it was specifically not included in the standard. Future versions of the standard may consider extending the language to include the second and third examples as standard conforming. The change is to allow a difference in the number of arguments of each data type to disambiguate overloads. Discussion: To allow the second and third examples it would be necessary to have text that would place an ordering relationship between the positional disambiguators and keyword disambiguators. Consider the following code fragment, which includes an ambiguous call. This code fragment must be nonstandard conforming. INTERFACE AMBIGUOUS SUBROUTINE S1(I,B,J,A) END SUBROUTINE SUBROUTINE S2(K,I,A,J) REAL:: I END SUBROUTINE END INTERFACE CALL AMBIGUOUS(3, 0.5, A=0.5, J=0) ! Cannot tell which of S1 or S2 to ! call EDITS: 1. In section 14.1.2.3, in the third paragraph [242:38] change "and at least one of them must have a nonoptional dummy argument that" to "and (1) one of them has more nonoptional dummy arguments of a particular data type, kind type parameter, and rank than the other has dummy arguments (including optional dummy arguments) of that data type, kind type parameter, and rank; or (2) at least one of them must have a nonoptional dummy argument that" and indent numbers (1) and (2) to be a sublist of list item (2); changing them to be (a) and (b) respectively. 2. In section 14.1.2.3, in the text after the example [243:10-11] change "(1)" to "(2)(a)" twice change "(2)" to "(2)(b)" twice SUBMITTED BY: Malcolm J. Cohen HISTORY: 94-281r1 m130 submitted with proposed response, approved u.c. 94-306 m131 X3J3 ballot failed 17-2 94-359r1 m131 revised answer to only change conformance of first example; approved u.c. 95-034r1 m132 X3J3 ballot approved 19-1, with edit -------------------------------------------------------------------------------- NUMBER: 000184 TITLE: Intent of intrinsic dummy arguments KEYWORDS: INTENT, intrinsic, argument - dummy, INTENT(IN) DEFECT TYPE: Erratum STATUS: X3J3 approved; ready for WG5 QUESTION: If a specific intrinsic procedure is passed as an actual argument and an interface block is specified for the dummy procedure what should be specified for the intent(s) of the dummy argument(s) of the dummy procedure? In particular it seems that the following program: INTERFACE SUBROUTINE S(P) INTERFACE REAL FUNCTION P(R) REAL R ! S1 REAL,INTENT(IN) :: R ! S2 REAL,INTENT(INOUT) :: R ! S3 REAL,INTENT(OUT) :: R ! S4 END FUNCTION END INTERFACE END SUBROUTINE END INTERFACE INTRINSIC SIN CALL S(SIN) END is standard conforming if any one of the statements S1 through S4 appears for dummy argument R. Was this intended? This seems an oversight that should be corrected by an edit to 12.4.1.2 and chapter 13. ANSWER: No. Only the version of the program in which statement S2 appears is standard conforming. Discussion: Section 12.4.1.2 states that if the interface of the dummy procedure is explicit, the characteristics of the associated actual procedure must be the same as the characteristics of the dummy procedure. Such characteristics (12.2) include the characteristics of the dummy arguments of which one is the argument intent. Unfortunately in chapter 13, the intents of most intrinsic procedure dummy arguments, including those of specific intrinsic functions such as SIN that may be passed as actual arguments are unspecified. The supplied edit corrects this deficiency by giving all such nonpointer dummy arguments INTENT(IN). EDITS: 1. Change the title of section 13.3 to be [183:36] "Arguments to intrinsic procedures" 2. add the following as a new paragraph at the end of section 13.3 [183:39+] "The dummy arguments of the specific intrinsic procedures in 13.12 have INTENT(IN). The nonpointer dummy arguments of the generic intrinsic procedures in 13.13 have INTENT(IN) if the intent is not stated explicitly." SUBMITTED BY: Graham Barber HISTORY: 94-275 m130 submitted 94-334r1 m131 proposed response, approved u.c 95-034r1 m132 X3J3 ballot, approved 17-3; returned to subgroup for determination of edit location description 95-085 m132 Changed placement of edit so that new section was not created. -------------------------------------------------------------------------------- NUMBER: 000185 TITLE: What is the allocation status of an array after an allocation failure? KEYWORDS: ALLOCATE, POINTER, DEALLOCATE, status DEFECT TYPE: Interpretation STATUS: X3J3 approved; ready for WG5 QUESTION: It does not appear that the standard defines the allocation status of an array if an ALLOCATE statement fails and returns a nonzero STAT= value? Given a program segment like: REAL, ALLOCATABLE, DIMENSION(:) :: A,B,C ALLOCATE(A(10), B(10), C(10), STAT = ISTAT) Question 1: If "ISTAT" comes back non-zero, is it legal to deallocate the arrays and try to reallocate them with smaller sizes? Question 2: If instead of allocatable arrays, the variables had been pointers, is it legal to NULLIFY them? Question 3: Are the answers to questions 1 and 2 different if a single array is allocated rather than a list? Question 4: If a DEALLOCATE fails for a list, what is the allocation status of the arrays? Question 5: Is it acceptable to use the ALLOCATED and/or ASSOCIATED functions to attempt to recover from a failure? Question 6: 6.3.1.1 might be read to mean that successful allocation makes the arrays "currently allocated" and otherwise leaves them "not currently allocated". But that's not an obvious reading of the text. In some ways I/O is similar to allocate (they both process a list of things and have a STAT= clause). If an input statement fails then everything in the list becomes undefined. Does that apply by analogy to ALLOCATE? ANSWER 1: Yes. Note that one or more of the arrays is expected to have an allocation status of "currently not allocated", due to the error which occurred. See the Discussion below. Note that this example only used allocatable arrays. If a pointer appears in a DEALLOCATE statement, its pointer association status must be defined (section 6.3.3.2). See the Discussion below. ANSWER 2: Yes. See section 14.6.2.3. ANSWER 3: No, the answers are the same. See Answer 6 below. ANSWER 4: Whether the allocation status of the array is currently allocated or not currently allocated is processor dependent. The standard does not specify what the allocation status (or pointer association status) of arrays (or pointers) specified in a DEALLOCATE statement will be when an error condition occurs during execution of a DEALLOCATE statement. ANSWER 5: For ALLOCATED, yes. For ASSOCIATED, it depends on the pointer association status of the pointer at the time the ASSOCIATED intrinsic is called. The ALLOCATED intrinsic may be called with any allocatable array whose allocation status is either currently allocated or currently not allocated. The ASSOCIATED intrinsic must not be called with a pointer whose pointer association status is undefined (section 6.3.3.2). See the Discussion below. ANSWER 6: No. The standard does not require a processor to allocate the variables specified in an ALLOCATE statement as a group; therefore, a processor may successfully allocate some of the arrays specified in an ALLOCATE statement even when that ALLOCATE statement assigned a positive value to the variable specified in the STAT= specifier. Discussion: Only when the allocation status of an array is undefined is it illegal to specify the array in an DEALLOCATE statement. The only way for an allocatable array to have a status of undefined is described in section 14.8, item (3). If an array specified in a DEALLOCATE statement has an allocation status of not currently allocated when the DEALLOCATE statement is executed, an error condition occurs as described in section 6.3.3.1. The behavior of the DEALLOCATE statement in the presence of an error condition is described in section 6.3.3. Immediately after the execution of an ALLOCATE statement, all allocatable arrays specified in that ALLOCATE statement will have a defined allocation status (either currently allocated or currently not allocated). When a pointer is specified in an ALLOCATE statement which fails (assigns a positive value to ISTAT in this example), then the pointer association status of that pointer will not be changed if the allocation failed for that particular pointer. If that pointer previously had a pointer association status of undefined, it will still have a pointer association status of undefined immediately after the ALLOCATE statement is executed; therefore, it would be illegal to specify that pointer in a DEALLOCATE statement (section 6.3.3.2) or in a call to the ASSOCIATED intrinsic (section 13.13.13), unless the allocation status of the pointer was first changed to be defined (either associated or disassociated). EDITS: None. SUBMITTED BY: Dick Hendrickson HISTORY: 94-296 m131 submitted 95-039 m132 draft response, approved u.c. 95-101 m133 X3J3 ballot approved, 12-6 -------------------------------------------------------------------------------- NUMBER: 000186 TITLE: Allowed values of POSITION= and STATUS= specifiers when changing BLANK= KEYWORDS: OPEN statement, POSITION= specifier, STATUS= specifier DEFECT TYPE: Erratum STATUS: X3J3 approved; ready for WG5 QUESTION 1:What values are allowed for the POSITION= specifier when an OPEN is used to "reopen" a file and change the BLANK= etc, specifiers? Section 9.3.4, page 115, lines 20+ states: "If the file to be connected to the unit is the same as the file to which the unit is connected, only the BLANK=, DELIM=, PAD=, ERR=, and IOSTAT= specifiers may have values different from those currently in effect..." QUESTION 2:What is the current value of the POSITION= specifier? QUESTION 3:Given a sequence like: OPEN( UNIT = 10, FILE = "TAPE10", BLANK = "ZERO", POSITION="REWIND") WRITE(10 .......... are the following OPEN statements standard conforming? (Note that POSITION="ASIS" is the default for the OPEN) 1 OPEN( UNIT = 10, FILE = "TAPE10", BLANK = "NULL", POSITION="REWIND") 2 OPEN( UNIT = 10, FILE = "TAPE10", BLANK = "NULL" ) 3 OPEN( UNIT = 10, FILE = "TAPE10", BLANK = "NULL", POSITION="ASIS") A simple reading of the sentence is that 1 and 2 are standard conforming and have the same effect, but that 3 is not. The surprising feature is that execution of 1 does NOT rewind the file and that attempting to explicitly leave the file ASIS via 3 is nonstandard. It's not completely obvious that 2 is standard conforming. Section 9.3.4, page 115, line 23 states the OPEN "...does not cause any change in any of the unspecified specifiers..." so this apparently means that the POSITION= specifier is still "REWIND". However, section 9.3.4.7, page 117, line 25 states that the default value for the position specifier is "ASIS". QUESTION 4:Does the OPEN "not cause any change" from the initial specification of an unspecified specifier or does it use the default for an unspecified specifier? QUESTION 5:There is a set of similar questions for STATUS. If the STATUS= is omitted on the reopen, it defaults to "UNKNOWN". Section 9.3.4.2, page 116, lines 22+ appears to allow, for example, STATUS="NEW" on the initial OPEN but then requires either STATUS="OLD" or no STATUS= on subsequent reopens. Is this correct? ANSWER:In the following answers and discussion, the following terms are used: reOPEN (reOPEN-ing, reOPEN-ed): This is used to describe an OPEN statement for a unit which is already connected to the same file. This also applies to an OPEN statement for an external unit when the FILE= specifier is absent and the unit is already connected. properties of a connection: This is used to describe properties of a connection to an external unit that may be specified in an OPEN statement, including STATUS= and POSITION=. Note that the standard defines what the POSITION property is, but not what the STATUS property is. However, the standard does describe how the status changes during the process of an open, i.e. when STATUS="NEW" is specified, the file is created and the status changes to "OLD". Both POSITION and STATUS have a "current value", that is not necessarily the "value" specified in the OPEN statement. ANSWER 1:The standard is not clear about what values are legal for the POSITION= specifier when a file is "reOPEN-ed". The intent was to always permit a POSITION= specifier with a value of "ASIS", and to permit a value of "REWIND" only if the file was currently positioned at its initial point, and a value of "APPEND" only if the file was currently positioned at its terminal point. The edits below clarify what is allowed. ANSWER 2:The phrasing of the indicated paragraph is misleading. What the committee intended was that, except for the specifiers specifically listed, a specifier may not have a value different from those currently in effect, or in the case of the POSITION= specifier, the value must not specify a different position than the current position of the file. ANSWER 3:With the edits to the standard below, the OPEN statements labeled "2" and "3" are standard conforming for the indicated example (an OPEN followed by a WRITE followed by another OPEN, all for the same unit). The OPEN statement labeled "1" is not standard conforming in this example. ANSWER 4: The OPEN specifiers which are not specified when a file is reOPENed do not act as if the "default" value was specified for those specifiers. Instead, the property of the connection associated with that specifier is not changed by the reOPEN statement. This is described in the 6th paragraph of section 9.3.4, and this overrides the more general discussion of specifiers and their default values later in this chapter. ANSWER 5: Yes. Edits are provided to clarify what values are acceptable for the STATUS= specifier when reopening a file. Discussion: It is not absolutely clear in the Fortran 90 standard exactly what values are allowed for the POSITION= and STATUS= specifiers when a file is reOPENed. The standard is not clear what the phrase "currently in effect" in the sixth paragraph of section 9.3.4 means for the POSITION= and STATUS= specifiers. The committee intended that the phrase "currently in effect" mean the property of the connection at the time of the reOPEN, not the value of the specifier in the original OPEN statement. The language used in the standard in this area was adapted from the FORTRAN 77 standard, but some additional complications introduced by some new OPEN specifiers were not adequately addressed. When an OPEN statement is reOPENing a file, the POSITION= specifier with a value of "ASIS" is always allowed. When the file is positioned at its initial point, a reOPEN statement may have a POSITION= specifier with a value of "REWIND", and if the file is positioned at its terminal point a POSITION= specifier may have a value of "APPEND". The committee believes the standard already states this, using the intended interpretation of the phrase "currently in effect" in the 6th paragraph of section 9.3.4. An edit is included below to clarify this intent. The committee originally intended that if a STATUS= specifier was present when a unit was reOPENed, the value for the STATUS= specifier should not conflict with the "current" value in effect; however, it is very difficult to discern from the text currently in the standard what is allowed and what is prohibited. Edits are provided to clarify what values may be specified for STATUS= when reopening a file. The edits below clarify what may be specified for the POSITION= and STATUS= specifiers when reOPENing a file. EDITS: 1.In section 9.3.4, sixth paragraph [115:22], change "currently in effect." to the following: 'currently in effect. If the POSITION= specifier is present in such an OPEN statement, the value specified must not disagree with the current position of the file. If the STATUS= specifier is included in such an OPEN statement, it must be specified with a value of OLD.' 2.In section 9.3.4, add the following paragraph (note) after the 6th paragraph: [115:25+] 'Note that a STATUS= specifier with a value of OLD is always allowed when the file to be connected to the unit is the same as the file to which the unit is connected. In this case, if the status of the file was SCRATCH before execution of the OPEN statement, the file will still be deleted when the unit is closed, and the file is still considered to have the status SCRATCH.' 3.In section 9.3.4 [116:3], delete "OLD" and add the following sentence [116:3+]: 'If the STATUS= specifier has the value OLD, the FILE= specifier must be present unless the unit is currently connected and the file connected to the unit exists.' SUBMITTED BY: Dick Hendrickson for meeting 131 HISTORY: 94-297r1 m131 submitted 95-016 m132 draft response, 95-017r1 m132 draft response, approved u.c. 95-101 m133 X3J3 letter ballot, failed 17-1 95-160 m133 revised response, approved u.c. 95-183 m134 X3J3 ballot, passed 17-0 -------------------------------------------------------------------------------- NUMBER: 000187 TITLE: TARGET attribute, storage association, and pointer association KEYWORDS: TARGET attribute, association - storage, COMMON block, association - pointer DEFECT TYPE: Erratum STATUS: X3J3 consideration in progress QUESTION: Defect item 92, the response to which has been approved by WG5 and is now in the "B" section of interpretation requests, contains an answer that is desirable but there is no text in the standard that supports the response. X3J3 was no doubt considering the following text from section C.5.3 as the base text for the response but (1) this text is in an appendix, not in the body of the standard, and (2) the text is flawed: The TARGET attribute ... is defined solely for optimization purposes. It allows the processor to assume that any nonpointer object not explicitly declared as a target may be referred to only by way of its original declared name. The rule in 5.1.2.8 ensures that this is true even if the object is in a common block and the corresponding object in the same common block in another program unit has the TARGET attribute. The only part of 5.1.2.8 that could reasonably be considered the "rule" to which C.5.3 refers is: An object without the TARGET or POINTER attribute must not have an accessible pointer associated with it. This "rule" does not seem to provide the insurance mentioned in C.5.3. Rather, it seems that this sentence exists to clarify the "may" in the first sentence of 5.1.2.8. That is, it seem to be just reiterating that the following is not standard conforming: INTEGER I INTEGER, POINTER :: P P => I In actuality, there is no way that a pointer can become *pointer associated* with an object that does *not* have the TARGET (or POINTER) attribute. The confusion seems to arise when an object with the TARGET attribute is storage associated with an object that does not have the TARGET attribute. There is pointer association and there is storage association but pointer association does not "transmit" through storage association. What, then, is the meaning of the sentence in 5.1.2.8 cited above? ANSWER: The sentence from 5.1.2.8 was intended to prohibit a nontarget object from being referenced both via a pointer and via the object's name within a single scoping unit but, as you point out, it fails to do so. Edits are provided to add text to provide the prohibition alluded to in C.5.3. Discussion: The following example is provided to illustrate the problem and clarify the edits: PROGRAM MAIN_PROG ! Variable M (a member of blank common) does not have the TARGET ! attribute. INTEGER M COMMON M INTEGER, POINTER :: P INTERFACE SUBROUTINE SUB(P) INTEGER, POINTER :: P END SUBROUTINE END INTERFACE CALL SUB(P) M = -1 PRINT *, "M = ", M PRINT *, "P's target = ", P END SUBROUTINE SUB(P) INTEGER, POINTER :: P ! Variable M (a member of blank common) has the TARGET attribute. INTEGER, TARGET :: M COMMON M M = 100 P => M END In the main program, the storage unit represented by M and P is accessible by two different methods: the variable name M and the pointer P. The text in C.5.3 is intended to prevent this multiple accessibility but the sentence it is referencing in 5.1.2.8 is not relevant with respect to this example. Pointer P is not pointer associated with variable M in the main program. This could be demonstrated by adding the statement PRINT *, ASSOCIATED(P, M) to the main program but this statement would be invalid because M has neither the POINTER nor TARGET attribute in that scoping unit. Since there is no text in 5.5.2.3 that states that if an item in a common block has the TARGET attribute, it may correspond only with another item (in another declaration of the common block) that also has the TARGET attribute, the edits add this rule. Note that defect item 160 also quotes this same passage from C.5.3 in its question. That defect item resulted in the addition of a constraint that prohibits an object in an EQUIVALENCE list from having the TARGET attribute. Without this prohibition, there could again possibly be more than one avenue avenue of reference to a data object in a single scoping unit. In the common block case, however, it is desirable to allow variables with the TARGET attribute so the edit adds the rule stating if a variable in a common block has the TARGET attribute, any corresponding variable in another instance of the common block with the same name must also have the TARGET attribute. REFERENCES: ISO/IEC 1539:1991 5.5.1 (as modified by defect item 160) EDITS: 1. Delete the second sentence of 5.1.2.8 [48:16-17]. 2. Insert as the (new) last paragraph of 5.5.2.3 [59:42+]: "An object with the TARGET attribute must become storage associated only with another object that has the TARGET attribute." 3. Delete the fourth sentence of C.5.3 [269:23-25]. SUBMITTED BY: Larry Rolison HISTORY: 94-299r1 m131 submitted, with proposed response, passed 12-1 95-034r1 m132 X3J3 ballot, failed 14-6 -------------------------------------------------------------------------------- NUMBER: 000188 TITLE: Ambiguity in Namelist Input? KEYWORDS: i/o namelist, value separator, logical value DEFECT TYPE: Erratum STATUS: X3J3 approved; ready for WG5 QUESTION: Suppose a namelist input list contains a logical array, followed by a variable named F (or T). If there are not enough elements to satisfy the array, then the standard doesn't seem clear whether to interpret the F= as .FALSE., discarding the '=' as superfluous, or as a new namelist group object. e.g, this input file contains 3 forms of .FALSE. for a 4 item array. PROGRAM TEST IMPLICIT NONE INTEGER F(4) LOGICAL L(4) NAMELIST /TRACERS/ L, F READ (9, TRACERS) END --------------- input file ----------------- &TRACERS L=.FALSE.,.F.,F, F=0,1,2,3 / -------------------------------------------- 10.9.1.2, 3rd paragraph (page 152) states: "When the name in an input record represents an array variable ... The number of values following the equals must not exceed the number of list items in the expanded sequence, but may be less; in the latter case the effect ..." so a full list is not needed. 10.9.1.3 3rd paragraph (page 153) states: "When the next effective item is of type logical, the input form of the input value must not include slashes, blanks, or commas among the optional characters permitted for L editing (10.5.2) " and points to the description of the input field 10.5.2 2nd paragraph (page 143) states: "The input field consists of optional blanks, optionally followed by a decimal point, followed by a T for true or F for false. The T or F may be followed by additional characters in the field. Note that the logical constants .TRUE. and .FALSE. are acceptable input forms......" describes the forms allowed on input. The 'additional characters' is the sticky point. This leads to the questions: Question 1) In the example above, is the F=0 interpreted as a .FALSE. or a namelist group item? Question 2) Does the answer to (1) change if the equals sign is surrounded by blanks (value separators) e.g.: &TRACERS L=.FALSE.,.F.,F, F = 0,1,2,3 / Question 3) It appears the 3rd paragraph in 10.9.1.3 taken with 10.5.2 is intended to allow F in a list to be interpreted as .FALSE., (e.g.: F,) but it is difficult to construe the text this way. If the input file was &TRACERS L=.FALSE.,.F.,F/ F = 0,1,2,3 / would the slash terminate the namelist input or would 'F/' be an illegal logical field? Shouldn't the paragraph be rewritten to say blank, comma or slash in a logical field are interpreted as value separators? Note: the consequence to the implementation is lookahead at inconvenient moments. ANSWER 1: It is intended to be interpreted as the start of a new namelist name-value subsequence. The name before the "=" may be any name in the . Edits are supplied to resolve the ambiguity. ANSWER 2: No. The presence of optional blanks as described in section 10.9 does not affect the interpretation. ANSWER 3: The "/" terminates the namelist record. "/" is not permitted as one of the optional characters following the "T" or "F" in a logical constant (10.9.1.3, 3rd paragraph). Therefore, the "/" is a value separator (10.9, 10.8) and it causes termination of the namelist input statement as described in the 4th paragraph of section 10.9.1.2. Discussion: The committee intended that a name-value subsequence should always be identifiable by looking for an object name or subobject designator, followed by an equal sign, with optional blanks permitted before and after the equal sign. The committee attempted to eliminate all ambiguities between the start of a name-value subsequence and a value by limiting the forms of acceptable input values. The particular case mentioned in Question 1 was overlooked. The edit below fixes this ambiguity. EDIT: In section 10.9.1.3, 3rd paragraph [153:12], change "blanks," to "blanks, equals,". SUBMITTED BY: David Phillimore. HISTORY: 94-298 m131 submitted 94-345 m131 response, approved u.c 95-034r1 m132 X3J3 ballot approved 20-0, with edits -------------------------------------------------------------------------------- NUMBER: 000189 TITLE: Module name / local name conflict KEYWORDS: name - class, use association, global entity DEFECT TYPE: Interpretation STATUS: X3J3 approved; ready for WG5 QUESTION: The question in this defect item is a variation on defect item 127. Consider the following program: MODULE M1 INTEGER I END MODULE MODULE M2 USE M1 INTEGER J END MODULE MODULE M3 USE M2 INTEGER M1 END MODULE Is there a conflict between the global module name M1 (the first module) and the locally declared variable name M1 (in the last module)? ANSWER: No. Discussion: The declaration of the local variable M1 is not in conflict with module name M1 because module names are not use associated. From 11.3.2: The USE statement provides the means by which a scoping unit accesses named data objects, derived types, interface blocks, procedures, generic identifiers (12.3.2.1), and namelist groups. Note that a module is not a procedure. Naming a module in a scoping unit (on the USE statement) causes the module name to become known to that scoping unit (as opposed to the module name being accessed from the module) and thus conflicts with the module name are possible within the scoping unit that names the module on the USE statement. And this was the question addressed by Interpretation Request 127. However, since a module name is NOT accessed via a USE statement, module name M1 is not known to module M3 and therefore there is no conflict with the declaration of variable M1 in M3. EDITS: None SUBMITTED BY: Larry Rolison HISTORY: 94-301 m131 submitted with proposed response, approved u.c. 95-034r1 m132 X3J3 ballot, approved 20-0 -------------------------------------------------------------------------------- NUMBER: 000190 TITLE: Subobjects of constants in a DATA statement KEYWORDS: DATA stmt, constant DEFECT TYPE: Interpretation STATUS: X3J3 consideration in progress QUESTION: Consider the following syntax rules from Section 5.2.9: R532 is [*] R533 is ... R534 is and the following constraint Constraint: A of a must involve as primaries only constants or DO variables of the containing s, and each operation must be intrinsic. In all cases, the rules reduce to "constant". The definition of "constant" is provided by R305: R305 is or R307 is The above two rules seem to indicate that if an identifier appears where "constant" is allowed in the DATA statement rules cited above, the identifier must be a name; that is, it can not be the subobject of a named constant. Is this analysis correct? ANSWER: Yes, your analysis is correct. A , a , and a constant appearing in a of a DATA implied-DO can be a name (of a named constant) but not a subobject designator. Discussion: There is no intent in the standard to extend the above rules over what was provided in the FORTRAN 77 standard. So, for example, the following program fragment is not standard conforming: INTEGER, PARAMETER :: PARR(3) = (/ 1, 2, 3 /) INTEGER :: ARRAY(3) DATA (ARRAY(I), I = PARR(1), 3) / PARR(1), PARR(2)*PARR(3) / EDITS: None SUBMITTED BY: Larry Rolison HISTORY: 94-302 m131 submitted, with proposed response 94-360 m131 alternate answer proposed, failed 7-7 94-302 m131 original answer, approved 14-2 95-034 m132 X3J3 ballot failed 15-5 -------------------------------------------------------------------------------- NUMBER: 000191 TITLE: Interaction of SEQUENCE derived types and rename KEYWORDS: SEQUENCE, derived type, use association, derived type DEFECT TYPE: Erratum STATUS: X3J3 consideration in progress QUESTION: Consider the following: MODULE M TYPE T SEQUENCE TYPE (T), POINTER :: P END TYPE END MODULE USE M, T2=>T TYPE T SEQUENCE TYPE (T2), POINTER :: P END TYPE TYPE (T) X TYPE (T2) Y X = Y END Section 4.4.2, 'Determination of derived types', seems to indicate that types T and T2 in the main program refer to the same type. Note that both types have structure components that agree in order, name, and attributes. However, considering type T in the context of module M only, type T is a derived type that contains one component that is a pointer to itself. In the context of the main program, type T is a derived type that contains one component that is a pointer to a different derived type. Are types T and T2 considered to be the same type? ANSWER: Yes, T and T2 are the same type. An edit is provided to clarify this conclusion. Discussion: The first sentence in section 4.4.2 states, "a particular type name may be defined at once in a scoping unit." However, by the use of rename, it's possible for a scoping to have access to two separately defined derived types, that were originally defined the same name, by two different local names. For derived types made accessible by use association, the derived type name referred to in section 4.4.2 is in the corresponding . Edits are provided to clarify this. EDITS: 1. In section 4.4.2, add the following to the end of the first paragraph: [35:39] "In addition, two derived types accessible in the same scope might be the same if one or both are accessible by use association." 2. In section 4.4.2, after the second paragraph, add the following independent paragraph: [35:46] "Note that the criterion that the two types have the same name applies to the of the respective ." SUBMITTED BY: Janice C. Shepherd HISTORY: 94-273 m130 submitted 94-377 m131 Response submitted, approved u.c. 95-034r1 m132 X3J3 ballot failed 15-5 -------------------------------------------------------------------------------- NUMBER: 000192 TITLE: Ambiguity of dummy procedures in interface bodies KEYWORDS: dummy procedures, interface bodies DEFECT TYPE: Interpretation STATUS: X3J3 approved; ready for WG5 QUESTION: It appears that it may not be possible to identify from a procedure interface body which, if any, of its dummy arguments are dummy procedures. This arises from the fact that it is not necessary to give an explicit interface for dummy procedures, or even to specify the EXTERNAL attribute for them (the latter only being necessary for procedures that are used as actual arguments). Even if it were mandatory to (at least) specify EXTERNAL for dummy procedures, this would still not resolve them into subroutines and functions, given that typing may be implicit. For example, in: INTERFACE FUNCTION F (A,B,C) END FUNCTION F END INTERFACE each of the arguments could be a dummy scalar variable, a dummy function or a dummy subroutine. It appears that an explicit interface should identify dummy procedures and their nature (function or subroutine, and result type in the former case). Section 12.2 of the F90 standard ("Characteristics of Procedures") does not seem to give much guidance: section 12.2.1.2 states that a dummy procedure's characteristics only include its characteristics *as* a procedure if its interface is explicit, which is not very illuminating. Question 1: Should a procedure interface body unambiguously identify dummy procedures and their nature (i.e. function or subroutine)? Question 2: Is the EXTERNAL attribute mandatory for dummy procedures in an interface body, if they do not themselves have explicit interfaces? Question 3: If so, how are dummy functions and subroutines distinguished given that typing may be implicit? ANSWER: Answer 1: No. The interface body must identify each dummy argument that is a procedure by means of one of the following : -- an EXTERNAL statement for the argument -- a type declaration statement for the argument and the argument also has the EXTERNAL attribute -- an interface block for the argument. Where an interface block is present the interface body will allow the disambiguation of the dummy procedure as a subroutine or function. Where a type declaration statement is present the dummy procedure is identified as a function. Where only an EXTERNAL statement is present it is not possible to disambiguate the procedure as a subroutine or function. Answer 2: Yes. Answer 3: A dummy argument that is a procedure may be identified as a function by its appearance in a type declaration statement or in a function statement within an interface body for the argument. A dummy argument that is a procedure may be identified as a subroutine by its appearance in a subroutine statement within an interface body for the argument. Discussion: The necessity to disambiguate dummy arguments that are procedures from dummy arguments that are not procedures is described in the response to defect item 000063. Section 12.3.2.1 (page 168) states that an interface body specifies all of a procedure's characteristics. Section 12.2.1.2 indicates that the characteristics of a dummy procedure are the explicitness of its interface, its characteristics as a procedure if the interface is explicit and whether it is optional. So, if a procedure P has a dummy procedure with an implicit interface the characteristics of the dummy procedure do not include whether it is a function or subroutine. Therefore it is not necessary that an interface block for P disambiguate the dummy procedure as a function or subroutine. If by contrast the interface for the dummy procedure is explicit in the scope of P, any interface body for P must include a nested interface body for the dummy procedure. This is indicated in the standard from the text of sections 12.2, 12.2.1.2 and 12.3. Section 12.3 specifies that the characteristics of a procedure are fixed. Section 12.2 indicates that the characteristics of a procedure include the characteristics of its dummy arguments. Finally, section 12.2.1.2 states that the characteristics of a dummy procedure include the explicitness of its interface. So any interface block for P must incorporate a nested interface block for the dummy procedure that specifies all these characteristics. EDITS: None SUBMITTED BY: John Merlin HISTORY: 94-307 m131 submitted 95-054r1 m132 draft response, approved u.c. 95-101 m133 X3J3 ballot approved, 14-4, with edits applied -------------------------------------------------------------------------------- NUMBER: 000193 TITLE: Pointer actual arguments with the OPTIONAL attribute KEYWORDS: optional, POINTER attribute TYPE: Erratum STATUS: X3J3 approved; ready for WG5 QUESTION : Section 12.5.2.8 states the following about an optional dummy argument that is not present (as modified by Corrigendum 1): [179:39-40] "Except as noted in (5) above, it may be supplied as an actual argument corresponding to an optional dummy argument." Section 7.1.4.1 states (as modified by Corrigendum 2) : [76:20:22] "If the pointer is not associated with a target, it may appear as a primary only as an actual argument in a reference to a procedure whose corresponding dummy argument is declared to be a pointer, or as the target in a pointer assignment statement." Consider the following example : PROGRAM MAIN CALL INNER() CONTAINS SUBROUTINE INNER(PARG) OPTIONAL :: PARG POINTER :: PARG INTERFACE SUBROUTINE SUB(TARG) OPTIONAL :: TARG END SUBROUTINE END INTERFACE CALL SUB(PARG) END SUBROUTINE END PROGRAM In this example, PARG is an optional dummy argument that is not present and it is being supplied as an actual argument corresponding to an optional dummy argument. On the other hand, PARG is a pointer that is not associated with a target, therefore it should not be supplied as the actual argument corresponding to a dummy argument that is not a pointer. If a pointer dummy argument is not present, may it be specified as the actual argument corresponding to a dummy argument that is not a pointer? ANSWER : No. An optional dummy argument that is a pointer and is not present must not be supplied as an actual argument corresponding to a dummy argument that is not a pointer. This restriction should have been included in the list within section 12.5.2.8 Edits are supplied to correct this omission. EDITS: 1. In Section 12.5.2.8, add the following to the numbered list after the list item added by Corrigendum 1 [179:38+]: "(6) If it is a pointer, it must not be supplied as an actual argument corresponding to a nonpointer dummy argument other than as the argument of the PRESENT intrinsic function." 2. In Section 12.5.2.8, in the text added by Corrigendum 1 to the last sentence of the section [179:39]: change "in (5)" to "in the list" SUBMITTED BY: Janice C. Shepherd HISTORY: 95-097 m133 submitted, with proposed response, approved u.c. 95-183 m134 X3J3 ballot, passed 16-1 -------------------------------------------------------------------------------- NUMBER: 000194 TITLE: Statements between SELECT CASE and CASE KEYWORDS: FORMAT statement, DATA statement, SELECT CASE statement, CASE statement, INCLUDE line, statement order DEFECT TYPE: Erratum STATUS: X3J3 approved; ready for WG5 QUESTION: 1. Figure 2.1 (page 11) shows that FORMAT and DATA statements may be intermixed with executable constructs but it is not clear at what points within an executable construct these statements may appear. In particular, may FORMAT and DATA statements appear between the SELECT CASE statement and the first CASE statement of a CASE construct? 2. May an INCLUDE line appear between the SELECT CASE statement and the first CASE statement of a CASE construct? ANSWER: 1. No. In general, FORMAT and DATA statements may appear in the IF, CASE and DO executable constructs because these constructs contain blocks and a block is defined in section 8.1 (on page 95) to consist of s, which in turn are defined as being made up of FORMAT and DATA statements, among others. However, the syntax rules for the CASE construct do not provide for any blocks or any other statements to appear between the SELECT CASE statement and the first CASE statement of a CASE construct. The sentence in 8.1 [95:12] that defines a block in prose is imprecise and is clarified in an edit. 2. Yes. An INCLUDE line may appear between a SELECT CASE statement and the first CASE statement of a CASE construct because an INCLUDE line is a line, not a statement. The INCLUDE file must then contain only insignificant lines (comment and blank lines) or the first statement in the INCLUDE file must be a CASE statement or an END SELECT statement. EDIT: Page 95, the sentence before rule R801 [95:12] insert "and possibly FORMAT and DATA statements" between "constructs" and "that". SUBMITTED BY: Larry Rolison HISTORY: 94-383r1 m131 submitted with proposed response, approved 13-3 95-034r1 m132 X3J3 ballot approved 19-1, with edits 95-116 m133 (N1112) correct typo in answer 2. -------------------------------------------------------------------------------- NUMBER: 000195 TITLE: INQUIRE with preconnected files KEYWORDS: INQUIRE statement, preconnected file DEFECT TYPE: Interpretation STATUS: X3J3 approved; ready for WG5 QUESTION: If unit 3 is preconnected to file PDG, which does not exist, then consider the following Fortran 90 source: PROGRAM PETE CHARACTER*50 FM INQUIRE(UNIT=3, FORM=FM) END The notes (section C.9.4, page 278, lines 11-17) state that 'For a preconnected file that does not exist, a form may be established or the establishment of a form may be delayed until the file is created'. QUESTION 1: Where in the actual standard is there anything that substantiates the notes that the form may be established as a preconnection property or that it may be delayed? QUESTION 2: If a processor delays the establishment of a form until the file is created, then what is returned in variable FM in the program above? The standard does not seem to cover this case, all it covers is a) if the connection is for formatted b) if the connection is for unformatted c) if there is no connection There seem to be similar problems with INQUIRE with RECL, BLANK and DELIM specifiers on a similar file. ANSWER 1: The standard does not clearly state that the establishment of a form may be delayed. It is inferable from other text and the lack of an explicit prohibition. ANSWER 2: The standard does not specify what is returned in the variable FM in this case. Therefore, the processor is free to choose any value. Some of the other specifiers may also return processor dependent values for this example. Any property of the connection or file that depends on: 1) the "form" or "access" of the file connection, or 2) is only allowed for a file with a particular "form" or "access", may have a processor dependent value returned by the INQUIRE statement for that property, for this particular example. Discussion: In several places the standard refers to a form being in the allowed set of forms. A processor may allow (but is not required to allow) some files to be OPENed with either a FORM value of FORMATTED or UNFORMATTED. In section 9.3.4.4 (OPEN statement, FORM= specifier), the standard states: "For a new file, the processor creates the file with a set of allowed forms that includes the specified form". This implies that a processor may delay establishing a form for a file until the file is created. And in section 9.3.2, 3rd paragraph, the standard states: "A file may be connected and not exist. An example is a preconnected external file that has not yet been written (9.2.1.1)." So, a preconnected file need not exist until the file is referenced in a data transfer statement, and the establishment of the form may be delayed until the the file is created. If the processor delays establishing a form until the file is created, the first data transfer statement to reference a non-existent preconnected file will establish the form, and it is incumbent upon the user to only use that form. EDITS: None. SUBMITTED BY: Peter Griffiths HISTORY: 95-014 m132 submitted 95-018 m132 draft response, approved u.c. 95-101 m133 X3J3 ballot approved, 16-2, with edits applied -------------------------------------------------------------------------------- NUMBER: 000196 TITLE: Inaccessibility of intrinsic procedures KEYWORDS: intrinsic procedure, INTRINSIC attribute, generic identifier, names class DEFECT TYPE: STATUS: X3J3 consideration in progress QUESTION: Section 14.1.2 states: "Note that an intrinsic procedure is inaccessible in a scoping unit containing another local entity of the same class and having the same name. For example, in the program fragment SUBROUTINE SUB ... A = SIN (K) ... CONTAINS FUNCTION SIN(X) ... END FUNCTION SIN END SUBROUTINE SUB " Are the following two comments about this text correct? (1) The example is not strictly correct because the resolution of the procedure reference "SIN" depends on the contents of the first "...": * If "..." does not contain an "INTRINSIC SIN" statement, the behavior is as specified: In SUB, the name SIN is established specific due to condition 14.1.2.4 part (2b), it is not established generic, and the internal function SIN is referenced due to 14.1.2.4.2 part (3). * If "..." does contain an "INTRINSIC SIN" statement, SIN is established specific as above, but also established generic due to condition 14.1.2.4 (1b). So the reference is resolved according to 14.1.2.4.1 part (2): the intrinsic function SIN is called. ( At least if there is a suitable specific function for data ) ( object K. If not, the reference is resolved according to ) ( 14.1.2.4.1 (4) which also requires a consistent reference. ) (2) The first sentence of the cited text is wrong (incomplete), because it does not consider the case of generic identifiers: * Intrinsic procedures are local entities of class (1). * Generic identifiers are local entities of class (1). * Various instances in the standard indicate that it is possible to extend the generic interface of intrinsic procedures. Consequently, in the example MODULE my_sin CONTAINS LOGICAL FUNCTION lsin (x) LOGICAL, INTENT(IN) :: x ... END FUNCTION lsin END MODULE my_sin SUBROUTINE sub USE my_sin INTERFACE SIN MODULE PROCEDURE lsin END INTERFACE SIN ... END SUBROUTINE sub the intrinsic procedure SIN remains accessible in SUB although that scoping unit contains another local entity of class (1) named SIN. ANSWER: EDIT: SUBMITTED BY: Michael Hennecke (hennecke@rz.uni-karlsruhe.de) HISTORY: 95-252 m135 submitted -------------------------------------------------------------------------------- NUMBER: 000197 TITLE: Relationship of NEAREST and SPACING KEYWORDS: NEAREST, SPACING, "machine representable" DEFECT TYPE: STATUS: X3J3 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: Discussion: EDIT(S): SUBMITTED BY: Larry Rolison HISTORY: 95-030 m132 submitted -------------------------------------------------------------------------------- NUMBER: 000198 TITLE: Characteristics of dummy procedures KEYWORDS: argument - optional, characteristics, dummy procedures, interface - explicit DEFECT TYPE: Erratum STATUS: X3J3 approved; ready for WG5 QUESTION: Section 12.4.1.2 "Argument associated with dummy procedures" states: "If the interface of the dummy procedure is explicit, the characteristics of the associated actual procedure must be the same as the characteristics of the dummy procedure (12.2)." Section 12.2.1.2 "Characteristics of dummy procedures" states: "The characteristics of a dummy procedure are the explicitness of its interface (12.3.1), its characteristics as a procedure if the interface is explicit, and whether it is optional (5.1.2.6, 5.2.2)." This would imply that the following two examples are not standard conforming, as the characteristics of ARG1 are not the same as the characteristics of ARG2, and ARG2 has an explicit interface. Example 1: SUBROUTINE S(ARG1) EXTERNAL ARG1 INTERFACE SUBROUTINE SS(ARG2) INTERFACE FUNCTION ARG2(I) END FUNCTION END INTERFACE END SUBROUTINE SS END INTERFACE CALL SS(ARG1) ! ARG2 has an explicit interface and that is ! one of its characteristics but ARG1 has an ! implicit interface as one of its characteristics END SUBROUTINE S Example 2: SUBROUTINE T(ARG1) OPTIONAL ARG1 INTERFACE FUNCTION ARG1(I) END FUNCTION END INTERFACE INTERFACE SUBROUTINE TT(ARG2) INTERFACE FUNCTION ARG2(I) END FUNCTION END INTERFACE END SUBROUTINE TT END INTERFACE IF (PRESENT(ARG1)) CALL TT(ARG1) ! ARG1 is optional and that ! is one of its characteristics. ARG2 is not ! optional and that is one of its characteristics. END SUBROUTINE T Are the code fragments standard conforming? ANSWER: Yes, both code fragments are standard conforming providing in the first code fragment that ARG1 is associated with a function whose arguments and function result are consistent with those of ARG2. Discussion: In the text cited from 12.4.1.2, the reference to 12.2 was there to indicate that the requirement is that the characteristics of the dummy procedure as a procedure match the characteristics of the actual procedure as a procedure. The other characteristics of a dummy procedure (the explicitness of its interface and whether it is optional) were not meant to be included in the reference. The characteristics of a procedure are: - the classification of the procedure as a function or subroutine - the characteristics of its arguments - the characteristics of its result value if it is a function In the second code fragment the interface for ARG1 shows that these three characteristics are the same for ARG1 and ARG2. In the first code fragment these three characteristics of ARG1 are not known. For this code fragment to be standard conforming these three characteristics of any procedure associated with ARG1 must be the same as those of ARG2. An edit is included to clarify the text in 12.4.1.2. EDIT: Section 12.4.1.2, replace the second paragraph with [173:35-36] "If the interface of the dummy procedure is explicit, the characteristics listed in 12.2 must be the same for the associated actual procedure as for the corresponding dummy procedure." SUBMITTED BY: Janice C. Shepherd HISTORY: 95-042 m132 submitted, with proposed response, approved 9-4, 95-067 m132 alternate edit proposed, approved u.c. 95-101 m133 X3J3 ballot, failed 13-5 95-187 m134 alternate response proposed, approved u.c. 95-256 m135 X3J3 ballot, approved 15-0 ------------------------------------------------------------------------------ NUMBER: 000199 TITLE: Kind Type Parameters and the DELIM= specifier KEYWORDS: kind type parameter, i/o list-directed, i/o namelist DEFECT TYPE: Erratum STATUS: X3J3 approved; ready for WG5 QUESTION: Should defect item 131, which clarified that kind parameters should not appear in formatted input and output records, have deleted the text about in section 9.3.4.9 also? ANSWER: Yes. This is corrected by the edit below. Discussion: Defect item 131 revised numerous sections in chapter 10, where the form of values in formatted records was described, but similar text in chapter 9 was missed. The intent of defect item 131 was to prohibit a from appearing as part of a nondefault character constant in formatted records. Defect item 131 should have deleted the text in chapter 9, section 9.3.4.9, in the discussion of the DELIM= specifier, where the standard states that a nondefault character constant written to a list directed or namelist output record will be preceded with a and an underscore, whenever the file was opened with certain values for the DELIM= specifier. EDITS: In section 9.3.4.9, first paragraph, delete the 4th sentence [117:40-41]: "If APOSTROPHE or QUOTE is specified, a and underscore will be used to precede the leading delimiter of a nondefault character constant." SUBMITTED BY: Rich Bleikamp HISTORY: 95-181 m134 submitted with proposed response, approved u.c. 95-256 m135 X3J3 ballot, approved 16-0 -------------------------------------------------------------------------------- NUMBER: 000200 TITLE: subsumed by 000202: Evaluation of NINT and machine approximations KEYWORDS: DEFECT TYPE: STATUS: Subsumed QUESTION: Is the expression INT(A + 0.5) in the description of NINT meant to be evaluated exactly or as a machine approximation? This request for interpretation is the result of having discovered that a Fortran 90 compiler produces the value 16,000,002 for the expression NINT(16 000 001 . 0). At first glance, this appeared to be a bug; however, the algorithm used to implement NINT in this compiler is the algorithm from the Fortran 90 standard. That algorithm computes the NINT of a value A that is greater than zero as INT(A + 0.5). When A is 16,000,001.0, the value of A + 0.5 (in single=precision) is 16,000,002.0 on some machines. ANSWER: The expression result may be a processor approximation. Discussion: A numeric computation result is an approximation; the standard describes the desired results in "mathematical" terms (i.e., "+" means to add), but does not specify how precise the result must be. EDITS: None. SUBMITTED BY: Robert Corbett HISTORY: 95-182 m134 submitted 95-247r1 m134 approved as the response to NUMBER 000202 subsumed by 000202 -------------------------------------------------------------------------------- NUMBER: 000201 TITLE: SELECTED_REAL_KIND result KEYWORDS: SELECTED_REAL_KIND, intrinsic, result DEFECT TYPE: STATUS: X3J3 consideration in progress QUESTION: The Result Value portion of the description of SELECTED_REAL_KIND states in part: The result has a value equal to a value of the kind type parameter of a real data type with decimal precision, as returned by the function PRECISION, of at least P digits ..., or if no such kind type parameter is available on the processor, the result is -1 if the precision is not available... When SELECTED_REAL_KIND is invoked with a P value of -1, some vendors return a positive value as the result (almost certainly because they've focused on the phrase "of at least P digits" in the above quote from the standard) and some vendors return -1 (almost certainly because they've focused on the phrase "the result is -1 if the precision is not available" in the above quote from the standard). Is either one of these results "more correct" than the other or are they both acceptable? ANSWER: Discussion: REFERENCES: EDIT(S): SUBMITTED BY: Larry Rolison HISTORY: 95-175 m134 submitted -------------------------------------------------------------------------------- NUMBER: 000202 TITLE: Evaluation of intrinsic procedures KEYWORDS: algorithm, mathematical, computational DEFECT TYPE: Interpretation STATUS: X3J3 consideration in progress QUESTION: When the standard specifies an algorithm for computing a mathematical procedure, must a processor use that algorithm? For example, ANINT is defined as INT(A+0.5). On some processors ANINT(16 000 001.0) evaluates to 16 000 002.0 using this algorithm; but if it can be computed as the more expected 16 000 001.0, may a processor do so? See, also, item 000200 which this item subsumes. ANSWER: No, a processor is not bound to use the algorithm from the standard. Yes, a processor may return the mathematically equivalent result for ANINT. Discussion: The standard is intended to permit processors to use infinite accuracy if available. It is also intended to allow processors to use any mathematically equivalent algorithm the processor desires. EDITS: None SUBMITTED BY: Keith Bierman HISTORY: 95-247r1 m134 submitted with proposed response, approved 9-4 subsumes defect item 200 95-256 m135 X3J3 ballot failed 10-6 ------------------------------------------------------------------------------- NUMBER: 000203 TITLE: Scope of operator/assignment symbols KEYWORDS: intrinsic/defined operators/assignment, local/global entities DEFECT TYPE: Interpretation request STATUS: X3J3 consideration in progress QUESTION: Are the following interpretations correct? 1. Section 14.4 (Scope of operators) says that ``The intrinsic operators are global entities.'' and that ``A defined operator is a local entity.''. But a defined-operator (R311) may be an extended-intrinsic-operator (R312) which in turn is an intrinsic-operator (R310). This means that if intrinsic operators are global entities, so are at least some of the defined operators, so the second quotation given above cannot be true. PROPOSED EDIT: Add `` that is not an extended intrinsic operator'' after ``A defined operator'' in [F95,277:23]. 2. In Section 14.4, the scentence ``Within ...'' applies to the first scentence only. Defined-operators (other than extended-intrinsic-ops) have no intrinsic meaning and so "additional operations" makes no sense. PROPOSED EDIT: Move scentence 2 to the end of 14.4. 3. Section 14.5 (Scope of the assignment symbol) does not address the replacement of the intrinsic derived type assignment operation, as defined in 7.5.1.2 and 12.3.2.1.2. PROPOSED EDITS: Add ``, or replace the intrinsic derived type assignment operations'' after ``operations'' in [F95,277:27]. 4. The entities under consideration in 14.4 and 14.5 are the operator and assignment SYMBOLS. These are to be distinguished from the associated OPERATIONS in the same way that a generic name is to be distinguished from the specific names it comprises. PROPOSED EDITS: in [F95,277], replace: * line 22: "operators" => "operator symbols" * line 23: "operators" => "operator symbols" * line 23: "operator" => "operator symbol" * line 24: "operator" => "operator symbol" * After the ``Where ...'' scentences (lines 24,27), add ``The procedures corresponding to these operations are local entities.''. (The intrinsic operations have no "specific" entities associated with them and so need not be mentioned. If they had, these would be global entities.) ANSWER: EDIT: SUBMITTED BY: Michael Hennecke (hennecke@rz.uni-karlsruhe.de) HISTORY: 95-254 m135 submitted