J3/05-101 Date: 22-Nov-2004 To: J3 Members From: interp/Stan Whitlock Subj: J3 Fortran interp letter ballot #10 - due 22-Dec-2004 Enclosed in the tenth letter ballot on Fortran interpretations. The rules by which we operate say: o J3 votes on the answer at a J3 meeting; a simple majority vote marks the answer as "passed by J3 meeting". o Between J3 meetings the chair of /interp sends a J3 letter ballot to J3 to approve interp answers that have been "passed by J3 meeting". The letter ballot runs for 30 days. Not voting on three of four consecutive J3 letter ballots is grounds to terminate J3 membership. An interp answer passes by a 2/3rds vote; a no vote must be accompanied by an explanation of the changes necessary to change the member's vote to yes. J3/interp reserves the right to recall an interp answer for more study even if the answer passes. 15 Fortran 2003 interpretations are currently "passed by J3 meeting" after J3 meeting #170. This is the letter ballot phase to go from "passed by J3 meeting" to "passed by J3 letter ballot". The following Fortran interpretations are being balloted: Yes No Number Title --- --- F03/0008 Pointer assignment and arrays --- --- F03/0012 Procedure pointers and the EXTERNAL attribute --- --- F03/0017 Dummy procedure pointers and PRESENT --- --- F03/0018 Multiple identical specific procedures in type-bound generic interfaces --- --- F03/0019 Multiple identical specific procedures in generic interface blocks --- --- F03/0020 Kinds of intrinsic type parameters --- --- F03/0021 What kind of token is a stop code? --- --- F03/0022 Coexistence of IEEE and non-IEEE kinds --- --- F03/0023 IEEE_SET/GET_UNDERFLOW_MODE --- --- F03/0024 DEALLOCATE and array pointers --- --- F03/0025 Abstract types in CLASS IS type guard statements --- --- F03/0026 Intrinsic types in CLASS IS type guard statements --- --- F03/0027 Assumed character length in type guard statements --- --- F03/0028 Commas in complex namelist output --- --- F03/0029 Negative zero and intrinsic functions The text of these interpretations is attached. Each interpretation starts with a row of "-"s. Please mark the above -Y- in the Yes column for "yes", -C- in the Yes column for "yes with comment", or -N- in the No column for a "no" answer {be sure to include your reasons with "no"} and send only the above text {not this entire mail message} with any comments to j3@j3-fortran.org by 11:59:59PM, PST, Wednesday, 22-Dec-2004, in order to be counted. Thanks /Stan ---------------------------------------------------------------------- NUMBER: F03/0008 TITLE: Pointer assignment and arrays KEYWORDS: pointer assignment, array, data-ref DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTION: There appears to be no explicit requirement that the s in R736 and R741 be scalar. If data-pointer-object and proc-component ref were data-refs, then C614 would prohibit the s from being arrays. However, although the syntax looks like a special case of a data-ref, nothing appears to say that R736 and R741 actually constitute data-refs. The standard gives no interpretation as to what the meaning would be in the case of an array. Even when variable is a scalar, the standard does not appear to define what the properties (such as type and shape) of a data-pointer-object or proc-pointer-object are in the case where the syntax has a "%". All we have is a syntax with no established meaning. Q1. Is the in R736 or R741 allowed to be an array? Q2. Is the interpretation of the forms in R736 and R741 the same as that of a data-ref? ANSWER: A1. No. The standard provides no interpretation of what such a form would mean. Therefore, by the first sentence of 1.5, it is not standard-conforming. Edits are provided to make this prohibition more direct. A2. Yes. EDITS: All edits refer to 04-007. [143:12,24,35,37] Insert "" before "", four times. SUBMITTED BY: Richard Maine HISTORY: 04-333 m169 Submitted 04-333r1 m169 Passed by J3 meeting 04-418r1 LB#9 Failed J3 letter ballot 04-421 m170 Revised - Passed by J3 meeting ---------------------------------------------------------------------- NUMBER: F03/0012 TITLE: Procedure pointers and the EXTERNAL attribute KEYWORDS: Procedure pointers, EXTERNAL DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTION: Is the following program unit standard conforming? SUBROUTINE SUB ( RPP ) REAL, EXTERNAL, POINTER :: RPP EXTERNAL :: PP POINTER :: PP PROCEDURE(REAL), POINTER :: PPP => NULL() END SUBROUTINE SUB The last sentence of "5.1.2.6 EXTERNAL attribute" appears to indicate that it is allowed: "A procedure that has both the EXTERNAL and POINTER attributes is a procedure pointer." That the title of subclause 12.2.1.2 is "Characteristics of dummy procedures and dummy procedure pointers" suggests that it is allowed. That subclause continues "... whether it is a pointer, ..." so it was clearly envisioned that at least dummy procedures could have the POINTER attribute. C1216 [264:30] appears to require PPP to be allowed: "C1216 (R1214) If => appears in , the procedure entity shall have the pointer attribute." On the other hand, A conspiracy of C512 [72:28-29] "C512 (R501) If the POINTER attribute is specified, the ALLOCATABLE, TARGET, EXTERNAL, or INTRINSIC attribute shall not be specified." the second sentence of subclause 5.1.2.6 [80:38-40] "This [EXTERNAL] attribute may also be specified by ... a ..." the first paragraph of subclause 5.2 [85:15ff] "The combination of attributes that may be specified for a particular entity is subject to the same restrictions ... regardless of the method of specification. This also applies to the PROCEDURE, EXTERNAL and INTRINSIC statements." and the last sentence of the first paragraph of 12.3.2.3 [264:8] "It [the procedure declaration statement] specifies the EXTERNAL attribute...." appears to completely wipe out procedure pointers (PPP because of the first paragraph of 12.3.2.3). C521 [73:6-7] and C568 [91:5] also appear to prohibit RPP and PP: "C521 (R504) The shall be the name of an external function, a function dummy procedure{, or a statement function}." "C568 (R541) A shall also be declared in a ." But then the first paragraph after R1210 (defining the EXTERNAL statement) [264:1] appears to allow RPP and PP: "Each shall be the name of ... a procedure pointer...." There is also a problem with protected procedure pointers. C535 clearly envisions their existence: "C535 (R501) The PROTECTED attribute is permitted only for a procedure pointer...." while C536 prohibits their existence: "C536 (R501) If the PROTECTED attribute is specified, the EXTERNAL ... attribute shall not be specified." ANSWER: The discussion of procedure pointers is indeed inconsistent. The program unit is intended to be standard conforming. It was an oversight during the development of the procedure pointer facility that the EXTERNAL attribute was not removed from C512, that "procedure pointer" was not added to C521, that C535 and C536 contradict one another, and that an external statement and specifying the EXTERNAL attribute in a type declaration statement were not allowed in C568. It is not helpful that the last sentence of the first paragraph of subclause 5.2 refers to "PROCEDURE ... statements" (which could be confused with the PROCEDURE statement in an interface block) where it should refer to "procedure declaration ... statements." EDITS: Delete ", EXTERNAL" from C512 [72:28]. Insert ", a procedure pointer" after "dummy procedure" in C521 [73:7]. Replace C536 [7:35-36]: "C536 (R501) If the PROTECTED attribute is specified, the INTRINSIC or PARAMETER attribute shall not be specified. If the PROTECTED and EXTERNAL attributes are specified, the POINTER attribute shall also be specified." Replace the last sentence of the first paragraph of subclause 5.2 [86:1] by "This also applies to procedure declaration statements, and to EXTERNAL and INTRINSIC statements." Replace C568 [91:5]: "C568 (R541) The EXTERNAL attribute (5.1.2.6) shall be explicitly specified for a ." SUBMITTED BY: Van Snyder HISTORY: 04-358 m169 Submitted 04-358r2 m169 Revised 04-418r1 LB#9 Failed J3 letter ballot 04-401r2 m170 Passed by J3 meeting ---------------------------------------------------------------------- NUMBER: F03/0017 TITLE: Dummy procedure pointers and PRESENT KEYWORDS: Dummy procedure pointers, PRESENT DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTION: Does the following program conform to the 2003 standard? procedure(real), pointer :: F => null() call s ( f ) contains subroutine S ( F ) procedure(real), optional, pointer :: F print *, present(f) end subroutine S end ANALYSIS: The second paragraph of 12.4.1.3 requires that if the dummy argument does not have the POINTER attribute and the actual argument does, the actual argument shall be associated. It is not clear in 13.7.91 whether the argument of PRESENT has or has not the POINTER attribute. ANSWER: The program conforms to the 2003 standard. An edit is supplied to remove any possibility of a contradictory reading of the relation between 12.4.1.3 and 13.7.91. EDITS: In the second paragraph of 12.4.1.3 [271:16] replace "an associated" by "a". At the end of that paragraph, insert a new sentence: "Except in references to intrinsic inquiry functions, if the actual argument is a pointer it shall be associated." SUBMITTED BY: Van Snyder HISTORY: 04-402 m170 Submitted 04-402r2 m170 Passed J3 meeting ---------------------------------------------------------------------- NUMBER: F03/0018 TITLE: Multiple identical specific procedures in type-bound generic interfaces KEYWORDS: Type-bound generics DEFECT TYPE: Clarification STATUS: Passed by J3 meeting QUESTION 1: Does the following program unit conform to the 2003 standard? module M type T contains procedure MyAdd generic :: operator(+) => myAdd end type T type X contains procedure, pass(b) :: MyAdd generic :: operator(+) => myAdd end type X contains integer function MyAdd ( A, B ) type(t), intent(in) :: A type(x), intent(in) :: B end function MyAdd end module M QUESTION 2: Does the following program unit conform to the 2003 standard? module M interface operator(+) procedure MyAdd end interface type T contains procedure MyAdd generic :: operator(+) => myAdd end type T contains integer function MyAdd ( A, B ) type(t), intent(in) :: A real, intent(in) :: B end function MyAdd end module M QUESTION 3: If the interface block and type definition are exchanged in QUESTION 2, does the program unit conform to the 2003 standard? ANALYSIS: The OPERATOR(+) bindings to the types T and X construct a single generic OPERATOR(+) interface that is a local entity of module M. They do not construct separate OPERATOR(+) generic interfaces that are separate local entities of the types. 16.2.3 (Restrictions on generic declarations) specifies that it "contains the rules that shall be satisfied by every pair of specific procedures that have the same generic identifier within a scoping unit." It is clear that if different functions with identical interfaces were bound to the types that they would be a "pair of specific procedures" and the resulting OPERATOR(+) interface would therefore be prohibited by 16.2.3. It is not clear whether the generic bindings bind separate specific procedures to the OPERATOR(+) generic, or only redundantly bind the same procedure. If the former, the program units are not standard conforming because they violate the provisions of 16.2.3. If the latter, they appear to be standard conforming. C1209 (in 12.3.2.1) prohibits a procedure to be bound to a generic interface more than once in a scoping unit, but only by way of a PROCEDURE statement in a generic interface block. There is nothing obviously equivalent in 4.5.4, nor anything that specifies that C1209 applies to generic bindings to types. It also does not apply between a generic interface block and a generic interface previously specified by a generic binding to a type (question 3), since the latter specific binding is accomplished by a conspiracy of a and a , not by a . ANSWER: The program units conform to the 2003 standard. Multiple bindings of the same procedure to a generic identifier using a in a type definition or by a type definition and a generic interface block do not bind a "pair of specific procedures" to the generic interface. Indeed, the following type definition is legal: type Z contains procedure :: MyAdd generic :: operator(+) => myAdd, operator(+) => myAdd end type Z EDITS: None. SUBMITTED BY: Van Snyder HISTORY: 04-405 m170 Submitted 04-405r1 m170 Passed by J3 meeting ---------------------------------------------------------------------- NUMBER: F03/0019 TITLE: Multiple identical specific procedures in generic interface blocks KEYWORDS: Type-bound generics DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTION 1: Does the following program conform to the 2003 standard? program P interface X subroutine S ( A ) integer :: A end subroutine S procedure S end interface X end program P ANALYSIS: 16.2.3 (Restrictions on generic declarations) specifies that it "contains the rules that shall be satisfied by every pair of specific procedures that have the same generic identifier within a scoping unit." It is not clear whether the interface body and the procedure statement bind separate specific procedures to the generic identifier, or only redundantly bind the same procedure. If the former, the program is not standard conforming because it violates the provisions of 16.2.3. If the latter, it appears to be standard conforming. C1209 (in 12.3.2.1) prohibits a procedure to be bound to a generic interface more than once in a scoping unit, but only by way of a PROCEDURE statement in a generic interface block. There is a general rule that nothing shall be declared more than once. It appears that a procedure statement within an interface block is not a declaration: 5.1.2.6 (External attribute) specifies that the external attribute may be specified by an EXTERNAL statement, a or an interface body that is not in an abstract interface block. A procedure statement in an interface block apparently does not specify the external attribute. The procedure specified by the PROCEDURE statement in the above example is clearly an external procedure with an explicit interface, so it satisfies the requirements of C1207. ANSWER: The program conforms to the 2003 standard. Multiple bindings of the same procedure to a generic identifier using an interface body and a procedure statement do not bind a "pair of specific procedures" to the generic interface. Enforcing C1209 is more bother for processors than simply allowing multiple bindings of a particular specific procedure to a generic interface. It is unhelpful to users, and can be hurtful if the multiple bindings are specified by independent generic interfaces and brought into a scoping unit by use association from different modules. There was no equivalent constraint in Fortran 90, although something like it was added by interp F90/000007. The constraint added there applied only to a single specification part. It's not clear whether that meant "declared in the same specification part" or "accessible in the same specification part." When it was put into Fortran 95, it clearly applied to all accessible generic interfaces with a particular . Given the multitude of new ways to bring specific procedures into a generic interface in Fortran 2003, and that many of those ways allow a specific procedure to be bound to a generic identifier more than once, this conspicuously lonely constraint should be removed. Edits are supplied to correct this oversight. EDITS: Remove C1209 from 12.3.2.1. SUBMITTED BY: Van Snyder HISTORY: 04-406 m170 Submitted 04-406r1 m170 Passed J3 meeting ---------------------------------------------------------------------- NUMBER: F03/0020 TITLE: Kinds of intrinsic type parameters KEYWORDS: type parameter, kind, intrinsic type DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTION: Q1. What are the kinds of the type parameters for intrinsic types? In most contexts, it doesn't matter. Fortran 95 did not even have the concept of the kind of a type parameter or a context in which such a thing could be detected in a standard-conforming program. Fortran 2003 added the concept in support of derived types. It also added a syntax which exposes the question for intrinsic types. Q2. What is the KIND of a type parameter inquiry? Q3. For example, consider the program program what_kind character c write (*,*) kind(c%kind) == kind(0) write (*,*) kind(c%len) == kind(0) end Are both write statements guaranteed to print .true. (meaning that the c%kind and c%len are of default kind) or not? For KIND parameters, although I can't find it explicitly stated, I see fairly strong evidence that all intrinsic kind parameters are intended to be default integers. This evidence is in the intrinsic functions. The KIND intrinsic function and all the selected_*_kind functions are specified to return default integers, which would make for some strangeness if the kind parameters were not default integer, in particular if the KIND intrinsic could not return the kind of its argument because that kind could not be represented in a default integer. There also seems no obvious benefit to having the kind of the intrinsic kind parameters be anything other than default. In practice, the number of supported values for kind is small and would have no trouble being represented in a default integer; large arrays of kind values are rare, so there isn't much benefit in using representations smaller than default. For character length, I see no similar evidence. Indeed, the LEN intrinsic seems to suggest that lengths might be other than default integer. I believe that there was clear intent to facilitate (but not require) support for character lengths longer than could be expressed by a default integer. In most contexts, it doesn't directly matter what the kind of length is. Parameter specifications in type-specs don't have to match in kind. So the user could specify and do arithmetic on lengths using whatever kind was appropriate for the anticipated problem sizes. The limit on maximum character length is processor-dependent anyway and is not necessarily the same as HUGE(whatever) (though it is a bit hard to imagine how it could usefully be larger). The only context in which I can see that might matter is in a type parameter inquiry (6.1.3). We don't appear to have defined the kind of a type parameter inquiry. Although we didn't say, I am assuming that a type parameter inquiry ought to "return" the kind of the type parameter it is inquiring about. Otherwise, there would be no way to inquire about the type parameter values of some derived type variables (if the values didn't fit in a default integer). We probably ought to explicitly say, though. ANSWER: Q1. The kind parameters of all the intrinsic types are of default integer kind. The kind parameter of the intrinsic character length parameter is processor-dependent. The support for this answer is as described in the question. Edits are provided to make this answer explicit. Q2. The kind parameter of a type inquiry is the same as that of the type parameter inquired about. See page 123, lines 35-36. Q3. The first write statement is guaranteed to print a .true. value; it is processor dependent whether the second one prints a .true. or .false. value. EDITS: All edits apply to 04-007. At [36:14], [37:30], [39:15], [40:14], and [44:2], insert the following sentence before "The kind": The kind type parameter is of type default integer. At [40:10], before "its", insert "its kind is processor-dependent and". SUBMITTED BY: Richard Maine HISTORY: J3/04-408 m170 Submitted J3/04-408r1 m170 Passed by J3 meeting ---------------------------------------------------------------------- NUMBER: F03/0021 TITLE: What kind of token is a stop code? KEYWORDS: STOP, token DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTION: The , when it is a string of s, does not appear to be specified by the standard to be any particular kind of token. Or indeed whether it is one token per or one per . The answer to these questions determines whether blanks are allowed, disallowed, or optional, in the middle of a STOP statement in free form. Consider the following statements: (1) STOP 123 (2) STOP123 (3) STOP 1 2 3 Which, if any, of these statements are standard-conforming? ANSWER: Only statement (1) was intended to be standard-conforming. Edits are supplied to clarify the situation. EDITS: [170:23] Replace with "<> " [170:24+] Insert new constraint "C834a (R850) The shall not have a and shall not have more than 5 s." [170:27] After "significant" insert "and all stop codes are permissible even if not representable in the default integer type" SUBMITTED BY: Malcolm Cohen HISTORY: J3/04-416 m170 Submitted - Passed by J3 meeting ---------------------------------------------------------------------- NUMBER: F03/0022 TITLE: Coexistence of IEEE and non-IEEE kinds KEYWORDS: IEEE, kind DEFECT TYPE: Interpretation STATUS: Passed by J3 meeting QUESTION: Is it allowed for a processor to have one or more real kinds for which there is no IEEE support, while also having real kinds for which there is IEEE support? Much of the IEEE material appears to assume that a processor could simultaneously support both IEEE and non-IEEE kinds. I thought this was the intent. However, the first sentence of the second paragraph in section 14 says that if IEEE_EXCEPTIONS or IEEE_ARITHMETIC is accessible in a scoping unit, then IEEE_OVERFLOW and IEEE_DIVIDE_BY_ZERO are supported in the scoping unit for *ALL* [emphasis mine] kinds of real and complex data. This says to me that if there is any kind of real for which the processor cannot support IEEE_OVERFLOW or IEEE_DIVIDE_BY_ZERO, then pretty much none of the IEEE stuff can be used on that processor at all; there isn't much of the IEEE stuff that can be used without IEEE_ARITHMETIC or IEEE_EXCEPTIONS. This seems draconian and unintended. I speculate that this condition is intended to apply to all IEEE real kinds rather than to all real kinds. ANSWER: Yes, this is allowed. The requirement that IEEE_OVERFLOW and IEEE_DIVIDE_BY_ZERO be supported for all kinds of real and complex data within that scoping unit was intentional. Support of these two flags means that the exceptions can be detected, either by a subsequent use of IEEE_GET_FLAG or by program termination (this is not under program control unless IEEE_SUPPORT_HALTING is true for those flags). Whether the flags are supported outside of a routine which uses IEEE_EXCEPTIONS or IEEE_ARITHMETIC is processor dependent. EDITS: None. SUBMITTED BY: Richard Maine HISTORY: J3/04-419 m170 Submitted J3/04-419r1 m170 Passed by J3 meeting ---------------------------------------------------------------------- NUMBER: F03/0023 TITLE: IEEE_SET/GET_UNDERFLOW_MODE KEYWORDS: IEEE, underflow mode DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTION: Is it allowed for the argument of IEEE_SET_UNDERFLOW_MODE or IEEE_GET_UNDERFLOW_MODE to be an array? There appears to be no restriction against arrays in these procedures. For IEEE_SET_UNDERFLOW_MODE, it is ill-defined what an array would mean. The wording implies a scalar, in that it talks about being true or false, but the restriction to scalars is not explicit. For IEEE_GET_UNDERFLOW_MODE, it could be defined, but seems a little silly and nonparallel. The similar procedures for rounding mode do explicitly specify that their arguments are scalar. ANSWER: No, arrays are not allowed for these arguments. Edits are provided to correct this error. EDITS: [374:21] Add "scalar and" after "shall be" [380:13] Add "scalar and" after "shall be" SUBMITTED BY: Richard Maine HISTORY: J3/04-420 m170 Submitted - Passed by J3 meeting ---------------------------------------------------------------------- NUMBER: F03/0024 TITLE: DEALLOCATE and array pointers KEYWORDS: DEALLOCATE, array pointers DEFECT TYPE: Interpretation STATUS: Passed by J3 meeting QUESTION: We currently say that one can deallocate an array pointer if it points to the "whole of an object that was created by allocation". What exactly does "whole" mean in this rule? Specifically, is the following allowed: REAL, DIMENSION(:), POINTER :: a, b ALLOCATE(a(1:10)) b=>a(1:10) DEALLOCATE(b) ANSWER: Yes, this is allowed, since "whole" means that b is ASSOCIATED with all elements of an array that was ALLOCATEd. In the given example, ASSOCIATED(a,b) is .TRUE., therefore either a or b can be used to DEALLOCATE the memory. EDITS: None SUBMITTED BY: Aleksandar Donev HISTORY: 04-378 m170 Submitted 04-378r1 m170 Passed by J3 meeting ---------------------------------------------------------------------- NUMBER: F03/0025 TITLE: Abstract types in CLASS IS type guard statements KEYWORDS: ABSTRACT, CLASS IS, type guard, SELECT TYPE DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTION: Consider the following program: PROGRAM foo TYPE, ABSTRACT :: base INTEGER i END TYPE TYPE, EXTENDS(base) :: child INTEGER j END TYPE CLASS(*), POINTER :: x TYPE(child), TARGET :: c1 x => c1 SELECT TYPE (x) CLASS IS (base) PRINT *, 'Class is base' CLASS DEFAULT PRINT *, 'Class is not base' END SELECT END Constraint C401 seems to prohibit the abstract type "base" from appearing in a CLASS IS type guard statement, thus prohibiting this program. There seems to be no reason to prohibit this, and allowing it seems to be useful in some situations. Was this program intended to be standard-conforming? ANSWER: Yes, this program was intended to be standard-conforming. Edits are provided to correct this oversight. EDITS: All edits refer to 04-007. [162:17] Change "" to "". [162:19] After "", insert "or ". [162:20] After "", insert "or ". [162:21] After "", insert "or ". SUBMITTED BY: Rob James HISTORY: 04-411 m170 Submitted 04-411r1 m170 Passed by J3 meeting ---------------------------------------------------------------------- NUMBER: F03/0026 TITLE: Intrinsic types in CLASS IS type guard statements KEYWORDS: CLASS IS, type guard, SELECT TYPE, intrinsic type DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTION: Consider the following program: PROGRAM foo CLASS(*), POINTER :: x INTEGER, TARGET :: i x => i SELECT TYPE (x) CLASS IS (INTEGER) PRINT *, 'How can INTEGER be a class?' END SELECT END The description of a CLASS IS type guard statement refers to an extension of the type specified. This makes no sense for nonextensible types. C815 disallows all nonextensible derived types, but nothing disallows intrinsic types, which are also nonextensible. Was this program intended to be standard-conforming? ANSWER: No, this program was not intended to be standard-conforming. Edits are supplied to correct this oversight. EDITS: All edits refer to 04-007. Note that these edits are the same as the edits proposed for F03/0025. [162:17] Change "" to "". [162:19] After "", insert "or ". [162:20] After "", insert "or ". [162:21] After "", insert "or ". SUBMITTED BY: Rob James HISTORY: 04-412 m170 Submitted 04-412r1 m170 Passed by J3 meeting ---------------------------------------------------------------------- NUMBER: F03/0027 TITLE: Assumed character length in type guard statements KEYWORDS: CHARACTER, assumed length, type guard, SELECT TYPE DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTION: Consider the following program: PROGRAM foo CHARACTER, TARGET :: c CLASS(*), POINTER :: p p => c SELECT TYPE (p) TYPE IS (CHARACTER(*)) PRINT *, 'Character of length ', LEN(p) END SELECT END Constraint C814 says that, in a type guard statement, the shall specify that each length type parameter is assumed. Constraint C416 does not list a type guard statement as a context in which "*" can be used as a length type parameter for a character. Was this program intended to be standard-conforming? ANSWER: Yes, this program was intended to be standard-conforming. Edits are supplied to correct this oversight. EDITS: All edits refer to 04-007. [41:9] Remove "or". [41:9+] Add a new list item: "(3.5) in the of a type guard statement (8.1.5), or" [41:33+] Add a new list item: "(3.5) If used in the of a type guard statement, the associating entity assumes its length from the selector." SUBMITTED BY: Rob James HISTORY: J3/04-413 m170 Submitted J3/04-413r1 m170 Passed by J3 meeting ---------------------------------------------------------------------- NUMBER: F03/0028 TITLE: Commas in complex namelist output KEYWORDS: Namelist, complex formatting, comma, semicolon DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTION: The 7th paragraph in 10.9.2 for list directed output says: "Complex constants are enclosed in parentheses with a separator between the real and imaginary parts, each produced as defined above for real constants. The separator is a comma if the decimal edit mode is POINT; it is a semicolon if the decimal edit mode is COMMA." There are similar words in most other places where complex formatting is described. The second paragraph of 10.10.1.3 Namelist group object list items says: "When the next effective item is of type complex, the input form of the input value consists of a left parenthesis followed by an ordered pair of numeric input fields separated by a comma and followed by a right parenthesis. " Other places correctly describe namelist complex output as having a separator, either a comma or a semicolon, depending on the decimal edit mode. Should the namelist version be reworded to say "comma or semicolon"? ANSWER: Yes. Edits are supplied to correct this oversight. EDITS: All edits refer to 04-007. [244:29] Replace "comma" with "separator". [244:30] Before "The first", add the following sentence: The separator is a comma if the decimal edit mode is POINT; it is a semicolon if the decimal edit mode is COMMA. [244:32] Replace "comma" with "separator". [244:33] Replace "comma" with "separator". SUBMITTED BY: Dick Hendrickson HISTORY: 04-409 m170 Submitted 04-409r1 m170 Passed by J3 meeting ---------------------------------------------------------------------- NUMBER: F03/0029 TITLE: Negative zero and intrinsic functions KEYWORDS: Negative zero, IEEE, intrinsic functions DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTION: 4.4.2 states "Processors that distinguish between positive and negative zeros shall treat them as equivalent ... as actual arguments to intrinsic procedures other than those for which it is explicitly specified that negative zero is distinguished" Q1. Does this mean that TRANSFER(-0.0,42) is required to give the same answer as TRANSFER(+0.0,42)? The definition of TRANSFER has no explicit mention of negative zero. Q2. Does this mean that MERGE(+0.0,-0.0,flag) always returns +0.0? Q3. Does this mean that SPREAD(-0.0,2) has the value [+0.0,+0.0] instead of [-0.0,-0.0]? Q4. Does this mean that RESHAPE([-0.0],[1]) has the value [+0.0] instead of [-0.0]? Q5. Does this mean that SET_EXPONENT(-0.0,10) is +0.0 not -0.0? Q6. Does this mean that if a REAL variable X has a negative zero value, REAL(x,...) has a positive zero value? Q7. Does this mean that CMPLX(0,-0.0) has the value (+0.0,+0.0) instead of (+0.0,-0.0)? Q8. Does this mean that if a complex variable C has a negative zero imaginary part, that AIMAG(C) returns +0.0 instead of -0.0? Q9. In any other intrinsic function, if the definition of the intrinsic would imply a different result for negative zero than for positive zero, does this mean that the function returns the positive zero answer for a negative zero argument? ANSWER: Q1. No. The definition of TRANSFER explicitly states that its result has the same physical representation as its first argument. This would not be possible if "equivalent" meant that the exact same result had to be produced. Q2. No, this would contradict the definition of MERGE. Q3. No. SPREAD "replicates" its argument, which means that the value of each copy is the same as the original, not just compare equal. As with TRANSFER, this would not be possible with the suggested interpretation of the text in 4.4.2. Q4+. No. As with the previous questions, this would require an overly strict interpretation of the term "equivalent", contradicting the clear intent of the function in question. DISCUSSION: The term "equivalent" in the quoted text in 4.4.2 refers to the concept of mathematical equivalence, not physical or computational equivalence. A clarifying edit is supplied. EDITS: [38:2] Before "equivalent" insert "mathematically". SUBMITTED BY: Malcolm Cohen HISTORY: J3/04-422 m170 Submitted - Passed by J3 meeting ----------------------------------------------------------------------