From janshep@watson.ibm.com Tue Sep 5 17:30:47 1995 Received: from watson.ibm.com (watson.ibm.com [129.34.139.4]) by dkuug.dk (8.6.12/8.6.12) with SMTP id RAA03355 for ; Tue, 5 Sep 1995 17:30:07 +0200 Message-Id: <199509051530.RAA03355@dkuug.dk> Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 5521; Tue, 05 Sep 95 11:29:37 EDT Date: Tue, 5 Sep 95 11:29:36 EDT From: "Janice C. Shepherd ((914) 784-6313)" X-Addr: J1-K10, Hawthorne I tieline 863 To: sc22wg5@dkuug.dk Subject: 006 X3J3 letter ballot These 7 defect items were processed at meeting 134 of X3J3. These defects will be the subject of an X3J3 letter ballot (soon to be emailed out). Comments on these defect items are also welcomed from non-X3J3 members. Thanks. Janice C. Shepherd ------------------------------------------------------------------------------ NUMBER: 000081 TITLE: Pointer actual argument overlap KEYWORDS: pointer, target, argument - actual, argument - dummy, argument association DEFECT TYPE: Erratum STATUS: X3J3 draft response QUESTION: Section 12.5.2.9, Restrictions on entities associated with dummy arguments, clearly states that if there is partial or complete overlap between actual arguments associated with two different dummy arguments of the same procedure, the overlapping portions may not be defined, redefined, or undefined during the procedure execution. It continues: "This restriction applies equally to pointer targets. For example, in REAL, DIMENSION (10), TARGET :: A REAL, DIMENSION (:), POINTER :: B, C B => A (1:5) C => A (3:9) CALL SUB (B, C) B (3:5) cannot be defined because it is part of the actual argument associated with the second dummy argument. C (1:3) cannot be defined because it is part of the argument associated with the first dummy argument. A (1:2) [which is B (1:2)] remains definable through the first dummy argument and A (6:9) [which is C (4:7)] remains definable through the second dummy argument." Unfortunately, this example does not contain an explicit interface for the called subroutine, nor are there sufficient words to clearly state what is meant by the words and example provided. Question 1: Do the above restrictions hold when both dummy arguments are nonpointers? In this case the following interface describes SUB. INTERFACE SUBROUTINE SUB (X, Y) REAL, DIMENSION (:) :: X, Y END SUBROUTINE END INTERFACE Question 2: Same as question 1, only add the TARGET attribute to one or both of the dummy arguments. The following interfaces may describe SUB. INTERFACE SUBROUTINE SUB (X, Y) REAL, DIMENSION (:), TARGET :: X, Y END SUBROUTINE END INTERFACE or INTERFACE SUBROUTINE SUB (X, Y) REAL, DIMENSION (:) :: X, Y TARGET X END SUBROUTINE END INTERFACE Question 3: Do the above restrictions hold *upon entry* when both dummy arguments are pointers? That is, *upon entry* to SUB, is it safe to assume that pointer dummy arguments do not have overlapping elements which may get defined during execution of SUB? The following interface describes SUB. INTERFACE SUBROUTINE SUB (X, Y) REAL, DIMENSION (:), POINTER :: X, Y END SUBROUTINE END INTERFACE Question 4: Same as question 3, but one dummy argument is a pointer, one has the target attribute? *Upon entry* to SUB, is it safe to assume a pointer dummy argument does not point to any elements of a target dummy argument which may get defined during execution of SUB, but during the execution of SUB such an association may come to exist? The following interface describes SUB. INTERFACE SUBROUTINE SUB (X, Y) REAL, DIMENSION (:) :: X, Y POINTER X TARGET Y END SUBROUTINE END INTERFACE Question 5: Two derived type dummy arguments each have a subobject (or a subobject of a subobject etc.) which are pointers with the same type, kind type parameter, and rank. *Upon entry* to the subroutine, is it safe to assume such pointer subobjects do not have overlapping targets which may get defined? That is, in the following fragment, *upon entry* to SUB, is it safe to assume X%PTR_1 and Y%PTR_2 cannot have overlapping target elements which get defined during execution of SUB? SUBROUTINE SUB (X, Y) TYPE A SEQUENCE REAL, DIMENSION(:), POINTER :: PTR_1 END TYPE TYPE B SEQUENCE REAL, DIMENSION(:), POINTER :: PTR_2 END TYPE TYPE (A) :: X TYPE (B) :: Y ANSWER: There is a deficiency in the standard. The restrictions always apply to the allocation status or pointer association status of the entities, but do not apply to the values when: (1) the dummy argument or a subobject of the dummy argument has the POINTER attribute or (2) the dummy argument has the TARGET attribute, is a scalar or an assumed-shape array and does not have the INTENT(IN) attribute and the actual argument is a target other than an array section with a vector subscript. Edits are supplied to correct this. The answers to the specific questions are: Answer 1: Yes for the interface specified. Answer 2: Yes for the allocation status or pointer association status of the entities. Yes for the values except when (2) holds. Answer 3: Yes for the allocation status or pointer association status of the entities. No for the values. Overlapping elements of dummy arguments may be defined during execution of SUB. Answer 4 (first part): Yes for the allocation status or pointer association status of the entities. No for the value of the pointer argument. No for the value of the target argument when it is not of INTENT(IN), it is scalar or an assumed-shape array and the actual argument is a target other than an array section with a vector subscript. Yes for the value of the target argument in other cases. Answer 4 (second part): Upon entry to SUB, a pointer dummy argument may point to an element of a target assumed-shape dummy argument that is defined during execution of SUB. Answer 5: Yes for the allocation status or pointer association status of the entities. No for the values. Overlapping elements of pointer components of dummy arguments may be defined during execution of SUB. Discussion: The restrictions of Section 12.5.2.9 on entities associated with dummy arguments are intended to facilitate a variety of optimizations in the translation of the procedure, including implementations of argument association in which the value of an actual argument that is neither a pointer nor a target is maintained in a register or in local storage. The latter mechanism is usually known as "copy-in/copy-out". The text assumed that the rules applied to an actual argument with the TARGET attribute, too, but defect item 125 has made it clear that this is not the case for all actual arguments with the TARGET attribute and edits are needed in 12.5.2.9. The present text is correct with respect to the "availability" of an entity associated with a dummy argument. Neither pointer assignment nor any of the statements ALLOCATE, DEALLOCATE, NULLIFY may be applied other than through the dummy argument. For example, in the code INTEGER, POINTER :: IP CALL INNER(IP) CONTAINS SUBROUTINE INNER(IARGP) INTEGER, POINTER :: IARGP INTEGER, TARGET :: J IP => J ! Illegal the pointer assignment is not allowed because it is changing the pointer association of the actual argument. In the case of a dummy argument with the attribute POINTER or TARGET, the implementation can assume that its descriptor is distinct from any other entity accessible in the procedure. The present text is incorrect for the value of a pointer dummy argument. Here, the implementation must allow for the value to be altered through another pointer as in the example INTEGER, POINTER :: IP CALL INNER(IP) CONTAINS SUBROUTINE INNER(IARGP) INTEGER, POINTER :: IARGP INTEGER, TARGET :: J IP = 0 ! OK. This alters the value of IARGP, too. It is also incorrect where the dummy argument has the TARGET attribute, the dummy argument does not have INTENT(IN), the dummy argument is a scalar object or an assumed-shape array and the actual argument is a target other than an array section with a vector subscript. Here the implementation must allow for the value to be altered through a pointer as in the example INTEGER, POINTER :: IP CALL INNER(IP) CONTAINS SUBROUTINE INNER(IARGT) INTEGER, TARGET :: IARGT IP = 0 ! OK. This alters the value of IARGT, too. EDITS: 1. In section 12.5.2.9, [180:3-4] Replace the first two lines of item (1) by "Action that affects the pointer association status of the entity or any part of it (any pointer assignment, allocation, deallocation, or nullification) must be taken through the dummy argument. No action that affects the allocation status of the entity may be taken. Action that affects the value of the entity or any part of it must be taken through the dummy argument unless (a) the dummy argument has the POINTER attribute, (b) the part is all or part of a pointer subobject, or (c) the dummy argument has the TARGET attribute, the dummy argument does not have INTENT(IN), the dummy argument is a scalar object or an assumed-shape array and the actual argument is a target other than an array section with a vector subscript. For example, in" 2. In section 12.5.2.9, [180:32] in the line following the line "DEALLOCATE (A)" change 'availability' to 'pointer association status'. 3. In section 12.5.2.9, [180:37] in the second to last paragraph on page 180, after "the same procedure" add "and the dummy arguments have neither the POINTER nor the TARGET attribute". 4. In section 12.5.2.9, [181:8] in line 8 of page 181, after "CALL SUB(B,C)" add "! The dummy arguments of SUB are neither pointers nor targets". 5. In section 12.5.2.9, [181:17-19] Replace the first three lines of item (2) by "If the pointer association status of any part of the entity is affected through the dummy argument, then at any time during the execution of the procedure, either before or after the definition, it may be referenced only through that dummy argument. If the value of any part of the entity is affected through the dummy argument, then at any time during the execution of the procedure, either before or after the definition, it may be referenced only through that dummy argument unless (a) the dummy argument has the POINTER attribute, (b) the part is all or part of a pointer subobject, or (c) the dummy argument has the TARGET attribute, the dummy argument does not have INTENT(IN), the dummy argument is a scalar object or an assumed-shape array and the actual argument is a target other than an array section with a vector subscript. For example, in" 6. In section C.12.7, [291:40-42] Replace lines 3 to 5 by "The restrictions on entities associated with dummy arguments are intended to facilitate a variety of optimizations in the translation of the procedure, including implementations of argument association in which the value of an actual argument that is neither a pointer nor a target is maintained in a register or in local storage." ' SUBMITTED BY: Jon Steidel HISTORY: 92-208 m123 Submitted 93-85 m124 Proposed response, withdrawn 93-174 m125 Revised response, withdrawn 93-213 m126 Revised response, adopted by unanimous consent 93-255r1 m127 ballot failed 19-5 94-248 m130 Revised response and edits. 94-282r1 m130 Clarified terminology, approved u.c. 94-306 m131 ballot failed 11-7 94-309r1 m131 modified edits and answer, approved 12-1 94-366r1 m131 First edit replaced with revised text from 94-366r1 approved u.c. 95-034r1 m132 X3J3 ballot failed, 16-4 95-043 m132 revised words of answer/edit (no change in intent) and change status to X3J3 approved; approved 10-4 95-244 m134 Updated answer and edits based on new answer to defect item 125, approved u.c. ------------------------------------------------------------------------------ NUMBER: 000083 TITLE: Extending generic intrinsic procedures KEYWORDS: generic name, intrinsic procedure, interface block, INTRINSIC attribute DEFECT TYPE: Erratum STATUS: X3J3 draft response QUESTION: Is the following code fragment standard conforming? INTERFACE SIN REAL FUNCTION MY_SIN(X) REAL, INTENT(IN) :: X END FUNCTION END INTERFACE Section 14.1.2.3 contains the following sentence: "When an intrinsic procedure, operator, or assignment is extended, the rules apply as if the intrinsic consisted of a collection of specific procedures, one for each allowed combination of type, kind type parameter, and rank for each argument or operand." This sentence indicates that there is a "hidden" generic interface for the intrinsic SIN that looks something like : INTERFACE SIN REAL FUNCTION DEFAULT_REAL_SIN(X) REAL, INTENT(IN) :: X END FUNCTION REAL FUNCTION REAL_DIFFERENT_KIND_SIN(X) REAL(KIND=), INTENT(IN) :: X END FUNCTION ... COMPLEX FUNCTION CSIN(X) COMPLEX, INTENT(IN) :: X END FUNCTION ... END INTERFACE Section 11.3.2 indicates that if a user supplies a generic interface SIN such as in the first example, the user interface will be treated as a single interface with the "hidden" generic intrinsic interface. However, according to the rules of section 14.1.2.3 the MY_SIN specific interface and the "hidden" DEFAULT_REAL_SIN specific interface are ambiguous. Therefore users must not write generic interfaces unless they are sure that the generic name they select and the arguments to the specific interfaces they specify will not conflict with any "hidden" generic interfaces implied by the generic intrinsics. ANSWER: The code fragment ought to be standard conforming. Edits are provided to reflect this. Discussion: As the standard is currently written, if a generic interface were written an ambiguity as described in the rules of 14.1.2.3 could not be avoided without knowledge of all intrinsics. Requiring such knowledge is a severe hindrance to the useability of generic interfaces. An edit is supplied so that the rules in 14.1.2.3 do not apply to the specific procedures represented by a generic intrinsic. The rules for resolving procedure references to names established to be generic are given in section 14.1.2.4.1. Section 12.3.2.3 describes the semantics of the INTRINSIC statement. An edit is supplied for this section to clarify that the name of a generic intrinsic procedure with the INTRINSIC attribute can also be the name of a generic interface. EDITS: 1. In section 12.3.2.3 add to the end of the first paragraph after the constraint [171:12]: "A name can appear as both the name of a generic intrinsic procedure in an INTRINSIC statement and as the name of a generic interface if procedures in the interface and the specific intrinsic procedures are all functions or all subroutines (14.1.2.3)." 2. In section 14.1.2.3 in the third sentence [242:28]: change "When an intrinsic procedure, operator, or" to "When an intrinsic operator or" 3. In section 14.1.2.3 add as a new paragraph at the end of the section [243:13+] "If a generic name is the same as the name of a generic intrinsic procedure, the generic intrinsic procedure is not accessible if the procedures in the interface and the specific intrinsic procedures are not all functions or not all subroutines. If a generic invocation applies to both a specific procedure from an interface and a specific intrinsic procedure of an accessible generic intrinsic procedure, it is the specific procedure from the interface that is referenced." SUBMITTED BY: Larry Rolison HISTORY: 92-210 m123 submitted 93-180 m125 Response, approved 19-1 93-255r1 m127 ballot failed 21-3 94-163r1 m129 Clarified answer and added another edit. withdrawn as new edit needs rewording. 94-241 m130 Sorted edits. Revised edit 1. Add edit 3. 94-290r1 m130 Revised edit 2 and deleted edit 3. Simplified discussion. Approved u.c. 94-306 m131 X3J3 ballot failed 12-7 95-196 m134 new version of edits, approved 13-2 ------------------------------------------------------------------------------ NUMBER: 000125 TITLE: Copy in/copy out of target dummy arguments KEYWORDS: argument - dummy, target, interface - explicit, argument association DEFECT TYPE: Erratum STATUS: X3J3 draft response QUESTION:Previous Fortran standards have permitted copy in/copy out as a valid implementation for argument passing to procedures, as does Fortran 90. Fortran 90 introduces POINTER and TARGET attributes. Sections 12.4.1.1 and C.12.8 indicate that it was intended that copy in/copy out also be a valid implementation for passing an actual argument that has the TARGET attribute to a dummy argument that has the TARGET attribute. The following example demonstrates a case where a copy in/copy out implementation may get different results from an implementation which does not use a copy in/copy out method for such a combination of arguments. POINTER IPTR TARGET I IPTR => I CALL SUB (I, IPTR) ... CONTAINS SUBROUTINE SUB (J, JPTR) POINTER JPTR TARGET J PRINT *, ASSOCIATED (JPTR, J) END SUBROUTINE END Is this a flaw in the standard? ANSWER:Yes, there is a flaw in the standard. The edits supplied disallow copy in/copy out as a valid implementation for passing an actual argument that has the TARGET attribute to a corresponding argument that has the TARGET attribute, and is either scalar or is an assumed-shape array. Discussion: The changes apply only to target dummy arguments. Without the changes the behaviour of the example in the question would surprise many programmers. Other examples not involving the ASSOCIATED function are also affected by these changes in such a way that they too will have a more expected behaviour. One such example is included in the edit to section C.12.8. An earlier answer to this defect included different wording for the start of the second paragraph of edit 3: "If the dummy argument has the TARGET attribute and the corresponding actual argument has the TARGET attribute but is not an array section with a vector subscript:" and did not include the paragraph: "If the dummy argument has the TARGET attribute and is an explicit-shape array or is an assumed-size array and the corresponding actual argument has the TARGET attribute but is not an array section with a vector subscript: (1) On invocation of the procedure, whether any pointers associated with the actual argument become associated with the corresponding dummy argument is processor dependent. (2) When execution of the procedure completes, the pointer association status of any pointer that is pointer associated with the dummy argument is processor dependent." An earlier answer to this defect included different wording for the first paragraph of edit 4. "When execution of a procedure completes, any pointer that remains defined and that is associated with a dummy argument that has the TARGET attribute, remains associated with the corresponding actual argument if the actual argument has the TARGET attribute and is not an array section with a vector subscript. The earlier versions of edits 3 and 4, along with edits 1 and 2 were included in corrigendum 2. EDITS: 1. Section 12.4.1.1, add at the end of the fourth paragraph [173:6], "If the dummy argument has the TARGET attribute and the actual argument has the TARGET attribute but is not an array section with a vector subscript, the dummy and actual arguments must have the same shape." 2. Section 12.4.1.1, fifth paragraph, last sentence [173:10-13] delete, "with a dummy argument of the procedure that has the TARGET attribute or" 3. Section 12.4.1.1, delete the sixth paragraph [173:14-17] and replace with, "If the dummy argument does not have the TARGET or POINTER attribute, any pointers associated with the actual argument do not become associated with the corresponding dummy argument on invocation of the procedure. 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. (2) When execution of the procedure completes, any pointers associated with the dummy argument remain associated with the actual argument. If the dummy argument has the TARGET attribute and is an explicit-shape array or is an assumed-size array and the corresponding actual argument has the TARGET attribute but is not an array section with a vector subscript: (1) On invocation of the procedure, whether any pointers associated with the actual argument become associated with the corresponding dummy argument is processor dependent. (2) When execution of the procedure completes, the pointer association status of any pointer that is pointer associated with the dummy argument is processor dependent. If the dummy argument has the TARGET attribute and the corresponding actual argument does not have the TARGET attribute or is an array section with a vector subscript, any pointers associated with the dummy argument become undefined when execution of the procedure completes." 4. Section C.12.8, delete the second paragraph through the end of the section [292:5-37] and replace with "When execution of a procedure completes, any pointer that remains defined and that is associated with a dummy argument that has the TARGET attribute and is either scalar or is an assumed-shape array, remains associated with the corresponding actual argument if the actual argument has the TARGET attribute and is not an array section with a vector subscript. REAL, POINTER :: PBEST REAL, TARGET :: B (10000) CALL BEST (PBEST, B) ! Upon return PBEST is associated ... ! with the "best" element of B CONTAINS SUBROUTINE BEST (P, A) REAL, POINTER :: P REAL, TARGET :: A (:) ... ! Find the "best" element A(I) P => A (I) RETURN END SUBROUTINE END When the procedure BEST completes, the pointer PBEST is associated with an element of B. An actual argument without the TARGET attribute can become associated with a dummy argument with the TARGET attribute. This permits pointers to become associated with the dummy argument during execution of the procedure that contains the dummy argument. For example: INTEGER LARGE(100,100) CALL SUB(LARGE) ... CALL SUB() CONTAINS SUBROUTINE SUB(ARG) INTEGER, TARGET, OPTIONAL :: ARG(100,100) INTEGER, POINTER, DIMENSION(:,:) :: PARG IF (PRESENT(ARG)) THEN PARG => ARG ELSE ALLOCATE (PARG(100,100)) PARG = 0 ENDIF ... ! Code with lots of references to PARG IF (.NOT. PRESENT(ARG)) DEALLOCATE(PARG) END SUBROUTINE SUB END Within subroutine SUB the pointer PARG is either associated with the dummy argument ARG or it is associated with an allocated target. The bulk of the code can reference PARG without further calls to the PRESENT intrinsic." SUBMITTED BY: Jon Steidel - X3J3/93-095 HISTORY: 93-095 m124 submitted with draft response and adopted (15-1) 93-111 m125 ballot, returned to subgroup based on Leonard, Maine comments. Problems with placement of edit 1, content of edit 4 93-139r m125 revised response adopted 17-1. 93-255r1 m127 ballot failed 13-10 94-092r1 m128 revised response, approved 11-5 94-116r1 m129 X3J3 ballot failed 10-13 94-177r1 m129 revised response closer to 93-255r1; approved 19-2 94-221 m130 X3J3 ballot, approved 21-2 94-327 m131 WG5 approved, edit changed to reflect change in corrigendum 2. 95-177 m134 revised response and edits, approved 14-2 ------------------------------------------------------------------------------ NUMBER: 000175 TITLE: What is a "constant specification expression"? KEYWORDS: constant specification expression, expression - constant, specification expression - constant, expression - specification DEFECT TYPE: Erratum STATUS: X3J3 draft response QUESTION: The term "constant specification expression" is used in several places (in two constraints following R429, for example), but nowhere defined. What is the definition of "constant specification expression"? ANSWER:A constant specification expression is a specificiation expression that is also a constant expression. An edit is supplied to define this term. EDIT: In section 7.1.6.2, add to the paragraph ahead of R734 [79:19] "A is a specification expression that is also a constant expression." SUBMITTED BY: Dick Weaver HISTORY: 94-137 m129 submitted 95-186 m134 response proposed, approved u.c. ------------------------------------------------------------------------------ NUMBER: 000179 TITLE: DO variable with POINTER attribute KEYWORDS: DO variable, POINTER attribute DEFECT TYPE: Erratum STATUS: X3J3 draft response QUESTION: The first constraint following rule R822 states: "Constraint: The must be a named scalar variable of type integer, default real, or double precision real." The definition of loop initiation (8.1.4.4.1) states: "(2) The DO variable becomes defined with the value of the initial parameter 1." The definition of the execution cycle of a DO loop (8.1.4.4.2) states: "(3) ... The DO variable, if any, is incremented by the value of the incrementation parameter 3." Consider the following program: INTEGER, POINTER :: PTR INTEGER, TARGET :: LCV PTR => LCV DO PTR = 1, 3 PRINT *, LCV END DO END Note that the DO variable has the POINTER attribute. The POINTER attribute does not seem to be prohibited for the DO variable, but when the DO variable has the POINTER attribute, it is unclear as to whether the DO variable is the pointer or the target of the pointer. That is, it is unclear as to whether the pointer or the target is to be "defined" (8.1.4.4.1) or incremented (8.1.4.4.2). Also consider the following modification of the above program: INTEGER, POINTER :: PTR INTEGER, TARGET :: LCV1, LCV2 LCV1 = 1 LCV2 = 4 PTR => LCV1 DO PTR = 1, 3 IF (...) PTR => LCV2 ! An alternate EXIT form? END DO END The standard does not seem to address what happens when the DO variable is switched to a different variable while the loop is active. Did the standard mean to allow a DO variable to have the POINTER attribute? ANSWER: No. This oversight has been remedied by an edit. Discussion: The description of the iterative form of the DO loop was essentially carried forward from the previous standard. It was an oversight to not prohibit the DO variable from having the POINTER attribute. Prohibiting the POINTER attribute prevents the confusion that can arise as demonstrated by the example programs given above. EDITS: 1. Section 8.1.4.1.1 in the first constraint following rule R822 [100:38] insert "nonpointer" before "named". 2. Section 9.4.2 in the second constraint following rule R918, replace "scalar" with "nonpointer named scalar variable". SUBMITTED BY: Larry Rolison HISTORY: 94-226r1 m130 submitted, approved 10-1 94-306 m131 X3J3 ballot approved 19-0 95-044 m132 WG5 ballot, failed see Cohen's comments 95-246 m134 revised edits, approved u.c. ------------------------------------------------------------------------------ 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 draft response 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. -------------------------------------------------------------------------------- NUMBER: 000202 TITLE: Evaluation of intrinsic procedures KEYWORDS: algorithm, mathematical, computational DEFECT TYPE: Interpretation STATUS: X3J3 draft response 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 can be computed as the more expected 16 000 001.0, may a processor do so? ANSWER: No, a processor is not bound to use the algorithm form 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 ------------------------------------------------------------------------------